HTTP, HTTPS, SOCKS4 и SOCKS5: чем отличаются протоколы прокси

Разница сидит в том, на каком уровне посредник вмешивается в обмен. HTTP и HTTPS работают на прикладном уровне и разбирают сам запрос вместе с заголовками, SOCKS4 и SOCKS5 работают на уровне соединения и передают байты дальше, не заглядывая внутрь.

Отсюда вытекает всё остальное: какие программы примут какой вариант, как выглядит строка подключения, где резолвится доменное имя и что посредник вообще способен увидеть по дороге. Ниже разобраны четыре протокола по порядку, показаны схемы строк http://, https://, socks4://, socks5:// и socks5h://, приведены рабочие команды curl и сведена сравнительная таблица по всем признакам сразу.

Уровни: где именно стоит посредник

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

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

Разница уровня объясняет странность, которая сбивает новичков. Один и тот же адрес и порт из списка работает и как HTTP-посредник, и как SOCKS5: сервер понимает, чего от него хотят, по первым байтам соединения. Мы выдаём в пакете сразу IPv4 с HTTP и HTTPS плюс SOCKS4 и SOCKS5, поэтому переключение протокола в программе не требует ни новых адресов, ни доплаты.

HTTP-прокси: посредник читает запрос

При работе по HTTP программа отправляет посреднику запрос с абсолютным адресом в стартовой строке. Выглядит это так:

GET http://example.com/catalog/page-2 HTTP/1.1
Host: example.com
User-Agent: Mozilla/5.0
Proxy-Authorization: Basic dXNlcjU1MjE6cGYzOWtk
Accept-Encoding: gzip, deflate

Посредник видит здесь всё: метод, полный путь, строку агента, кодировки, cookie, тело POST-запроса. Он способен добавить свои заголовки, снять свои служебные поля перед отправкой и вернуть ответ обратно программе. Именно поэтому у HTTP-варианта есть собственный код отказа: 407 Proxy Authentication Required приходит от посредника, целевой сервер о запросе при этом даже не узнаёт.

Такая осведомлённость даёт удобства. HTTP-прокси умеет кешировать ответы, писать журнал по адресам, работать с заголовком Proxy-Authorization отдельно от авторизации на целевом сайте. Браузеры и парсеры выросли вокруг этого протокола, поэтому поддержка у него самая широкая: поле «HTTP-прокси» есть буквально везде.

# обычный запрос через HTTP-посредник
curl -x http://185.24.87.14:8000 http://example.com/robots.txt

# то же самое с учётными данными пакета
curl -x http://user5521:[email protected]:8000 http://example.com/robots.txt

# посмотреть служебный обмен целиком
curl -v -x http://185.24.87.14:8000 http://example.com/ 2>&1 | head -n 25

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

HTTPS через прокси: туннель поверх того же порта

Зашифрованный трафик посредник разобрать не может по определению: ключи сессии знают только браузер и целевой сервер. Поэтому для HTTPS схема меняется. Программа сначала просит посредника открыть сквозной канал методом CONNECT, получает подтверждение и дальше гонит по этому каналу байты TLS, которые посредник переносит вслепую.

CONNECT example.com:443 HTTP/1.1
Host: example.com:443
Proxy-Authorization: Basic dXNlcjU1MjE6cGYzOWtk

HTTP/1.1 200 Connection established

После строки 200 Connection established посредник теряет доступ к содержимому. Он знает имя хоста и порт из преамбулы, знает объём переданных байтов и длительность сессии. Пути, заголовки, cookie и тело ответа остаются внутри шифрования. Механика самого туннеля разобрана отдельно в материале про туннель CONNECT и работу с шифрованием, здесь достаточно самого факта.

Практический вывод для настройки: отдельного «HTTPS-порта» у посредника обычно нет. Тот же адрес и тот же порт принимают и обычные запросы, и запросы на открытие туннеля, сервер различает их по методу. Именно поэтому в конфигах библиотек ключ https часто указывает на строку со схемой http, и это правильная запись.

# HTTPS-адрес через тот же HTTP-посредник, туннель поднимается сам
curl -x http://user5521:[email protected]:8000 https://ifconfig.me

# увидеть строку установки туннеля
curl -v -x http://185.24.87.14:8000 https://example.com/ 2>&1 | grep -i 'CONNECT\|established'

Схема https:// в самом ключе -x означает другое: шифрование самого канала до посредника. Такой режим поддерживают немногие программы, и в списке адресов он отражается настройкой на стороне сервера, схема строки при этом остаётся прежней. Состав пакета с шифрованным вариантом описан на странице, где собран доступ по HTTPS с туннелем до целевого узла.

SOCKS: посредник на уровне соединения

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

Из этого следуют три свойства, ради которых SOCKS и берут.

