SOCKS5 UDP: как работает команда UDP ASSOCIATE

Поддержка UDP в SOCKS5 означает, что прокси может передавать UDP-датаграммы, а не только TCP, с помощью команды UDP ASSOCIATE. Именно поэтому SOCKS5 встречается в DNS-запросах, VoIP-звонках и работе с QUIC. Механика работы описана ниже со ссылками на спецификацию. Отдельная страница сравнивает провайдеров с поддержкой UDP; здесь всё остаётся на уровне протокола.

Обозначения, используемые во всех таблицах ниже: ✅ задокументировано поставщиком · ❌ не предоставляется или не задокументировано · ⚠️ задокументировано с ограничениями · 💡 практический совет. Другие обозначения на этой странице не используются.

Чем SOCKS5 отличается от SOCKS4 и HTTP-прокси

SOCKS5 отличается от SOCKS4 и HTTP-прокси главным образом поддержкой протоколов и аутентификацией. SOCKS4 передаёт только TCP и не поддерживает аутентификацию; HTTP-прокси ограничены веб-трафиком и проверяют заголовки. SOCKS5 работает на уровень ниже, на сеансовом уровне, оставаясь независимым от протоколов. Именно поэтому сравнение SOCKS5 и SOCKS4 возникает снова и снова.

SOCKS4 по-прежнему подходит для старых скриптов, которые вообще не затрагивают UDP, и для них он отлично работает без изменений. SOCKS5 же — разумный выбор для всего, что работает в реальном времени или зависит от UDP.

Рукопожатие SOCKS5 и команда UDP ASSOCIATE шаг за шагом

Команда UDP ASSOCIATE в SOCKS5 открывает временный ретранслятор, чтобы клиент мог отправлять и получать UDP-датаграммы через прокси, а не напрямую. Она выполняется вместе со стандартным рукопожатием: приветствие, аутентификация, запрос. После одобрения ответ возвращает адрес ретрансляции для каждого последующего пакета. Согласно заметкам Рамы о RFC 1928, TCP-сессия, стоящая за ней, должна оставаться открытой, иначе ретранслятор перестаёт работать.

Рукопожатие SOCKS5 и ретрансляция UDP ASSOCIATE

1. Шаг 1. TCP-рукопожатие. Клиент подключается и отправляет приветствие с методами аутентификации.
2. Шаг 2. Выбор метода. Прокси выбирает метод, часто пароль или без аутентификации.
3. Шаг 3. Аутентификация. При необходимости обе стороны обмениваются учётными данными.
4. Шаг 4. Запрос UDP ASSOCIATE. Клиент отправляет команду с указанием IP/порта или 0.0.0.0:0.
5. Шаг 5. Назначение порта ретрансляции. Прокси отвечает привязанным адресом для датаграмм.
6. Шаг 6. Пересылка датаграмм. Клиент оборачивает пакеты в заголовок SOCKS5; прокси распаковывает и пересылает их.

Этот порт остаётся привязанным к TCP-соединению, об этом легко забыть, когда сессия разрывается.

TCP против UDP через прокси

TCP и UDP ведут себя через прокси по-разному, и протокол SOCKS5 поддерживает оба, но не одинаково. TCP требует рукопожатия, упорядоченной доставки и повторной передачи, что добавляет задержку, но гарантирует доставку. UDP пропускает всё это: нет рукопожатия, нет порядка, нет повторной отправки — он легче для чувствительного ко времени трафика.

Выбор неправильного транспорта — это не проблема прокси, а несоответствие между потребностями приложения и тем, на чём оно работает.

Когда поддержка UDP действительно важна

Не каждая рабочая нагрузка способна выдержать накладные расходы, которые добавляет путь только по TCP. Поддержка SOCKS5 UDP важна всегда, когда приложение не может поглотить накладные расходы на рукопожатие или повторную передачу. Разрешение DNS, HTTP/3 на базе QUIC, VoIP и многопользовательские игры по своей сути полагаются на UDP. Без поддержки UDP эти приложения либо полностью отказываются работать, либо откатываются на более медленный путь. Это не нишевая тема — всё больше веба переходит на протокол QUIC.

Стоит в первую очередь проверить поддержку UDP для:

• ✅ DNS-запросов, которым нужен тот же исходящий IP, что и у остальной части сессии
• ✅ Трафика QUIC и HTTP/3 — для проверки поведения сайтов на новом транспорте
• ✅ Проверки качества VoIP и видеозвонков между регионами
• ✅ Мониторинга в реальном времени, где важна точность времени
• ✅ Пользовательских UDP-протоколов, созданных для внутренних инструментов

