Что такое HTTPS-прокси на самом деле и когда он нужен

Когда вы видите у прокси-провайдера надпись «supports HTTPS», почти всегда имеется в виду не то, что вы думаете. Под этим маркетинговым ярлыком продаётся обычный HTTP-прокси — только с поддержкой тоннелирования к HTTPS-сайтам. Настоящий HTTPS-прокси — это отдельная категория, в которой шифруется сам канал между вашим клиентом и прокси-сервером. Разница видна провайдеру интернета, публичной Wi-Fi-точке и корпоративному мониторингу. И эта разница определяет, узнают ли третьи лица, к каким сайтам вы обращаетесь.

В этой статье — где проходит граница между двумя продуктами, почему она важна и в каких сценариях HTTPS-прокси заменить нельзя. Без маркетинговых преувеличений. Только механика протокола и прикладные ситуации.

Две разные вещи под одним словом

Чтобы не путаться, сначала опишу оба варианта на уровне протокола.

Обычный HTTP-прокси. Ваш клиент (браузер, curl, скрапер) устанавливает TCP-соединение с прокси без шифрования. Если вы идёте на HTTPS-сайт, клиент отправляет команду CONNECT www.bank.com:443 HTTP/1.1 прямо в открытом виде по этому TCP-соединению. Прокси открывает TCP-коннект к банку, отвечает «200 Connection Established» и дальше прокачивает байты туда-обратно. TLS-handshake происходит между вашим клиентом и банком, байты handshake'а проходят через прокси, но сам прокси их не расшифровывает.

Тут важный момент. ClientHello в TLS — это первое сообщение в handshake'е, и оно отправляется в открытом виде. В нём есть расширение Server Name Indication (SNI), в котором лежит hostname целевого сайта. Задача SNI — сказать серверу, какой именно виртуальный хост вам нужен (важно, когда один IP обслуживает тысячи доменов). SNI читается любым, кто смотрит трафик на участке клиент → прокси: вашим провайдером, оператором Wi-Fi-точки, корпоративным DPI. Плюс сама команда CONNECT содержит тот же hostname открытым текстом. Получается двойная утечка: имя BANK.COM видно в двух местах на пути между вами и прокси.

Настоящий HTTPS-прокси. Клиент открывает TCP к прокси и сразу запускает поверх него TLS — ровно так же, как если бы подключался к обычному HTTPS-сайту. Только валидный сертификат у прокси, а не у банка. После того как TLS-сессия с прокси установлена, все дальнейшие команды — включая CONNECT www.bank.com:443 — идут уже внутри зашифрованного туннеля. Параллельно клиент инициирует свой TLS к банку внутри этого туннеля. Наблюдатель между вами и прокси видит только одно TLS-соединение к proxy.host.com. Ничего про BANK.COM в открытом виде не уходит.

Формально в TLS есть Encrypted Client Hello (ECH), который тоже скрывает SNI, но он требует поддержки со стороны целевого сервера и CDN перед которым он стоит, и развёртывается медленно. HTTPS-прокси — это решение, которое работает сегодня независимо от того, поддерживает ли целевой сайт ECH.

Проверка в одну команду

Чтобы отличить настоящий HTTPS-прокси от «HTTP-прокси, который умеет HTTPS», достаточно одной команды:

openssl s_client -connect proxy.host.com:50001

Если в ответ приходит TLS-handshake с валидным сертификатом — это HTTPS-прокси. Если приходит plain-text HTTP («400 Bad Request» или «407 Proxy Authentication Required») — это обычный HTTP-прокси, и независимо от того, что написано на витрине, канал до него не шифруется.

Можете попробовать на любом провайдере, которым пользуетесь. У нас, например, на всех эндпоинтах Geekproxy эта команда отдаёт TLS 1.3 с действительным сертификатом Let's Encrypt и Verify return code: 0 (ok).

Зачем это нужно на практике

SNI-утечка звучит абстрактно, пока не разобрать её на конкретные ситуации. Дальше — где разница между HTTP- и HTTPS-прокси превращается в реальные последствия.

