Купить прокси SOCKS5

HTTP-прокси разбирает ваш запрос: он видит метод, путь и заголовки, может их дополнить и решает, что отправить дальше. SOCKS5 работает уровнем ниже и в содержимое не заглядывает. Он открывает канал до нужного хоста и порта и дальше просто переносит байты в обе стороны.

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

Есть и обратная сторона. Раз SOCKS5 не разбирает запрос, он не умеет ничего в него подставлять и не кеширует ответы. Для сбора данных это плюс: трафик доходит в том виде, в каком его отправил ваш софт, без лишних заголовков и без вмешательства посредника.

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

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

Проверить это просто: откройте любой сервис проверки DNS через настроенное соединение и посмотрите, чьи серверы он показывает. Если там ваш домашний провайдер, разрешение идёт мимо прокси, и в настройках надо включить удалённый DNS.

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

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

Важная деталь: поддержка UDP через прокси SOCKS5 зависит не только от сервера, но и от клиента. Многие программы объявляют поддержку SOCKS5, но реализуют только TCP-часть, и UDP у них идёт мимо прокси напрямую. Проверять это надо на конкретном софте.

Для задач сбора данных UDP обычно не требуется: HTTP и HTTPS работают поверх TCP. Но если прокси SOCKS5 берутся под мессенджеры или клиентские приложения, наличие UDP становится решающим.

Протокол предусматривает переговоры о методе авторизации в самом начале соединения. Клиент присылает список методов, которые он умеет, сервер выбирает один и отвечает. Базовых вариантов два: без авторизации и по паре логин и пароль.

Когда доступ выдан в формате IP:PORT, используется первый метод, а проверка происходит на другом уровне: сервер сверяет адрес, с которого пришло соединение, со списком разрешённых. Поэтому такой формат и требует привязки, без неё прокси не поймёт, кто к нему стучится.

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

Если в программе есть поля для логина и пароля, но подключение не идёт, стоит проверить именно порядок: некоторые клиенты отправляют учётные данные только после явного включения соответствующего пункта в настройках прокси.