HTTP или SOCKS5: как выбрать протокол proxy?

Протокол — отдельный слой, не связанный с типом IP. Правильный residential IP с неправильным протоколом всё равно даёт ошибку «proxy не работает». В этом руководстве сравниваем, что каждый протокол отправляет по сети, где резолвится DNS, как ведут себя UDP и заголовки, насколько верны утверждения о скорости и какие инструменты что поддерживают. В примерах используется gateway WeProxy gw.weproxy.com.tr:8989; USER и PASSWORD — данные из вашей панели.

Чем HTTP proxy отличается от SOCKS5?

Главное отличие — насколько proxy понимает трафик. HTTP proxy читает HTTP-сообщения: при обычном HTTP он видит URL и заголовки, при HTTPS — только целевой хост и порт. SOCKS5 не интерпретирует никакой прикладной протокол: он получает адрес назначения и копирует байты в обе стороны.

Последнюю строку часто упускают. Ни один из протоколов не шифрует соединение между клиентом и proxy. Для HTTPS-целей содержимое защищено TLS, но учётные данные proxy и имя целевого хоста доходят до proxy в открытом виде. Если шифровать нужно весь путь от устройства до точки выхода, нужен VPN; разница в охвате и шифровании сведена в таблицу в сравнении proxy и VPN.

Как работает HTTP proxy?

С HTTP proxy клиент открывает TCP-соединение не с целевым сайтом, а с proxy, и отправляет запрос ему. Формат запроса зависит от того, http:// цель или https://.

Обычный HTTP: абсолютный URL

Для цели без TLS клиент пишет в строке запроса не только путь, а абсолютный URL. В RFC 9112 это называется absolute-form:

GET http://example.com/products?id=42 HTTP/1.1
Host: example.com
Proxy-Authorization: Basic VVNFUjpQQVNTV09SRA==

Proxy читает URL, сам резолвит example.com, подключается к цели и возвращает ответ. В этой модели proxy видит запрос целиком: путь, параметры, cookies и тело. Значение Proxy-Authorization — это лишь кодировка Base64, а не шифрование; VVNFUjpQQVNTV09SRA== декодируется в USER:PASSWORD.

HTTPS: туннель CONNECT

Для HTTPS-целей клиент запрашивает у proxy туннель методом CONNECT из RFC 9110:

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

HTTP/1.1 200 Connection established

После ответа 200 соединение превращается в «сырую» TCP-трубу. Клиент проводит TLS-рукопожатие с целью напрямую внутри этой трубы. Дальше proxy передаёт только зашифрованные байты и не видит ни путь URL, ни заголовки, ни тело. Ошибка аутентификации на этом этапе возвращается как 407, недоступная цель — как 502.

CONNECT не ограничен HTTP: теоретически он может открыть туннель на любой TCP-порт. На практике многие proxy разрешают CONNECT только на определённые порты, например 443. Поэтому для TCP-задач вне HTTP SOCKS5 — более предсказуемый путь.

Как работает SOCKS5?

Соединение SOCKS5 состоит из трёх шагов: выбор метода, аутентификация и команда. Все они — бинарные сообщения без HTTP-заголовков.

Рукопожатие и аутентификация (RFC 1928 и RFC 1929)

Вот байты, которые отправляет клиент при подключении к HTTPS-сайту с логином и паролем:

Клиент → Proxy : 05 02 00 02          VER=5, 2 метода: 0x00 (без аутентификации), 0x02 (логин/пароль)
Proxy → Клиент : 05 02                выбран 0x02
Клиент → Proxy : 01 04 "USER" 08 "PASSWORD"   согласование по RFC 1929
Proxy → Клиент : 01 00                аутентификация успешна
Клиент → Proxy : 05 01 00 03 0b "example.com" 01 bb   CONNECT, ATYP=доменное имя, порт 443
Proxy → Клиент : 05 00 00 01 <BND.ADDR> <BND.PORT>    REP=0x00, соединение готово