Публичные Wi-Fi и работа не из дома. В кафе, отеле, аэропорту вы не контролируете, кто сидит на той же точке доступа. Если через HTTP-прокси работаете с CRM, банком или почтовым сервером — имя этого сервера уходит в радиоэфир. Человек с ноутбуком и Wireshark в соседнем углу видит, куда вы ходите. HTTPS-прокси это закрывает: для всех на точке доступа вы просто подключены к вашему прокси-хосту, больше ничего не видно.

Корпоративная сеть с egress-инспекцией. В серьёзных компаниях весь исходящий трафик идёт через security-gateway, который логирует SNI всех исходящих TLS-соединений. Если вы через HTTP-прокси работаете с конкурентами, подрядчиками, внутренними расследованиями — ваша активность частично видна security-team. HTTPS-прокси скрывает от внутреннего DPI всё, кроме самого факта коннекта к прокси-хосту.

Интернет-провайдер с DPI. В Иране, Пакистане, Казахстане, Китае, частично в России и Беларуси провайдеры и магистральные операторы используют оборудование глубокой инспекции пакетов, умеющее классифицировать сайты по SNI и рвать соединения к определённым хостам. Если вы через HTTP-прокси — каждая команда CONNECT и каждый ClientHello видны и анализируются. Через HTTPS-прокси провайдер видит только одно TLS-соединение к одному хосту, который сам по себе ничего не говорит о том, куда вы дальше ходите.

Финтех due-diligence и M&A-исследования. Инвестбанк, готовящий сделку по поглощению, не хочет, чтобы его ISP видел частые обращения к сайту объекта сделки — эта информация сама по себе market-moving. Через HTTPS-прокси такие обращения невидимы для внешней сети.

Комплаенс — GDPR, PCI DSS 4.0.1, HIPAA. Формально стандарты говорят про шифрование «в транзите». Когда аудиторы дошли до понимания, что прокси — это тоже часть транзита, требования начали трактовать как обязательное шифрование на всех участках передачи, включая клиент-прокси. В регулируемых отраслях HTTPS-прокси постепенно становится compliance-дефолтом.

Журналисты и активисты в странах с цензурой. Для них сетевая цензура — не гипотетическая модель угрозы. Если на государственном уровне собирается статистика, кто и куда ходил, HTTPS-прокси скрывает от наблюдателя весь список ваших hostname'ов. Он не делает вас невидимым, но сильно меняет то, что можно собрать в логи.

Ad verification и работа с рекламными платформами. Сервисы проверки рекламы работают из ограниченных сетей с фильтрацией исходящего трафика. Обычный HTTP-прокси опознаётся anti-proxy системами по паттернам трафика. HTTPS-прокси маскируется под обычный HTTPS-сайт и этот детект обходит.

Anti-detect браузеры. Multilogin, Dolphin Anty, GoLogin, Kameleo, AdsPower, Undetectable принимают HTTPS-схему прокси нативно, потому что их аудитория (арбитражники, ad-operators, multi-account менеджеры) работает в средах, где HTTP-прокси палится файрволлом, а HTTPS — проходит. Отдельный большой класс пользователей, которому HTTPS-прокси нужен постоянно.

Когда HTTPS-прокси не нужен

Не каждый сценарий требует TLS до прокси. Если задача — просто поменять исходящий IP для скрейпинга e-commerce, публичных API или неблокируемых сайтов, обычный HTTP-прокси отрабатывает быстрее и стоит обычно дешевле. TLS-handshake к прокси добавляет порядка 100–200 мс к каждому новому соединению. Для массового скрейпинга в миллионы запросов это критично. Если вы в доверенной сети (собственный офис, проверенный VPN) и канал до прокси контролируете — HTTP достаточен.

Второй случай — инструмент не поддерживает HTTPS-схему. Например, Scrapy без custom downloader middleware молча проигнорирует https:// в настройках прокси и обработает как HTTP.

Совместимость: что где работает

Поддержка HTTPS-прокси в клиентах очень фрагментирована. Ниже — актуальный срез на начало 2026 года.

curl — полная поддержка через --proxy https://user:pass@host:port. TLS-верификация включена по умолчанию. Отключить можно через --proxy-insecure, но в продакшене этого делать не стоит.

Python httpx — поддержка встроенная: httpx.Client(proxy="https://user:pass@host:port"). Python requests официально HTTPS-прокси не поддерживает, нужны обходные решения.

Playwright — принимает HTTPS-прокси через параметр proxy={"server": "https://...", "username": "...", "password": "..."}. Работает со всеми браузерными движками.

