Четыре протокола, помеченные как «прокси», объединяет разве что название. HTTP-прокси анализируют уровень 7 и перезаписывают заголовки; SOCKS-прокси вообще не читают ваш трафик. Это различие определяет, какой прокси подходит для просмотра веб-страниц, парсинга и организации сырых туннелей.
HTTP-прокси
HTTP-прокси ожидает семантику HTTP. Он вскрывает запрос, читает URL, может добавлять заголовки вроде Via или X-Forwarded-For и отвергает всё, что не является корректным HTTP-запросом. Браузеры, curl и большинство библиотек для парсинга по умолчанию используют HTTP-прокси, потому что настройка практически бесплатна — достаточно задать одну переменную окружения или передать флаг.
Цена этой простоты — прозрачность. Прокси видит полный URL, включая путь и строку запроса, а в случае обычного HTTP — ещё и тело запроса. Кэширующие прокси могут перезаписывать ответы; прозрачные прокси могут удалять куки. Относитесь к любому HTTP-прокси как к полностью привилегированному посреднику и никогда не передавайте через него учётные данные по незащищённому каналу.
HTTPS-прокси и метод CONNECT
«HTTPS-прокси» — несколько вводящий в заблуждение термин. Он обозначает HTTP-прокси, который дополнительно реализует метод CONNECT. CONNECT указывает прокси открыть сырой TCP-туннель к целевому хосту и передавать байты в обоих направлениях; клиент и получатель затем договариваются о TLS так, как будто прокси нет. Прокси видит целевой хост и порт, а также объём переданных байтов, но не содержимое.
Таким образом, «прокси с поддержкой HTTPS» — это прокси, который поддерживает туннелирование TLS, а не прокси, работающий поверх TLS. Соединение от вашей машины до прокси может быть как обычным, так и зашифрованным — независимо. Если вас волнует защита этого соединения, используйте реализацию SOCKS5 поверх TLS или коммерческий платный прокси, публикующий свою TLS-конечную точку.
SOCKS4
SOCKS4 — это минимум 1994 года: только TCP, только IPv4, без UDP, без IPv6, без аутентификации, без разрешения имён хостов на стороне прокси. Рукопожатие состоит из шести байт плюс однобайтовый код ответа. Он до сих пор встречается в дикой природе, потому что протокол настолько мал, что почти любой инструмент, работающий с TCP, может корректно его реализовать. Если в списке указан SOCKS4, ожидайте простую пересылку TCP на IPv4-адрес — и ничего больше.
SOCKS5
SOCKS5, определённый в RFC 1928 (1996), — это версия, с которой работает большинство современных инструментов. Он добавляет пересылку UDP, адреса IPv6, аутентификацию GSSAPI и возможность разрешать имена хостов на стороне прокси, а не клиента. Поскольку SOCKS5 не делает никаких предположений о прикладном уровне, работающем поверх него, это самый гибкий выбор для нагрузок, отличных от HTTP: SSH, IRC, BitTorrent, кастомные RPC.
Производительность и накладные расходы
Прокси SOCKS имеют меньшие накладные расходы на запрос, потому что они ничего не анализируют. HTTP- и HTTPS-прокси тратят ресурсы на полный разбор запроса при каждом соединении. Для одного долгоживущего TLS-сеанса внутри CONNECT разница незначительна. Для тысяч коротких запросов, когда прокси каждый раз открывает новое соединение, SOCKS5 выигрывает измеримо — обычно 2–5 мс на запрос за счёт отсутствия разбора.
Анонимность на практике
HTTP-прокси, не удаляющий ваши заголовки, может раскрыть ваш IP-адрес клиента через Via, X-Forwarded-For или Forwarded. У SOCKS-прокси таких заголовков нет, потому что они вообще не оперируют понятием заголовков. Это не столько функция анонимности, сколько отсутствие поверхности для утечки. Внутри CONNECT-туннелированного HTTPS получатель видит только рукопожатие TLS, так что любая утечка на уровне HTTP через прокси становится неактуальной.
Соглашения о портах
В этом каталоге вы встретите: 80, 8080, 3128, 8888 для HTTP; 443 для конечных точек, явно поддерживающих CONNECT; 1080 для SOCKS. Многие провайдеры выставляют нестандартные высокие порты (выше 10 000), чтобы избежать случайного сканирования портов. Номер порта ничего не говорит о качестве — он лишь указывает, что оператор решил открыть.