HTTP или SOCKS5: какой протокол прокси выбрать

У резидентских и мобильных прокси Proxeta два порта: 8080 для HTTP и 1080 для SOCKS5. Логин, пароль и пул адресов у них общие, так что выбор протокола зависит не от тарифа, а от того, что умеет ваша программа. Ниже — как работает каждый протокол, кто в нём разрешает имена сайтов, почему через шлюз не проходят UDP и QUIC и что выбрать для типичных задач.

Как работает HTTP-прокси

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

Для сайта по https:// программа сначала просит прокси открыть туннель:

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

Прокси соединяется с example.com по порту 443 и отвечает кодом 200, после чего программа шифрует трафик прямо с сайтом. Прокси видит имя сайта и объём данных, но не адреса страниц и не их содержимое. Если логин или пароль не подошли, прокси отвечает кодом 407 Proxy Authentication Required.

Логин и пароль передаются в заголовке Proxy-Authorization в кодировке base64. Это не шифрование: строка из примера раскодируется в login-country-us:password. Логины в примерах сокращены: в строке из личного кабинета есть ещё параметр фильтра, например -filter-medium, поэтому копируйте её целиком.

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

SOCKS5 не разбирает HTTP. Программа здоровается с прокси, проходит вход по логину и паролю (это отдельный шаг протокола, описанный в RFC 1929) и просит соединить её с хостом и портом. Дальше прокси передаёт байты в обе стороны и не знает, что внутри.

Логин и пароль в SOCKS5 тоже идут открытым текстом. Ни SOCKS5, ни HTTP-прокси со схемой http:// не шифруют соединение между вами и прокси, поэтому содержимое защищает только HTTPS между программой и сайтом.

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

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

DNS: кто превращает имя сайта в адрес

У HTTP-прокси вопрос решён протоколом: в запросе CONNECT и в запросе к http://-сайту уходит имя, а адрес находит прокси.

В SOCKS5 программа может передать либо имя, либо адрес, который уже нашла сама. В curl и requests это задаёт схема: с socks5h:// имя разрешает прокси, с socks5:// — ваше устройство. Chromium с SOCKS5-прокси передаёт имя. В других программах ищите в настройках пункт вроде «DNS через прокси».

Почему это важно:

• Локация. Ответ DNS зависит от того, где находится резолвер. Крупные сайты и CDN отдают адрес сервера рядом с ним, поэтому при разрешении на вашем устройстве запрос может уйти к серверу для вашего региона, а не для региона выхода.
• Приватность. Если имена разрешает ваше устройство, ваш DNS-провайдер видит, какие сайты вы открываете через прокси.
• Ошибки. Если ваше устройство не может разрешить имя, запрос с socks5:// оборвётся ещё до соединения с сайтом.

Почему UDP и QUIC не проходят через шлюз

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

Что из этого следует на практике:

• HTTP/3 через прокси не работает. HTTP/3 идёт поверх QUIC, а QUIC — поверх UDP. Браузеры и HTTP-библиотеки через прокси открывают сайты по HTTP/2 или HTTP/1.1 поверх TCP.
• Звонки, игры и другие UDP-программы через этот шлюз не пойдут. В зависимости от программы такой трафик либо не заработает, либо пойдёт напрямую, мимо прокси.
• Отдельные DNS-запросы по UDP через шлюз не передаются. Отдайте разрешение имён прокси: у HTTP это происходит само, у SOCKS5 — со схемой socks5h://.

Порты и строка прокси в Proxeta

Строки HTTP и SOCKS5 с одинаковыми настройками отличаются только портом, логин и пароль те же. Две команды ниже проверяют один и тот же логин по двум протоколам:

curl -sS --max-time 30 -w '\n' \
  --proxy http://proxy.example.invalid:8080 \
  --proxy-user 'login-country-us:password' \
  https://api64.ipify.org

curl -sS --max-time 30 -w '\n' \
  --proxy socks5h://proxy.example.invalid:1080 \
  --proxy-user 'login-country-us:password' \
  https://api64.ipify.org

Схема должна совпадать с портом: http:// — с 8080, socks5h:// — с 1080. Если их перепутать, соединение оборвётся или зависнет сразу после подключения. Остальные параметры строки разобраны в статье формат строки прокси, а ошибки curl — в статье curl через прокси.

Протокол выбирается при генерации в поле «Протокол». У ISP-прокси данные для подключения указаны в заказе во вкладке «Мои прокси».

Команды запускались 5 ноября 2026 года в curl 8.7.1 через локальные тестовые прокси, а не через шлюз Proxeta.

Что выбрать: HTTP или SOCKS5

• Браузер, Playwright, расширение для Chrome → HTTP. Chromium через Playwright не принимает SOCKS5 с логином и паролем, а расширение Proxeta Proxy Manager работает только с HTTP-прокси.
• curl, Python и другие HTTP-клиенты → любой. Для HTTP не нужны дополнительные пакеты, для SOCKS5 в requests нужен PySocks, а в curl используйте схему socks5h://. Примеры — в статье прокси в Python.
• Telegram → SOCKS5: его принимают приложения для Android, iPhone и компьютера, а HTTP — только Telegram Desktop. Настройка — в статье прокси для Телеграм.
• Антидетект-браузер → любой из протоколов, который он поддерживает; главное, чтобы тип прокси в профиле совпадал со строкой.
• Программа, которая умеет только один протокол → он.
• Нужен UDP → ни тот ни другой: шлюз UDP не передаёт.