Первое: протокол внутри не имеет значения. По SOCKS ходят HTTP, SMTP, IMAP, POP3, FTP, обмен внутри игровых клиентов, произвольные бинарные протоколы собственной разработки. Посреднику всё равно, он переносит байты.

Второе: порт назначения любой. HTTP-посредник обычно ограничен разумным набором портов, сокетный вариант открывает соединение на 25, 587, 993, 5222 или 27015 без особых настроек.

Третье: заголовков он не добавляет никаких, потому что заголовков в его картине мира просто нет. Всё, что уходит на целевой сервер, приходит от программы и остаётся в том виде, в каком она это отправила.

# SOCKS5 с учётными данными
curl -x socks5://user5521:[email protected]:8000 https://ifconfig.me

# SOCKS4, учётных данных в протоколе нет
curl -x socks4://185.24.87.14:8000 http://example.com/

# проверка произвольного порта, который HTTP-вариант обычно не пропускает
curl -x socks5h://user5521:[email protected]:8000 -v smtp://smtp.example.com:587

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

SOCKS4 и SOCKS5: три реальных отличия

Версии различаются тремя вещами, и все три ощущаются в работе.

Доступ по логину и паролю

SOCKS4 умеет передавать только идентификатор пользователя, поле в преамбуле короткое и проверку пароля не подразумевает. SOCKS5 описывает отдельный этап согласования метода: клиент перечисляет, что умеет, сервер выбирает, и при выборе метода с учётными данными идёт обмен парой логина и пароля. Поэтому строка socks5://user:pass@host:port работает, а socks4://user:pass@host:port пару молча теряет.

Доменные имена

SOCKS4 принимает в преамбуле адрес в виде четырёх байтов, то есть готовый IPv4. Программа обязана разрешить имя сама. SOCKS5 добавил тип адреса «доменное имя», и клиент отправляет строку example.com целиком, а разрешением занимается сервер на выходе. Это меняет картину запросов к службе имён и закрывает целый класс расхождений между тем, что видит программа, и тем, куда она реально попадает.

UDP

SOCKS4 переносит только TCP. SOCKS5 описывает отдельную команду UDP ASSOCIATE, через которую можно переносить датаграммы. Что именно из этого работает на практике и какие программы умеют пользоваться этим механизмом, разобрано отдельно в материале про TCP и UDP через SOCKS5.

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

Проверить, какая версия реально согласовалась, проще всего подробным выводом curl. При SOCKS5 в логе видна строка о выборе метода доступа, при SOCKS4 сразу идёт запрос соединения. Мы смотрим на эту строку каждый раз, когда пара логина и пароля вроде бы указана верно, а сервер отвечает отказом: половина таких случаев объясняется схемой socks4://, оставшейся в конфиге с прошлого прогона. Обе версии открыты в пакете, где мы держим сокетный доступ к пулу IPv4.

Схемы строк подключения и разница между socks5 и socks5h

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

Буква h в конце socks5h расшифровывается как hostname и означает ровно одно: доменное имя уезжает на сервер строкой и разрешается там. При схеме socks5:// библиотека сначала спрашивает у своей службы имён, какой адрес стоит за example.com, и только потом просит посредника соединиться с полученным адресом.

Разница видна в двух местах. Во-первых, запрос к службе имён уходит с рабочей машины, поэтому картина обращений на стороне провайдера отличается от картины соединений через пул. Во-вторых, целевой домен может отдавать разные адреса в зависимости от того, откуда пришёл вопрос: имя разрешается рядом с машиной, соединение открывается из пула, и программа попадает не на тот узел, который отвечает посреднику.

# имя разрешает локальная машина
curl -x socks5://user5521:[email protected]:8000 https://example.com/

# имя разрешает сервер на выходе
curl -x socks5h://user5521:[email protected]:8000 https://example.com/

# короткая проверка: совпадает ли адрес на выходе с ожидаемым
curl -s -x socks5h://user5521:[email protected]:8000 https://ifconfig.me

В python отличие выражается той же буквой внутри словаря схем.

proxies_local = {'https': 'socks5://user5521:[email protected]:8000'}
proxies_remote = {'https': 'socks5h://user5521:[email protected]:8000'}

Мы советуем ставить socks5h везде, где программа это принимает. Стоит это ничего, поведение становится предсказуемее, и вопрос «почему адрес показывается верно, а сайт ведёт себя странно» снимается сам собой.

Полная сравнительная таблица по четырём протоколам

Ниже сведены все признаки, по которым протоколы расходятся в реальной настройке.

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