Если proxy не принимает ни один из предложенных методов, он возвращает 0xFF и закрывает соединение. По RFC 1929 логин и пароль передаются открытым текстом — это не слабее и не сильнее Base64 в HTTP. В недоверенной сети вместо учётных данных можно использовать IP whitelist. В тарифах WeProxy аутентификация по логину/паролю и по IP whitelist работает и через HTTP, и через SOCKS5.

Команды и типы адресов

RFC 1928 определяет три команды и три типа адресов:

На неподдерживаемую команду proxy отвечает 0x07, на неподдерживаемый тип адреса — 0x08. Полный список кодов ответа и их типичные причины — в руководстве по кодам ошибок proxy.

Где резолвится DNS: socks5 или socks5h?

У HTTP proxy имя целевого хоста передаётся proxy внутри запроса (CONNECT example.com:443 или абсолютный URL), и резолвит его proxy. Корректный клиент не делает локальный DNS-запрос для цели.

В SOCKS5 решение принимает клиент. Если клиент сам резолвит имя и отправляет IP с ATYP 0x01, DNS-запрос уходит на ваш собственный резолвер. Если он отправляет имя с ATYP 0x03, резолвит proxy. В curl и Python эта разница выражается именем схемы:

• socks5:// — в большинстве клиентов локальный резолвинг. Запрос уходит на DNS провайдера или офиса с вашим реальным IP.
• socks5h:// — имя хоста передаётся proxy («h» = hostname). Резолвинг происходит на стороне выхода.

socks5h — не отдельный протокол, а использование ATYP 0x03 того же RFC 1928. У локального резолвинга два побочных эффекта. Первый — DNS leak. Второй — географическая несогласованность: сайт за CDN возвращает IP рядом с вашим местоположением, и proxy подключается к этому далёкому адресу. Тест и способы исправления подробно описаны в руководстве по DNS leak.

Какой протокол передаёт UDP-трафик?

HTTP proxy не передаёт UDP. CONNECT — это TCP-туннель; QUIC (HTTP/3) и игровой трафик через него не проходят. Поэтому браузеры за proxy обычно используют не HTTP/3, а HTTP/2 или HTTP/1.1 поверх TCP.

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

Команда описана в RFC, но включена не у каждого провайдера и не в каждом тарифе. В WeProxy продукт статический residential IPv4 proxy предлагает SOCKS5 + UDP в локациях за пределами Турции; локация Турция — это HTTP и обычный SOCKS5. Узел без поддержки UDP отклоняет запрос UDP ASSOCIATE кодом 0x07. Подробности для игр, VoIP и real-time приложений — в руководстве по UDP proxy.

Меняет ли proxy заголовки?

При обычных HTTP-запросах HTTP proxy находится внутри сообщения и может добавлять заголовки. RFC 9110 определяет заголовок Via для пересылающих посредников; reverse proxy и некоторые корпоративные proxy также добавляют X-Forwarded-For или Forwarded. Большинство анонимных forward proxy эти заголовки не отправляют, но всё равно проверьте свой выход через echo-эндпоинт.

С HTTPS-запросами всё иначе. После CONNECT трафик зашифрован, поэтому proxy не может трогать заголовки, идущие к цели. Целевой сайт видит только заголовки, которые отправил ваш клиент.

SOCKS5 никогда не добавляет и не читает заголовки. Это часто подают как преимущество в «приватности», но в эпоху HTTPS оба протокола приходят к одному: какие заголовки видит цель, решает ваш код. Согласованность User-Agent, Accept-Language и cookies важнее протокола.

SOCKS5 быстрее HTTP proxy?

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

TCP-соединение с proxy в обоих случаях стоит 1 RTT. Дальше для HTTPS-цели HTTP proxy добавляет 1 RTT на один обмен CONNECT. SOCKS5 с логином/паролем добавляет 3 RTT: выбор метода, аутентификация и CONNECT. Если proxy в 50 мс от вас, это примерно 100 мс дополнительного ожидания на каждое новое соединение. С аутентификацией по IP whitelist шаг аутентификации исчезает, и разница сокращается до 1 RTT.

И эта разница видна только на новых соединениях. В клиенте с keep-alive и пулом соединений цена платится на первом запросе. Реальную скорость определяют другие факторы: тип выходного IP и его удалённость от цели, канал residential-устройства, время ответа сайта и ваши настройки параллельности. Утверждение «SOCKS5 анонимнее» неверно по той же причине: анонимность определяют DNS, WebRTC и поведение заголовков, а не название протокола.

