HTTP и HTTPS прокси: в чём разница и какой выбрать

HTTP- и HTTPS-прокси отличаются одним участком маршрута: шифруется ли соединение между вашим устройством и самим прокси-сервером. Обычный HTTP-прокси общается с браузером открытым текстом, но защищённые сайты всё равно открывает через туннель CONNECT, и содержимое страницы остаётся зашифрованным от браузера до сайта. HTTPS-прокси шифрует ещё и первый отрезок пути, поэтому логин от прокси и адреса посещаемых сайтов не видны тем, кто следит за локальной сетью.

Путаницу создают сами продавцы. Строка «HTTP/HTTPS» в тарифах почти всегда означает обычный HTTP-прокси, который умеет ходить на HTTPS-сайты, а не прокси с TLS-подключением. Разберём оба варианта пошагово: как проходит запрос, что видит владелец прокси в каждом режиме, сведём всё в таблицу и покажем команды curl, которые за минуту покажут, какой режим у вашего сервера.

Два значения слов «HTTPS-прокси»

Под этим названием скрываются две разные схемы:

• HTTP-прокси с поддержкой CONNECT. Прокси указывается как http://host:port и работает и с http://, и с https:// сайтами. Так устроены практически все коммерческие прокси, и именно это продавцы называют «поддержкой HTTPS».
• Прокси с TLS на входе. Клиент сначала устанавливает с прокси зашифрованное соединение, адрес выглядит как https://host:port, и уже внутри него отправляет запросы. Такой режим поддерживают меньше программ и меньше провайдеров.

Простое правило: если программа просит только хост, порт и тип «HTTP», а защищённые сайты при этом открываются, у вас первый вариант. Основы самого протокола описаны в статье о том, что такое HTTP-прокси.

Как обычный HTTP-прокси передаёт трафик

