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

На каком уровне работает каждый

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

Главное заблуждение: анонимность при HTTPS

Когда вы обращаетесь по https, HTTP-прокси не может заглянуть внутрь. Соединение открывается специальной командой, после которой прокси становится слепым передатчиком: он видит только имя хоста, порт, тайминги и объём переданных данных — ровно то же, что видит SOCKS5.

Где SOCKS5 действительно выигрывает

• Не-HTTP трафик: произвольный TCP и UDP. У HTTP-прокси поддержки UDP нет вовсе.
• Разрешение доменных имён на стороне прокси, если библиотека это умеет запросить.
• Отсутствие любого вмешательства в заголовки — их просто нечем менять.

Для сбора данных с сайтов ни один из этих пунктов обычно не решающий. Поэтому выбор чаще определяется тем, что умеет ваш софт, а не свойствами протокола.

Что поддерживает ваш софт

Это и есть настоящий критерий. Большинство парсеров и SEO-инструментов принимают оба протокола, но не все — и не всегда с авторизацией. В Python для SOCKS5 нужна отдельная зависимость, которой нет в базовой поставке. В Chromium авторизация SOCKS5 работает ненадёжно, и для headless-браузеров практичнее HTTP-прокси с авторизацией по адресу.

# HTTP-прокси
curl -sI -x http://ЛОГИН:ПАРОЛЬ@ШЛЮЗ:HTTP_ПОРТ https://example.com | head -1

# SOCKS5. Буква h в схеме = резолв домена на стороне прокси
curl -sI -x socks5h://ЛОГИН:ПАРОЛЬ@ШЛЮЗ:SOCKS_ПОРТ https://example.com | head -1

# Для SOCKS5 в Python нужна отдельная зависимость:
#   pip install "requests[socks]"

Про DNS — коротко

У SOCKS5 есть тонкость с тем, кто разрешает доменное имя: ваша машина или прокси. Она влияет на то, видит ли провайдер список открываемых вами домен, и в схеме подключения обозначается одной буквой. Подробно с примерами это разобрано в статье про подключение прокси в Python — здесь достаточно знать, что такая настройка есть.

Как выбрать

• Сбор данных по HTTPS, обычные библиотеки — берите HTTP, разницы не будет.
• Софт принимает только SOCKS5 — берите SOCKS5, вопрос закрыт.
• Нужен UDP или не-HTTP протокол — только SOCKS5.
• Headless-браузер — HTTP плюс авторизация по whitelist.

У нас оба протокола доступны на одном тарифе и с одинаковой авторизацией, поэтому решение не окончательное: можно проверить оба на своей задаче и оставить тот, что удобнее.

Что именно умеет SOCKS5, чего нет у HTTP

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

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

Как проверить, что у вас включилось

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

Надёжная проверка одна: отправить запрос к эндпоинту, который возвращает видимый адрес, отдельно по каждой схеме и сравнить. Если адрес совпадает с вашим домашним, прокси не применился, какая бы схема ни стояла в настройках.

• Адрес совпадает с домашним — прокси не применился вовсе.
• Адрес прокси, но задача не работает — дело не в протоколе, ищите в авторизации или в цели.
• Одна схема работает, другая нет — почти всегда порт другого протокола или неподдерживаемая авторизация.