SOCKS5- и SOCKS4-прокси

SOCKS-прокси позволяет программе поручить подключение к целевому серверу посреднику. Прокси открывает нужное соединение и передаёт данные в обе стороны. Программа продолжает использовать собственный протокол, поэтому такой способ подходит для веб-запросов, API-клиентов, передачи файлов и другого ПО с поддержкой SOCKS.

Для нового подключения обычно выбирают SOCKS5: он поддерживает больше форматов адресов, позволяет согласовать способ аутентификации и предусматривает передачу UDP. SOCKS4 сохраняет смысл для программ, которым нужна именно старая версия. Более общее сравнение этих протоколов с HTTP-прокси приведено в статье «SOCKS- и HTTP-прокси».

Как программа подключается через SOCKS

Представим, что программа открывает https://example.com/ через SOCKS5-прокси. Сначала она связывается с прокси и просит его подключиться к сайту, а затем обменивается данными с сайтом через готовое соединение. Это происходит в четыре этапа:

1. Программа устанавливает TCP-соединение с прокси по его доменному имени или IP-адресу и порту подключения.
2. Программа и прокси согласуют способ доступа. Если он требует учётных данных, программа передаёт их, а прокси выполняет проверку.
3. Программа отправляет команду SOCKS CONNECT с адресом и портом назначения. Прокси проверяет правила доступа, пытается подключиться к адресату и сообщает результат.
4. После успешного ответа программа начинает обмен с адресатом через прокси. Для HTTPS-сайта она устанавливает TLS-соединение с сайтом и проверяет его сертификат, после чего отправляет веб-запрос.

Два номера порта относятся к разным серверам. Например, прокси может принимать подключения по адресу proxy.example:1080, а сайт — по адресу example.com:443. Порт 1080 традиционно используется для SOCKS, но сервис вправе назначить другой. Подключаться нужно к порту, указанному для вашего прокси; этот порт не заменяет порт сайта.

При обычной передаче TCP SOCKS пересылает поток байтов программы без необходимости разбирать каждый HTTP-запрос или команду передачи файла. Программа продолжает общаться с адресатом по собственному протоколу. Поэтому один и тот же механизм SOCKS подходит как для веб-клиентов, так и для других программ.

CONNECT — команда самого SOCKS со своим форматом сообщений; она отличается от метода HTTP CONNECT. В SOCKS также есть команда BIND для программ, которым нужно обратное подключение сервера через прокси, например при активном FTP. Для неё нужна отдельная поддержка; обычные запросы к сайтам и API обходятся без BIND.

Чем отличаются SOCKS4, SOCKS4a и SOCKS5

SOCKS4 открывает TCP-соединения к IPv4-адресам. В SOCKS4a можно передать доменное имя, чтобы прокси сам нашёл его IP через DNS. SOCKS5 добавляет выбор способа аутентификации, принимает IPv4, IPv6 и доменные имена, а также предусматривает передачу UDP.

Таблица описывает возможности протоколов. Чтобы воспользоваться конкретной функцией, её должны поддерживать и клиентская программа, и прокси-сервис. Например, SOCKS5-прокси может обслуживать TCP-соединения, но не предоставлять работающую передачу UDP.

В запросе SOCKS5 можно передать IPv6-адрес, но прокси должен уметь подключиться к этому серверу по IPv6. Два соединения могут использовать разные версии IP: программа подключается к прокси по IPv4, а прокси — к целевому серверу по IPv6.

SOCKS4a — расширение SOCKS4, а не другое название любого подключения SOCKS4. Если старая программа умеет передавать только IPv4-адреса, выбор SOCKS4 не добавит ей удалённый DNS. Для SOCKS4a расширение нужно с обеих сторон. Если обе стороны поддерживают SOCKS5, обычно проще выбрать его; сам по себе переход на SOCKS4 не улучшает репутацию выходного IP или скорость.

Кто определяет IP-адрес сайта по его имени

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

При локальном DNS программа обращается к своему DNS-резолверу за адресом reports.example. Допустим, в ответ приходит 203.0.113.27: тогда программа просит SOCKS-прокси подключиться к 203.0.113.27:443. Поиск адреса уже выполнен на стороне клиента, хотя последующее соединение с сайтом проходит через прокси.

При DNS на стороне прокси программа передаёт reports.example:443, предварительно не определяя адрес этого сайта локально. Прокси получает его IP через DNS и открывает нужное соединение. Доменное имя передаётся прокси внутри запроса SOCKS.

Этот режим может помочь, если клиент не получает адрес по имени, а прокси получает. Некоторые сервисы возвращают разные IP в зависимости от DNS-сервера, поэтому перенос поиска может изменить сервер, к которому откроется соединение. Страну выходного IP прокси это не задаёт и приём запроса сайтом не гарантирует.

В curl два режима выбираются следующими командами:

curl --proxy socks5://proxy.example:1080 https://example.com/
curl --proxy socks5h://proxy.example:1080 https://example.com/

С socks5:// curl определяет адрес сайта локально, а с socks5h:// передаёт прокси имя сайта. Оба варианта используют SOCKS5. Буква h в формате URL этого клиента означает, что имя сайта будет разрешать прокси. Она не превращает SOCKS5 в HTTPS и не добавляет шифрование. В другой программе может использоваться переключатель или удалённый DNS по умолчанию. Условные имя и порт прокси нужно заменить своими, а также указать требуемые параметры аутентификации.

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

