SOCKS4 и SOCKS5: сравнение аутентификации, DNS и UDP

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

Важно различать, что определяет протокол и что реализует ваш сервис. Одна лишь метка SOCKS5 не подтверждает, что конкретный адрес подключения принимает UDP, предоставляет выходной адрес IPv6 или поддерживает все методы аутентификации.

SOCKS4 и SOCKS5 вкратце

Оба протокола позволяют приложению поручить прокси-серверу установить соединение. Форматы запросов и поддерживаемые функции различаются. При сравнении учитывайте SOCKS4a, иначе вывод о поддержке DNS будет неполным.

Возможность	SOCKS4	SOCKS4a	SOCKS5
Запросы на TCP-соединение	Да	Да	Да
Команда UDP-ретрансляции	Нет	Нет	Определяется протоколом
Доменное имя, отправляемое на прокси	Нет	Да	Да
Формат адреса назначения IPv6	Нет	Нет	Да
Согласование метода аутентификации	Нет	Нет	Да
Субпереговоры по логину и паролю	Не определено	Не определено	Определяется отдельно в RFC 1929
Типичная причина выбрать	Совместимость со старым клиентом	Старый клиент, требующий DNS на стороне прокси	Поддерживаемое современное приложение

Это возможности протокола, а не обещание относительно сервиса какого-либо провайдера. Эти Спецификация SOCKS5 определяет типы адресов, согласование аутентификации и команды соединения. Прежде чем полагаться на ту или иную функцию, убедитесь, какое подмножество поддерживает ваш адрес подключения.

Чем отличается аутентификация

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

SOCKS4 включает поле USERID, но не определяет обмен именем пользователя и паролем, как в SOCKS5. Управление доступом зависит от реализации. Было бы неточно утверждать, что все серверы SOCKS4 используют только списки разрешённых IP-адресов или что USERID равнозначен входу, защищённому паролем.

При вводе данных доступа к прокси используйте формат, который требует приложение. В некоторых инструментах есть отдельные поля для хоста, порта, имени пользователя и пароля. Другие ожидают строку подключения. Строка с учётными данными, скопированная не в то поле, может не сработать, даже если аккаунт действителен.

Разделяйте аутентификацию и шифрование. Метод с логином и паролем, описанный в RFC 1929 не шифрует обмен паролем. Сам по себе SOCKS5 не заменяет HTTPS или другой защищённый транспорт. HTTPS-адресат защищает соединение приложения с помощью TLS; это не защищает автоматически отдельный незашифрованный обмен логином для прокси.

Разрешение DNS и исключение SOCKS4a

В базовом SOCKS4 запрос на подключение содержит IPv4-адрес назначения. Клиенту нужен этот адрес до отправки запроса. SOCKS4a расширяет запрос, чтобы клиент мог отправить доменное имя, которое сервер разрешит самостоятельно, как это Спецификация SOCKS4a explains.

SOCKS5 также поддерживает адресацию по доменному имени. Используется ли она в приложении, зависит от его настроек и реализации. Выбор SOCKS5 не доказывает, что каждый DNS-запрос приложения проходит через прокси.

Например, curl различает socks5://, при котором целевой адрес разрешается локально, с socks5h://, при котором прокси просят выполнить разрешение имени. В других приложениях этот выбор может быть представлен флажком или выполняться внутри. Проверьте документацию приложения, а не считайте, что такое именование универсально.

Удалённое разрешение имён может быть полезно, когда у прокси есть подходящее представление о DNS узла назначения. Оно не гарантирует анонимность или доступ к сайту с ограничениями. Поведение DNS — лишь одна часть соединения, и приложение может выполнять дополнительные запросы за пределами этого соединения.

UDP и IPv6 требуют поддержки с обеих сторон

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

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

С IPv6 связано аналогичное различие. Протокол может представлять адрес назначения IPv6, но это не определяет сетевое подключение прокси-сервера или тип выходного адреса, который предоставляет ваш тариф. Если для вашей задачи требуется IPv6, подтвердите это явно и протестируйте нужный адрес назначения.

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

Выберите и протестируйте совместимое соединение

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

Проверяйте по одной переменной за раз:

1. Сверьте хост и порт с данными вашего текущего подключения.
2. Выберите в приложении протокол прокси, указанный в документации.
3. Введите учётные данные или настройте необходимый список разрешённых IP.
4. Загрузите безопасную тестовую страницу и проверьте отображаемый публичный адрес.
5. Отдельно проверьте реальное приложение, включая необходимое поведение DNS, UDP или IPv6.

Успешная проверка публичного IP подтверждает, что именно этот тестовый запрос прошёл через прокси. Она не доказывает, что через прокси работает каждое приложение или каждый протокол на вашем устройстве. Наш руководство по проверке прокси описывает более широкий процесс проверки.

При сравнении производительности сохраняйте неизменными назначение, сеть и нагрузку. Одна лишь версия протокола не является надёжным показателем рейтинга скорости. На результат могут влиять установление соединения, нагрузка сервера, расстояние и время ответа целевого ресурса. Не меняйте протокол и сервер одновременно, если хотите понять, какое изменение помогло.

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

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

Само по себе — нет. Используйте подходящий защищённый протокол прикладного уровня, например HTTPS, и проверьте, как защищено соединение с прокси. Имя пользователя и пароль аутентифицируют доступ, но не шифруют соединение автоматически.

Может ли приложение, поддерживающее только SOCKS4, использовать адрес подключения SOCKS5?

Только если есть явно поддерживаемый путь совместимости, например адрес подключения, который принимает оба протокола. Совпадения полей хоста и порта недостаточно. Проверьте совместимость с приложением и сервисом, а не предполагайте её.

Всегда ли SOCKS5 разрешает DNS удалённо?

Нет. Он может отправить прокси доменное имя, но то, как сформировать запрос, решает клиент. Проверьте настройку удалённого DNS в приложении или описание его поведения в документации.

Нужно ли заменять рабочую настройку SOCKS4?

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

Готовы выбрать подключение? Открыть Proxyca в Telegram чтобы посмотреть доступные услуги и проверить, какие функции протокола нужны вашему приложению.