HTTP- и HTTPS-прокси

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

Здесь нужно различать два подключения: как программа соединяется с прокси и как через него общается с сайтом. Это помогает правильно выбрать параметры подключения. Общее сравнение протоколов рассматривается в статье «SOCKS- и HTTP-прокси».

Что HTTP-прокси делает с веб-запросом

Допустим, скрипт мониторинга запрашивает http://example.com/catalog. Вместо прямого подключения к сайту он соединяется с указанным в настройках прокси. При использовании HTTP/1.1 скрипт передаёт в запросе полный адрес страницы, чтобы прокси знал, к какому серверу и ресурсу обратиться. Прокси отправляет запрос дальше и возвращает скрипту ответ сайта.

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

Сайт получает сетевое соединение с выходного IP прокси. Название HTTP не определяет происхождение этого адреса или срок его закрепления. Один и тот же протокол подключения может использоваться с серверными, провайдерскими, резидентскими и мобильными адресами, с постоянными IP или ротационным пулом.

Как HTTP-прокси открывает HTTPS-сайт

HTTPS-сайт использует TLS для защиты обмена между программой и сайтом. Чтобы передать этот обмен, HTTP-прокси сначала создаёт туннель. При обращении к https://example.com/catalog последовательность выглядит так:

1. Программа соединяется с прокси и методом CONNECT просит открыть туннель к example.com:443. В запросе указаны имя сервера и порт, без пути к странице.
2. Прокси проверяет доступ клиента и разрешение на подключение к указанному серверу, в том числе проверяет реквизиты, если они нужны. Затем открывает соединение с сервером и подтверждает готовность туннеля.
3. Программа через туннель устанавливает TLS-соединение с сайтом и проверяет его сертификат.
4. Программа отправляет веб-запрос внутри этого TLS-соединения. Прокси передаёт зашифрованные данные в обе стороны.

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

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

Что добавляет HTTPS-прокси

При работе через HTTPS-прокси программа сначала устанавливает TLS-соединение с самим прокси и проверяет его сертификат. Уже внутри этого защищённого соединения она отправляет HTTP-запросы или запрос CONNECT для открытия туннеля. Наблюдатель в сети между программой и прокси не может прочитать эти запросы.

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

В таблице показана обычная передача через прокси с включённой проверкой сертификатов, без перехвата HTTPS и отдельного VPN. Шифрование соединения с прокси не превращает HTTP-сайт в HTTPS-сайт.

Что видят прокси и сайт

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

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

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

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

Как читать параметры подключения

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

Эти команды curl запрашивают один HTTPS-сайт через два разных подключения к прокси. Вместо имени и порта прокси укажите параметры, выданные для выбранного способа подключения:

curl --proxy http://proxy.example:8080 https://example.com/
curl --proxy https://proxy.example:8443 https://example.com/

Первая команда подключается к прокси по HTTP, затем создаёт туннель CONNECT и TLS-соединение с сайтом. Вторая сначала устанавливает TLS с HTTPS-прокси, а через него — отдельное TLS-соединение с сайтом. В обоих случаях также нужен способ аутентификации, предусмотренный услугой.

Простая замена http:// на https:// не включит TLS на порту, который принимает только HTTP. Если для HTTPS-доступа выдано имя сервера, используйте именно его: при замене на IP может возникнуть ошибка несоответствия имени в сертификате.

Названия полей в программах тоже требуют внимания. Поле «HTTPS proxy» может выбирать прокси для HTTPS-сайтов, хотя подключение к самому прокси остаётся обычным HTTP. В curl переменная HTTPS_PROXY также определяет прокси для HTTPS-адресов назначения; её значение вполне может начинаться с http://. Название указывает, к каким запросам применяется настройка, а схема адреса прокси — как устанавливается подключение.

DNS и трафик, который проходит через прокси

Когда HTTP-клиент передаёт имя целевого сервера, прокси обычно сам получает его IP через DNS и подключается к нему. Если адрес самого прокси задан именем, клиенту нужен отдельный DNS-поиск, чтобы подключиться к прокси. Браузер также может отправлять запросы DNS для предварительной загрузки и других функций. Это разные обращения: настройка веб-прокси не направляет через него все DNS-запросы.

Настройка действует на трафик, который программа действительно направляет прокси. Другая программа может продолжать подключаться напрямую, а список исключений — отправлять отдельные сайты в обход прокси. Например, подключение API-скрипта через прокси не меняет маршрут независимого браузера. Проверять выходной адрес нужно из той программы и с теми настройками, которые будут использоваться в работе.

HTTP/2 до сайта и HTTP/2 до прокси

HTTP/2 позволяет вести несколько обменов по одному соединению, используя отдельные потоки. При работе через прокси важно понимать, о каком соединении идёт речь. Программа может согласовать HTTP/2 с сайтом внутри туннеля, созданного методом CONNECT по HTTP/1.1. Прокси передаёт зашифрованные данные, и ему не нужно понимать HTTP/2-сообщения сайта.

HTTP/2 между программой и прокси — отдельная возможность. Каждому туннелю CONNECT выделяется свой поток HTTP/2, поэтому несколько туннелей могут использовать одно подключение к прокси. Например, через него можно создать туннели к двум сайтам, сохранив отдельные подключения и TLS-соединения с каждым сайтом. Клиенту требуется меньше отдельных соединений с прокси, но доступа к зашифрованным запросам сайтов у прокси не появляется.

Выбранный режим должны поддерживать обе стороны. HTTPS сам по себе не означает HTTP/2: HTTPS-прокси может использовать HTTP/1.1. Скорость также зависит от клиента, сетевого маршрута, нагрузки на серверы и повторного использования соединений. Надпись HTTP/2 не гарантирует ускорения любой задачи.

Обычный CONNECT-туннель может передавать и другие протоколы поверх TCP, если это позволяют программа и прокси, хотя порты назначения могут быть ограничены. UDP он не передаёт. HTTP/3 использует QUIC поверх UDP, поэтому передать его через этот TCP-туннель тем же способом не получится. Для передачи UDP средствами HTTP нужны дополнительные механизмы, например CONNECT-UDP, и совместимые реализации. Одна лишь поддержка HTTPS или HTTP/2 этого не обеспечивает.

Для каких задач подходят HTTP- и HTTPS-прокси

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

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

HTTPS-прокси с TLS полезен, когда нужно дополнительно защитить соединение до самого прокси, включая реквизиты доступа и запросы к серверам назначения. Это имеет значение, если соединение проходит через сеть, которую вы не контролируете. Программа должна поддерживать TLS именно до прокси; одной возможности открывать HTTPS-сайты недостаточно.

Как понимать ошибки подключения

Ошибка может возникнуть при подключении к прокси, открытии туннеля или обмене с сайтом. Этап сбоя объясняет больше, чем один код ошибки.

Готовый туннель и успешное установление TLS показывают, что путь подключения работает. Они не гарантируют, что сайт примет конкретный аккаунт, выходной IP или запрос. Поэтому требование войти в аккаунт, CAPTCHA или ограничение запросов могут потребовать действий на уровне сайта или программы даже при исправном прокси.