Незашифрованные сайты (http://)

Для сайта без TLS клиент отдаёт прокси запрос целиком, причём с полным адресом, а не только путём:

GET http://example.com/catalog?page=2 HTTP/1.1
Host: example.com
Proxy-Authorization: Basic <логин:пароль в base64>

Прокси читает каждую строку, подключается к сайту, получает ответ и возвращает его клиенту. Раз он понимает запрос, он может кэшировать файлы, фильтровать адреса, менять заголовки или добавлять свои, например Via. Обратная сторона очевидна: прокси и любой узел между вами и прокси видят полный URL, cookie, поля форм и ответ сервера. Base64 в заголовке авторизации — это кодировка, а не шифрование, так что логин тоже читается из сети.

Защищённые сайты (https://)

Для HTTPS-сайта браузер не передаёт сам запрос. Он просит прокси открыть «сырой» канал:

CONNECT example.com:443 HTTP/1.1
Host: example.com:443
Proxy-Authorization: Basic <логин:пароль в base64>

Прокси подключается к сайту, отвечает HTTP/1.1 200 Connection established и дальше просто перекладывает байты в обе стороны. TLS-рукопожатие идёт между браузером и сайтом, и сертификат, который проверяет браузер, принадлежит сайту. Метод CONNECT описан в RFC 9110 (раздел 9.3.6), и многие прокси разрешают его только на порт 443.

Что прокси узнаёт в этом режиме: хост и порт назначения, имя сервера из начала TLS-рукопожатия (SNI), объём и время передачи данных. Пути, параметры запроса, cookie, введённые на странице пароли и сам контент остаются внутри зашифрованной сессии.

Как работает прокси с TLS-шифрованием

С настоящим HTTPS-прокси клиент начинает с TLS-рукопожатия с прокси и проверяет его сертификат. Только после этого он отправляет те же строки GET или CONNECT, но уже под защитой. Если сайт тоже работает по HTTPS, получается TLS внутри TLS: один слой до прокси, второй до сайта.

Что это даёт:

• логин и пароль от прокси не передаются по локальной сети в читаемом виде;
• владелец Wi-Fi или интернет-провайдер видит только факт подключения к прокси, но не строки CONNECT с именами сайтов;
• никто на первом отрезке пути не может подменить ответы обычных HTTP-сайтов.

Чем приходится платить: ещё одно рукопожатие при открытии соединения, немного больше нагрузки на процессор с обеих сторон и более узкая поддержка в программах. curl понимает схему https:// для прокси начиная с версии 7.52.0. Chrome и Firefox подключаются к такому прокси через PAC-файл с директивой HTTPS host:port — о том, как это устроено, рассказывает статья про адрес прокси-скрипта и PAC-файлы. Многие парсеры, боты и антидетект-браузеры по-прежнему предлагают в меню только «HTTP» и «SOCKS5».

Не путать с расшифровкой TLS

Некоторые корпоративные шлюзы идут дальше: завершают TLS-сессию на прокси, читают трафик и открывают к сайту новое зашифрованное соединение. Чтобы браузеры при этом не выдавали предупреждений, на каждый рабочий компьютер ставят корневой сертификат компании. Это отдельная технология со своими правилами, она разобрана в обзоре SSL/HTTPS-прокси. Арендованному прокси для исходящего трафика никакие дополнительные сертификаты на вашем устройстве не нужны. Если провайдер просит их установить, он сможет читать всё, что вы отправляете.

Сравнение в одной таблице

Что происходит со скоростью

CONNECT добавляет один обмен с прокси до начала TLS-рукопожатия с сайтом. TLS-прокси добавляет сверху собственное рукопожатие — с TLS 1.3 это примерно ещё один круг «запрос — ответ». Соединения keep-alive переиспользуются, поэтому задержка возникает один раз на соединение, а не на каждый запрос. На практике расстояние до прокси и его загрузка влияют на скорость гораздо сильнее, чем выбор режима.

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

Как проверить, какой режим поддерживает прокси

curl с ключом -v показывает весь обмен. Замените вымышленные адрес и учётные данные на свои:

# HTTP-прокси, защищённый сайт через туннель CONNECT
curl -v -x http://user-7f3k:pass-92ad@203.0.113.15:8080 https://api.ipify.org

# TLS-соединение с самим прокси
curl -v -x https://user-7f3k:pass-92ad@proxy.example.net:8443 https://api.ipify.org

В выводе первой команды ищите строку CONNECT api.ipify.org:443 и следом HTTP/1.1 200. Если вторая команда обрывается ошибкой TLS вроде «wrong version number», порт работает по обычному HTTP и TLS на нём нет. В обоих случаях команда выводит внешний IP — его можно сверить с результатом нашего онлайн-чекера прокси для того же сервера.

Частые ошибки и что они означают

• 407 Proxy Authentication Required. Прокси не принял логин или пароль либо вашего IP нет в белом списке.
• ERR_TUNNEL_CONNECTION_FAILED в Chrome. Прокси отклонил запрос CONNECT: закрыт порт назначения, сайт заблокирован фильтром или не прошла авторизация.
• Предупреждения о сертификате на всех сайтах. Кто-то на маршруте расшифровывает TLS. Не вводите пароли, пока не выясните, кто именно.
• Ошибки TLS, когда адрес прокси начинается с https://. Порт ждёт обычный HTTP — верните схему http://.

Какой вариант выбрать

• Парсинг, антидетект-браузеры, запросы к API, работа с аккаунтами. Хватает обычного HTTP-прокси с CONNECT: сайты сами шифруют содержимое. Резидентские прокси Node Proxy принимают HTTP-подключения с CONNECT, а также SOCKS5.
• Публичный Wi-Fi, сеть отеля, провайдер, которому вы не доверяете. Выбирайте TLS-прокси, если программа его поддерживает, или заворачивайте соединение в VPN либо SSH-туннель, чтобы скрыть логин от прокси и имена сайтов.
• Фильтрация и кэширование старых внутренних сайтов в офисе. Подойдёт классический HTTP-прокси, который читает открытый трафик.
• Игры, мессенджеры, почтовые клиенты и другой трафик не из браузера. Оба варианта подходят плохо. SOCKS5-прокси передаёт любые TCP-соединения, а при поддержке с обеих сторон — и UDP.