HTTP CONNECT
Запрос, которым клиент открывает сырой туннель через прокси. Всё после него зашифровано между концами, поэтому прокси пересылает байты, которых прочитать не может.
Для обычного HTTP прямой прокси читает запрос, забирает ресурс и возвращает его. Для HTTPS такая схема не работает, потому что чтение означало бы взлом шифрования. Это решает CONNECT: клиент просит прокси открыть соединение к хосту и порту, и после ответа 200 обе стороны договариваются о TLS напрямую через него.
Дальше прокси видит имя хоста из строки CONNECT, объём и тайминг байтов, и ничего больше. Ни путей, ни заголовков, ни кук, ни содержимого, потому что ключей у него нет.
Это и есть технический ответ на вопрос, который клиенты задают осторожно и редко вслух: что может прочитать поставщик. На туннелях CONNECT содержимое нам недоступно. Хост назначения доступен, как и объём прошедшего трафика, а это ровно то, что требуется для тарификации по гигабайтам.
По той же причине перехватывающие прокси это другой продукт. Прокси, инспектирующий HTTPS, обязан терминировать TLS и предъявить собственный сертификат, которому клиент должен быть настроен доверять. Мы так не делаем, а тот, кто делает, держит ваш открытый текст.
Что происходит на проводе
Клиент открывает соединение к прокси и отправляет строку CONNECT с именем хоста и портом назначения, а при аутентификации добавляет заголовок Proxy-Authorization.
Прокси отвечает кодом 200, как только открыто соединение наверх. С этого момента он копирует байты в обе стороны, не интерпретируя их, а последующее рукопожатие TLS идёт между клиентом и целью.
Сбои на этом этапе различимы: 407 означает, что учётные данные пришли не в том виде, 502 что прокси не смог достучаться до цели, а таймаут после 200 что туннель открылся, а дальний конец замолчал.
Посмотреть, как открывается туннель
Подробный вывод показывает каждую стадию, и отладка превращается в чтение вместо гадания:
Туннель по шагам
# -v печатает обмен CONNECT до рукопожатия TLS
curl -v -x login_c_DE:password@proxy.sotaproxy.com:10000 https://api.ipify.org 2>&1 | head -20
# статический адрес использует тот же метод на своём порту
curl -v -x login:password@YOUR-ISP-IP:50100 https://api.ipify.org 2>&1 | head -20- Если кода 200 в ответ на CONNECT вы так и не увидели, проблема в аутентификации или доступности, а не в целевом сайте.
- Обе наши HTTP-точки туннелируют HTTPS именно так; SOCKS5 на порту статики добивается того же другим рукопожатием.
- Поскольку туннель непрозрачен, возможности уровня запроса, которых иногда ждут от прокси, вроде переписывания заголовков, на HTTPS-трафике существовать не могут.
Частые неверные прочтения
HTTPS-прокси не расшифровывает HTTPS
Он его переносит. Расшифровка потребовала бы терминировать TLS и сертификат, которому доверяет ваш клиент.
Хост прокси всё же видит
Он назван в строке CONNECT. Содержимое скрыто, адреса назначения нет.
407 это не блокировка
Это отказ открыть туннель, потому что учётные данные пришли не так, как ожидалось. До цели ничего не дошло.
Это не то же самое, что SOCKS5
Туннелируют оба. CONNECT это метод HTTP, SOCKS5 отдельный протокол со своим рукопожатием и своей аутентификацией.
Смотри на практике
Готов использовать http connect?
SotaProxy даёт доступ к ротирующим резидентским, мобильным, дата-центр и ISP прокси. Без минимальных платежей.
Начать