Строку про коды отказа тоже стоит прочитать внимательно. У прикладного варианта отказ приходит текстом со статусом 407 и заголовком Proxy-Authenticate, его видно в любом логе и в любой панели разработчика. У сокетного варианта ответ бинарный, один байт кода, и программы переводят его в собственные сообщения вида «connection refused by proxy» либо «general SOCKS server failure». Из-за этого одна и та же причина отказа выглядит по-разному в зависимости от схемы, и мы всегда просим уточнять протокол, когда разбираем обращение по конкретному прогону.

Ещё один практический момент касается заголовков. Прикладной посредник способен добавить служебные поля вроде Via или X-Forwarded-For, сокетный такой возможности лишён по устройству протокола. Что именно уходит на целевой сервер в каждом режиме, проверяется одним обращением к сервису, который печатает полученные заголовки обратно.

Что выбирать под браузер, парсер, почту и произвольную программу

Выбор сводится к тому, что принимает софт и какой порт ему нужен.

Браузер. Настройки браузера принимают оба варианта. HTTP покрывает обычный сёрфинг и любые обращения к сайтам, включая HTTPS через туннель. SOCKS5 берут, когда важно, чтобы имена разрешались на выходе: в Chromium это включается ключом запуска, в Firefox галочкой в окне настроек.

# Chromium через SOCKS5 с разрешением имён на выходе
chromium --proxy-server="socks5://185.24.87.14:8000" \
  --host-resolver-rules="MAP * ~NOTFOUND , EXCLUDE 185.24.87.14"

Парсер. A-Parser, Key Collector и подобные программы работают по HTTP и HTTPS, потому что собирают именно веб-страницы. Список подставляется целиком, потоки считаются по пакету, схема остаётся http://. Сокетный вариант там тоже принимается, выигрыша в скорости он не даёт, зато закрывает вопрос с обращениями к службе имён.

Почтовый клиент. SMTP, IMAP и POP3 ходят по своим портам, поэтому здесь берут SOCKS5. Прикладной посредник почтовые протоколы не понимает: он разбирает HTTP, и байты SMTP для него бессмысленны. Порядок отправки писем через сокетный доступ подробно разобран в материале про отправку почты через прокси.

Произвольная программа. Всё, что открывает TCP-соединение на нестандартный порт, идёт через SOCKS5. Игровые клиенты, обменники сообщений, самописные сервисы, клиенты баз данных. Если у программы есть поле «SOCKS-прокси», туда кладётся хост, порт и пара логина и пароля из списка.

Все четыре протокола входят в один пакет и работают на одном пуле примерно из 12 000 адресов, поэтому смена протокола в софте не требует ни новой покупки, ни нового списка. Состав пакета целиком описан на странице, где оформляется доступ к пулу IPv4 с полным набором протоколов.

Как проверить, что выбранный протокол реально работает

Проверка занимает три команды. Сначала обращение к сервису, который возвращает адрес: ответ должен показать адрес из пула. Затем то же самое по второй схеме, чтобы убедиться, что оба режима подняты. Наконец обращение к целевому домену с выводом кода ответа.

# адрес на выходе по HTTP
curl -s -x http://user5521:[email protected]:8000 https://ifconfig.me

# адрес на выходе по SOCKS5
curl -s -x socks5h://user5521:[email protected]:8000 https://ifconfig.me

# код ответа целевого домена, без тела
curl -s -o /dev/null -w '%{http_code}\n' \
  -x socks5h://user5521:[email protected]:8000 https://example.com/

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

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

Частые вопросы

Какой тип прокси вы даёте?

В пакете IPv4 и SOCKS5 доступны SOCKS-4 и SOCKS-5 на выбор, рекомендуем SOCKS-5. Прикладные варианты HTTP и HTTPS работают на тех же адресах, поэтому переключение протокола делается настройкой в программе.

Нужно ли покупать отдельный пакет под SOCKS5?

Отдельная покупка не требуется. Протоколы IPv4, HTTP, HTTPS, SOCKS4 и SOCKS5 входят в один пакет, список адресов при смене протокола остаётся прежним, меняется только схема в строке подключения.

Чем проверять прокси после настройки?

Рекомендуем чекер от Zennolab, у него есть демонстрационная версия. Он проходит список пачкой, показывает отвечающие строки, тип посредника и время отклика. Одиночную проверку удобно делать командой curl с ключом -x и нужной схемой.

Что входит в прокси-пул?

Около 12 000 активных IPv4 и SOCKS5. Стандартные пакеты дают до 1000 потоков, корпоративный до 3000, доступ к пулу открыт клиентам сервиса. Список адресов обновляется в режиме реального времени и забирается ссылкой или файлом.

Разбор протоколов продолжается в соседних материалах раздела: как устроен протокол SMTP с разбором пути письма, порты 25, 465 и 587 и выбор между ними, приём почты по IMAP и POP3 через сокетный доступ. Когда протокол выбран, поля строки подключения разложены по частям в материале про разбор строки подключения.