Selenium, Puppeteer — частично. Через драйвер-специфичные capabilities, надёжность зависит от версий Chrome/Chromium, которые Selenium/Puppeteer поднимают.

Chrome/Chromium. Тут распространённое заблуждение. Флаг --proxy-server=https://host:port из командной строки не заставляет Chrome подключаться к прокси по TLS — он молча работает как обычный HTTP-прокси. Единственный рабочий способ заставить Chrome использовать HTTPS-прокси — через PAC-скрипт, где функция FindProxyForURL возвращает директиву HTTPS host:port (именно большими буквами, а не PROXY). Стандартные настройки прокси через ОС (Windows, macOS, Linux) тоже не принимают HTTPS-схему — интерпретируют её как HTTP.

Firefox. Аналогично — HTTPS-прокси поддерживается только через PAC с директивой HTTPS host:port. Стандартный GUI-конфиг прокси HTTPS-схему не принимает. Эта функциональность работает в Firefox с 2007 года (Bugzilla #378637), но многие её до сих пор не знают.

Anti-detect браузеры — Multilogin, Dolphin Anty, GoLogin, Kameleo, AdsPower, Undetectable. Все принимают HTTPS-прокси нативно при добавлении custom-прокси в профиль, отдельными полями (тип-хост-порт-логин-пароль).

Scrapy — без custom middleware не работает с HTTPS-схемой прокси. С middleware (на практике — самописный downloader middleware или переход на httpx-based pipeline) работает.

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

curl:

curl --proxy https://username:[email protected]:50001 https://www.target-site.com/

Python httpx:

import httpx

client = httpx.Client(
    proxy="https://username:[email protected]:50001"
)
response = client.get("https://www.target-site.com/")
print(response.text)

Playwright:

from playwright.sync_api import sync_playwright

with sync_playwright() as p:
    browser = p.chromium.launch(
        proxy={
            "server": "https://proxy.host:50001",
            "username": "username",
            "password": "password",
        }
    )
    page = browser.new_page()
    page.goto("https://www.target-site.com/")

PAC-скрипт для Chrome и Firefox — минимальный вариант:

function FindProxyForURL(url, host) {
    return "HTTPS proxy.host.com:50001";
}

Сохраняете в файл proxy.pac, в настройках браузера указываете путь к нему (или URL, если положите на внутренний http-сервер). Логин-пароль обычно запрашивается стандартным auth-диалогом браузера при первом запросе через прокси, дальше Chrome и Firefox держат креды в собственном хранилище.

Multilogin и другие anti-detect браузеры — в настройках профиля выбираете Custom Proxy, тип HTTPS, хост и порт раздельными полями, логин и пароль. Сохраняется на уровне профиля.

Как мы это сделали в Geekproxy

Коротко, чтобы не раздувать статью рекламой. На всех эндпоинтах HTTPS-прокси работает на отдельном порту, принимает TLS 1.3, использует валидный Let's Encrypt сертификат. Клиентский канал до прокси шифрован полностью. Команда CONNECT и hostname целевого сайта не уходят открытым текстом ни одному промежуточному наблюдателю. Через anti-detect браузеры подключается нативно, через curl и Playwright — стандартным синтаксисом выше.

Коротко, для занятых

«HTTPS proxy» у большинства провайдеров — это HTTP-прокси с CONNECT-тоннелированием. Имя целевого сайта видно в CONNECT-команде и в SNI на участке клиент-прокси.

Настоящий HTTPS-прокси оборачивает канал клиент-прокси в TLS первым слоем. На этом участке не видно ничего, кроме факта коннекта к самому прокси-хосту.

Проверяется одной командой openssl s_client -connect proxy:port — должен прийти TLS-handshake с валидным сертификатом.

Нужен в публичных сетях, под корпоративной инспекцией, в странах с DPI, в комплаенс-средах, в связке с anti-detect браузерами, для исследований, где сам факт коннекта к цели — уже информация.

Не нужен для простой смены IP в массовом скрейпинге и для инструментов без поддержки HTTPS-схемы.

Chrome и Firefox сами по себе HTTPS-прокси принимают только через PAC-скрипт с директивой HTTPS host:port. Из GUI и командной строки — не принимают.