Это имеет смысл только как легитимное использование SOCKS5 UDP: ваша собственная инфраструктура, ваши аккаунты или работа по договору — но никогда чужие системы.

Разрешение DNS: SOCKS5 против socks5h

Обычный SOCKS5 по умолчанию разрешает DNS локально, поэтому запрос может выйти за пределы туннеля. SOCKS5h меняет это: он отправляет доменное имя прокси, который вместо клиента выполняет удалённое разрешение DNS. Разница кажется небольшой, пока локальное разрешение не раскрывает, какие сайты запрашивает сессия. Настройки, ориентированные на приватность, по умолчанию используют SOCKS5h, когда клиент его поддерживает.

Где разрешается доменное имя

В cURL это один флаг: --socks5 разрешает локально, --socks5-hostname удалённо.

Методы аутентификации в SOCKS5

Протокол SOCKS5 определяет стандартные методы аутентификации, и правильный выбор зависит от конфигурации. Логин и пароль без проблем работают с браузерами, скриптами и антидетект-инструментами. Белый список IP обходится без учётных данных и проверяет подключающийся IP по одобренному списку, что подходит для фиксированных серверов. Оба метода предотвращают несанкционированное использование; ни один из них не шифрует.

Два способа аутентификации SOCKS5-соединения

Как эти два метода распределяются по сценариям использования:

• ✅ Логин/пароль: подходит для скриптов и антидетект-настроек с меняющимся IP
• ✅ Белый список IP: подходит для фиксированных серверов и автоматизации со статическими IP

💡 Периодически меняйте общие учётные данные при командном доступе

Чего SOCKS5 не делает

Поддерживает ли SOCKS5 UDP? Да, через UDP ASSOCIATE, но это маршрутизация, а не защита. Включает ли это шифрование? Нет, протокол никогда не создавался для шифрования полезной нагрузки, поэтому открытый текст остаётся открытым, если не обёрнут в TLS. SOCKS5 также не трогает отпечаток браузера; данные canvas, шрифтов и экрана проходят как есть. Это слой маршрутизации, а не приватности.

• ❌ Нет шифрования полезной нагрузки; SOCKS5 маршрутизирует трафик, не оборачивая его в TLS
• ❌ Нет маскировки отпечатка браузера; данные canvas и шрифтов проходят без изменений
• ❌ Нет защиты от утечек WebRTC; это настройка браузера, а не прокси
• ❌ Нет встроенной фильтрации вредоносного ПО или контента

Как проверить поддержку UDP в вашей конфигурации

Быстрая проверка лучше, чем гадать, действительно ли работает пакет. Тестирование поведения SOCKS5 UDP ASSOCIATE занимает пять-шесть проверок, и ни одна из них не требует специальных инструментов, кроме прокси-клиента и окна терминала. Начните с малого: подтвердите основы, прежде чем гнаться за производительностью. Потери пакетов и задержка имеют значение только при стабильном соединении. Выполняйте эти шаги по порядку, а не переходите сразу к замерам времени.

1. Шаг 1. Подключите клиент, убедитесь, что рукопожатие завершено.
2. Шаг 2. Отправьте запрос UDP ASSOCIATE, проверьте наличие корректного адреса ретрансляции.
3. Шаг 3. Выполните DNS-запрос через ретранслятор, убедитесь, что он корректно возвращается.
4. Шаг 4. Проверьте исходящий IP с помощью инструмента what-is-my-ip.
5. Шаг 5. Измерьте потери пакетов на нескольких сотнях UDP-пакетов.
6. Шаг 6. Запишите задержку как p50 и p95, поскольку всплески важнее среднего значения.

Распространённые ошибки

Привычки тестирования сильно различаются между командами, но шаблоны сбоев повторяются. Большинство проблем с UDP сводятся к нескольким ошибкам. Предположение, что каждый пакет поддерживает UDP без проверки документации, — самая большая из них, поскольку то, поддерживает ли SOCKS5 UDP, часто зависит от тарифа пакета, а не от названия протокола. Тестирование задержки до того, как заработает ретрансляция, идёт следом.

• ❌ Предположение, что UDP работает на каждом пакете, без проверки документации
•  Пропуск DNS-теста, переход сразу к прикладному трафику
• ❌ Игнорирование потерь пакетов и внимание только к средней задержке
• ❌ Повторное использование одного и того же порта ретрансляции в несвязанных сессиях
• ❌ Забывание о том, что управляющее TCP-соединение должно оставаться открытым