Если программе указали передавать поиск адреса прокси, а она выполнила его локально, запрошенное имя стало известно за пределами выбранного маршрута. Это утечка DNS. Шифрованный DNS защищает обмен с DNS-сервером, но сам сервер всё равно получает имя. Поиск адреса самого прокси — отдельная задача, а остальные программы сохраняют свои настройки. Удалённый DNS в одной программе не переносит к прокси все запросы устройства.

Аутентификация и шифрование

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

Невозможность согласовать метод отличается от отказа по неверному паролю: в первом случае обмена паролем ещё не было. Программа без поддержки входа по логину и паролю не сможет использовать SOCKS5-подключение, требующее эти реквизиты, только благодаря наличию пункта SOCKS5 в настройках. В SOCKS4 есть поле идентификатора пользователя, но нет такого же стандартного обмена паролем; сервер при этом может применять правила доступа.

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

При обычной пересылке через SOCKS HTTPS защищает обмен программы с сайтом — при включённой проверке сертификата и без перехвата TLS. Незашифрованный протокол приложения остаётся незашифрованным и при прохождении через прокси. Само наличие SOCKS5 или входа по паролю не обещает шифрование трафика.

Прокси всё равно знает IP подключившегося клиента, запрошенное назначение и время соединения. Адресат видит выходной IP прокси и получает предназначенные ему данные приложения. Cookies, вход в аккаунт и другие идентификаторы программы могут по-прежнему связывать действия с пользователем; смена версии SOCKS их не удаляет.

Как SOCKS5 передаёт TCP и UDP

TCP передаёт упорядоченный поток байтов. Запрос браузера, обращение к API или SSH-сеанс могут работать через TCP-соединение SOCKS, если клиент поддерживает такой путь, а прокси разрешает подключение к адресату. Успех на порту 443 одного сайта ещё не показывает, что доступен порт другой программы.

UDP передаёт отдельные датаграммы. Клиент SOCKS5 сначала открывает управляющее TCP-соединение и командой UDP ASSOCIATE запрашивает ретранслятор. Прокси возвращает его адрес и UDP-порт. Клиент отправляет туда датаграммы с SOCKS-заголовками, в которых указаны адресаты. Закрытие управляющего TCP-соединения прекращает эту UDP-пересылку. Датаграммы идут отдельно от управляющего соединения, а не внутри обычного потока SOCKS CONNECT.

Этот механизм должны поддерживать программа и сервис, а сеть должна пропускать соответствующий UDP-трафик. Например, приложение может успешно войти в аккаунт через TCP, но его голосовая, игровая или другая UDP-функция не заработает. Успешный HTTPS-запрос через SOCKS CONNECT подтверждает передачу TCP, а не работу UDP. QUIC использует UDP, но возможность работы QUIC зависит также от клиента и всего пути передачи; одной надписи SOCKS5 для такого вывода недостаточно.

Для каких задач подходит SOCKS

SOCKS полезен, когда программе нужно соединение через посредника с сохранением её собственного протокола обмена. Скрипт может обращаться к API через назначенный выходной IP, программа передачи файлов — связываться с удалённым сервером по разрешённому маршруту, а совместимое настольное приложение — работать через прокси, не являясь браузером. В каждом случае нужны поддержка SOCKS в клиенте и разрешение нужных портов назначения у сервиса.

Для повторной работы с одним аккаунтом или сервером может подходить постоянный выходной IP, а для независимых задач — сервис с ротацией. SOCKS4 и SOCKS5 не определяют этот выбор: от услуги зависят выходной адрес, тип его сети, круг пользователей и момент смены IP. Версия протокола также не служит показателем скорости; на результат влияют длина маршрута, загрузка сервера и доступная полоса.

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

Прокси, заданный внутри одной программы, обслуживает поддерживаемые соединения этой программы. Он не настраивает отдельный загрузчик или скрипт. Системные настройки прокси тоже действуют только на ПО, которое ими пользуется. Если адаптер перенаправляет соединения программы без собственной поддержки SOCKS, нужно учитывать, как он обрабатывает TCP, UDP и DNS. SOCKS не предоставляет обычную пересылку ICMP, поэтому ping не проверяет этот путь через прокси.

Параметры подключения и полезная проверка

Начните с адреса прокси, порта, версии SOCKS и способа доступа, указанных для выбранной точки подключения. Число вроде 1080 само по себе не определяет протокол. В программе нужно выбрать SOCKS, а не просто вписать тот же адрес в поле, рассчитанное только на HTTP-прокси.

Реквизиты прокси дают доступ к посреднику, а реквизиты сайта — к сайту. Это разные настройки. В curl --proxy-user передаёт учётные данные прокси, а --user — адресата. При доступе по IP белый список должен соответствовать исходному адресу клиента, который видит прокси; при смене сети этот адрес может измениться.

Выберите нужный режим DNS и проверьте исключения из проксирования. Программа может обращаться напрямую к адресам из списка исключений, даже если прокси настроен. В curl такое поведение может задавать NO_PROXY; параметр --noproxy "" очищает эти исключения для одного запуска, когда нужно целенаправленно проверить путь через прокси.

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

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

Как определить этап, на котором возникла ошибка

Различайте подключение к прокси, получение доступа, соединение с адресатом и ответ самого приложения. На этих этапах возникают разные ошибки.

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