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:pf39kd@185.24.87.14: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:pf39kd@185.24.87.14: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:pf39kd@185.24.87.14:8000 https://ifconfig.me

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

# проверка произвольного порта, который HTTP-вариант обычно не пропускает
curl -x socks5h://user5521:pf39kd@185.24.87.14: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:pf39kd@185.24.87.14:8000 https://example.com/

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

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

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

proxies_local = {'https': 'socks5://user5521:pf39kd@185.24.87.14:8000'}
proxies_remote = {'https': 'socks5h://user5521:pf39kd@185.24.87.14: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:pf39kd@185.24.87.14:8000 https://ifconfig.me

# адрес на выходе по SOCKS5
curl -s -x socks5h://user5521:pf39kd@185.24.87.14:8000 https://ifconfig.me

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

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

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

Что спрашивают

Это HTTP или SOCKS5?

В пакете 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 через сокетный доступ. Когда протокол выбран, поля строки подключения разложены по частям в материале про разбор строки подключения.