Какие инструменты поддерживают какой протокол?

Часто выбор делает за вас поддержка в инструменте. Таблица ниже описывает поведение распространённых клиентов по умолчанию:

Отсутствие аутентификации SOCKS5 в Chromium — самое частое препятствие на практике. Если передать в Puppeteer или Selenium SOCKS5 с логином и паролем, соединение не установится. Решение — использовать HTTP proxy или добавить IP вашего сервера в whitelist в панели и подключаться к SOCKS5 без учётных данных.

Разные инструменты ждут одни и те же данные в разных форматах: ip:port:user:pass, user:pass@host:port или URL со схемой. Вместо ручной конвертации используйте конвертер форматов proxy.

Как использовать HTTP и SOCKS5 в cURL и Python?

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

cURL

# HTTP proxy: туннель CONNECT для HTTPS-цели
curl -sS -x "http://USER:[email protected]:8989" https://api.ipify.org
echo

# SOCKS5, DNS на стороне proxy (рекомендуется)
curl -sS -x "socks5h://USER:[email protected]:8989" https://api.ipify.org
echo

# SOCKS5, DNS резолвится локально (риск утечки)
curl -sS --socks5 "USER:[email protected]:8989" https://api.ipify.org
echo

# Чтобы увидеть рукопожатие
curl -v -x "socks5h://USER:[email protected]:8989" https://api.ipify.org

Схема в URL proxy описывает протокол proxy, а не цели. Даже когда вы идёте на HTTPS-сайт через HTTP proxy, схема остаётся http://. Если в пароле есть @, : или /, примените percent-encoding. При неудачном SOCKS-рукопожатии curl возвращает ошибку (97).

Python

import requests

GATEWAY = "gw.weproxy.com.tr:8989"
AUTH = "USER:PASSWORD"

profiles = {
    "http": f"http://{AUTH}@{GATEWAY}",
    "socks5h": f"socks5h://{AUTH}@{GATEWAY}",  # pip install "requests[socks]"
}

session = requests.Session()
session.trust_env = False  # чтобы переменная HTTP_PROXY не перезаписала словарь

for name, proxy in profiles.items():
    try:
        r = session.get(
            "https://api.ipify.org?format=json",
            proxies={"http": proxy, "https": proxy},
            timeout=(10, 30),
        )
        print(name, r.status_code, r.json()["ip"])
    except requests.exceptions.RequestException as e:
        print(name, "ошибка:", e)

Если оба профиля возвращают один и тот же выходной IP, работают оба протокола. Какой использовать, дальше зависит от инструмента и задачи. Детали настройки — на страницах интеграции с Python и интеграции с Node.js. Как задать оба профиля в requests, httpx и aiohttp, показано рядом в руководстве по proxy в Python. Корректность ответа proxy по протоколу и аутентификации можно также проверить через proxy checker.

Какой протокол выбрать для какой задачи?

Короткое правило: если задача — веб или API, начинайте с HTTP; если есть TCP вне HTTP, UDP или приложение без настройки proxy, выбирайте SOCKS5. В инструментах, поддерживающих оба варианта, HTTP proxy даёт меньше RTT и более широкую совместимость.

Со стороны продуктов поддержка протоколов зависит от тарифа; перед покупкой проверьте технические характеристики на странице продукта. Rotating residential IPv4 proxy поддерживает HTTP и SOCKS5 и подходит для веб-задач: scraping, SEO и автоматизации. Для игр и real-time задач с UDP смотрите локации с UDP у продукта статический residential IPv4 proxy. Во всех тарифах неограниченное число потоков и одновременных сессий; стартовые пакеты указаны на страницах продуктов. Подробности по сценариям — на страницах web scraping и gaming proxy.

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

HTTP proxy создан для веба, SOCKS5 — для всего остального. Начинайте с того, что поддерживает ваш инструмент, для SOCKS5 пишите схему socks5h, а если нужен UDP, заранее проверьте поддержку UDP ASSOCIATE в тарифе.