Ни одна из этих ошибок не экзотична — все они происходят из-за пропуска проверки, которую большинство людей считают выполняемой протоколом SOCKS5 автоматически, без какого-либо шага ручной верификации.

Как Insocks поддерживает SOCKS5 с UDP

Раскрытие информации: Insocks — это наш сервис, поэтому относитесь к этому разделу как к информации от поставщика, а не к независимому исследованию, поскольку здесь есть очевидная коммерческая заинтересованность. Каждый пакет обрабатывает основы протокола одинаково под капотом, но часть, связанная с UDP, довольно заметно различается между провайдерами и тарифами. Полный стек был создан с расчётом на UDP с первого дня, а не добавлен позже. Прокси Insocks поддерживают SOCKS5 UDP на резидентных, мобильных, ISP и статических пакетах, поскольку UDP-ретрансляция находится в базовом стеке, а не добавлена сверху как запоздалая мысль. Настройка не требует дополнительной конфигурации: выберите SOCKS5 в вашем инструменте, и UDP передаётся автоматически. Именно поэтому команды выбирают Insocks, когда UDP просто обязан работать.

Источник: UDP-прокси, insocks.com, скриншот сделан в августе 2026 года

Аутентификация работает с логином и паролем или без них, в зависимости от настроек аккаунта. Каждый запрос SOCKS5 UDP ASSOCIATE проходит через одну и ту же инфраструктуру ретрансляции, независимо от того, из какого пакета он отправлен.

Любой, кто использует эти прокси, подтверждает правомерность использования в рамках нормативных требований США и условий обслуживания каждого сайта, поскольку всё это не предназначено для обхода правил, намеренно установленных целевым сайтом. Проверьте поведение SOCKS5 UDP с помощью бесплатной демо-версии или переходите сразу к регистрации.

Основные выводы

Краткая версия для тех, кто бегло просматривает текст перед приведённым ниже FAQ, охватывает уже пройденный путь по разделам, не повторяя каждую последнюю деталь из вышеизложенного. Она служит быстрым ориентиром для всех, кто пролистал мимо какого-то шага. Эти пункты суммируют приведённый выше разбор, включая вопрос о том, поддерживает ли SOCKS5 UDP так, как предполагает большинство людей. Ничто здесь не заменяет спецификацию в особых случаях. Рассматривайте это как краткое повторение, а не полную картину.

• ✅ SOCKS5 поддерживает TCP и UDP через команду UDP ASSOCIATE
• ✅ SOCKS5h разрешает DNS удалённо; обычный SOCKS5 разрешает локально, что может привести к утечке
• ✅ Аутентификация — это логин/пароль или белый список IP, но никогда шифрование
• ✅ Поддержка UDP зависит от пакета, а не только от названия протокола
• ✅ Тестирование начинается с основ подключения, а не с задержки и потерь пакетов

Раскрытие информации и источники данных

Все данные в этой статье, включая цены, уровни тарифов, лимиты и доступность продуктов, точны на дату публикации, указанную на этой странице. Условия поставщиков часто меняются без предварительного уведомления, начальные тарифы сдвигаются в зависимости от объёма, а промо-цены могут действовать в день, когда вы это читаете. Ничто здесь не является офертой, гарантией текущих условий или рекомендацией к покупке.

Эта статья опубликована Insocks. Insocks продаёт прокси и имеет коммерческую заинтересованность в разделе выше. Детали протокола основаны на цитируемой спецификации и документации поставщика, актуальной на август 2026 года. Товарные знаки принадлежат их владельцам.

Часто задаваемые вопросы

Прямые ответы на вопросы, которые люди задают чаще всего по этой теме.

Поддерживает ли SOCKS5 UDP?

Да, через UDP ASSOCIATE, передавая датаграммы через выделенный порт после TCP-рукопожатия.

Что такое команда UDP ASSOCIATE?

Команда SOCKS5, открывающая порт ретрансляции, чтобы UDP-датаграммы проходили через прокси напрямую.

В чём разница между SOCKS5 и socks5h?

SOCKS5 разрешает DNS локально; socks5h разрешает его через прокси, избегая утечек DNS.

Шифрует ли SOCKS5 трафик?

Нет. SOCKS5 только маршрутизирует трафик, не шифруя полезную нагрузку; используйте TLS отдельно.

Можно ли использовать SOCKS5 для DNS-запросов?

Да, DNS-запросы проходят через SOCKS5, и socks5h — более безопасный выбор.

Почему мой клиент не может открыть UDP-сессию?

Обычно пакет не поддерживает UDP, управляющее соединение разорвано или аутентификация настроена неправильно.