HTTP/2 проходит через прокси без проблем, потому что работает поверх TCP, а TCP — это именно то, что передает туннель CONNECT или соединение SOCKS5. HTTP/3 — нет: он работает поверх QUIC, который основан на UDP, и обычные HTTP-прокси вообще не могут туннелировать UDP, в то время как большинство SOCKS5-развертываний тоже этого не делают. Практическое следствие: клиент через прокси почти всегда общается с сайтом по HTTP/2 (или HTTP/1.1), даже если сайт поддерживает HTTP/3 — браузер молча переключается на более старую версию. Для большинства задач это нормально, но это меняет то, что видит целевой сервер, и это стоит понимать, а не обнаруживать случайно.
Три протокола за одну минуту
- HTTP/1.1 (1997): текстовый, один запрос за раз на соединение; браузеры открывают несколько соединений параллельно, чтобы компенсировать это.
- HTTP/2 (2015): бинарная структура кадров, множество параллельных потоков, мультиплексированных по одному TCP-соединению, сжатие заголовков (HPACK), server push (сейчас в основном заброшен). Под капотом — тот же TCP + TLS, что и в HTTP/1.1.
- HTTP/3 (2022): та же семантика, что и в HTTP/2, но передается через QUIC — транспорт, работающий поверх UDP, со встроенным TLS 1.3 в рукопожатии, без блокировки head-of-line в TCP и с возможностью пережить смену IP (например, переход телефона с Wi-Fi на 4G).
Браузер узнает, что сайт предлагает HTTP/3, одним из двух способов: через заголовок ответа Alt-Svc: h3=":443" в предыдущем HTTP/2-ответе или через DNS-запись HTTPS, рекламирующую его. Узнав об этом, он пробует QUIC при следующем соединении и запоминает результат.
Как прокси передают каждый из них
HTTP-прокси
Для HTTPS-назначения клиент отправляет CONNECT host:443, прокси открывает TCP-соединение с назначением и превращается в простой байтовый канал. Что бы клиент и назначение ни согласовывали внутри этого канала — TLS 1.3, затем HTTP/1.1 или HTTP/2 через ALPN — это невидимо для прокси и работает без изменений. Таким образом, HTTP/2 через HTTP-прокси — это совершенно нормально.
UDP не имеет места в этой модели. CONNECT создает TCP-туннель; не существует стандартного способа для обычного HTTP/1.1-прокси сказать: «передай мои UDP-датаграммы этому хосту». Браузер, настроенный на HTTP-прокси, просто не пытается использовать QUIC для origins — Chrome и Firefox отключают HTTP/3 для проксированных соединений — и вместо этого использует HTTP/2 через туннель. Никакой ошибки, никакого предупреждения.
SOCKS5-прокси
SOCKS5 действительно определяет команду UDP ASSOCIATE для ретрансляции датаграмм. В принципе, SOCKS5-прокси может переносить QUIC. На практике:
- многие коммерческие SOCKS5-прокси реализуют только
CONNECT(TCP) и отклоняют или игнорируют UDP ASSOCIATE; - UDP-ретрансляция через SOCKS5 требует, чтобы прокси имел доступный UDP-порт, а клиент поддерживал процедуру ассоциации, чего браузеры не делают для HTTP/3;
- Chrome и Firefox относятся к SOCKS-прокси так же, как к HTTP-прокси для этой цели: HTTP/3 не используется.
Таким образом, даже если прокси может пересылать UDP, браузер не попросит его об этом. Командные QUIC-клиенты и некоторые библиотеки могут быть направлены на SOCKS5-прокси с поддержкой UDP, но это специализированная конфигурация, а не стандартная. Наше сравнение SOCKS5 и HTTP-прокси более подробно рассматривает различие TCP/UDP.
Что могло бы переносить HTTP/3: MASQUE и CONNECT-UDP
Рабочая группа IETF MASQUE стандартизировала CONNECT-UDP (RFC 9298) — расширение, позволяющее HTTP/3 (или HTTP/2) прокси туннелировать UDP-нагрузку, а следовательно, и QUIC до origin. Это используется в iCloud Private Relay от Apple и в некоторых новых прокси для конфиденциальности. Поддержка в универсальных коммерческих прокси и в настройках прокси браузера все еще редкость; когда провайдер рекламирует «поддержку HTTP/3», стоит уточнить, означает ли это, что прокси говорит с вами по HTTP/3 или может туннелировать HTTP/3 до origins — это разные вещи.
Что происходит на самом деле, шаг за шагом
- Ваш браузер через прокси запрашивает
https://example.com. Он открываетCONNECT example.com:443через прокси. - Внутри туннеля он выполняет рукопожатие TLS 1.3, предлагая ALPN
h2иhttp/1.1. Origin выбираетh2. Вы используете HTTP/2. - Ответ содержит
Alt-Svc: h3=":443". Браузер замечает это — и, поскольку настроен прокси, игнорирует это для целей соединения. - Каждый последующий запрос к этому origin продолжает идти по HTTP/2 через туннель.
Выключите прокси и перезагрузите страницу: теперь браузер учитывает Alt-Svc, и тот же сайт обслуживается по HTTP/3. В обоих случаях ничего не ломается; просто отличается протокол.
Почему это важно
Производительность
Преимущества HTTP/3 — более быстрое рукопожатие, отсутствие блокировки head-of-line на потерянных линиях, миграция соединения — теряются через прокси. Для датацентровых прокси на хороших линиях разница невелика. Для мобильных прокси, где последний участок — это потерянная сотовая связь, QUIC помог бы больше всего, и именно там его нельзя использовать. Закладывайте немного большую задержку, чем показало бы прямое HTTP/3-соединение; см. методологию в как измерить скорость прокси.
Отпечатки и согласованность
Это тонкий момент. Антибот-системы записывают, какой протокол использовал клиент и как выглядели его HTTP/2 SETTINGS (см. как работают антибот-системы). Современный Chrome при прямом соединении достигает большинства крупных сайтов по HTTP/3. Тот же Chrome через прокси приходит по HTTP/2. Само по себе это не подозрительно — множество реальных пользователей сидят за корпоративными прокси и никогда не используют HTTP/3 — но это еще одна точка данных, и это означает, что ваш HTTP/2-отпечаток (значения SETTINGS, порядок заголовков) теперь всегда виден и должен соответствовать заявленному браузеру. HTTP-клиенты, имитирующие браузеры, должны имитировать HTTP/2-слой, а не только TLS-слой, именно по этой причине; статья о TLS-отпечатках объясняет стек.
Инструменты для скрапинга
Python-библиотека requests говорит только на HTTP/1.1; httpx может работать с HTTP/2 с дополнительным пакетом h2; aiohttp — HTTP/1.1. Ни одна из них не делает HTTP/3 через прокси. Поскольку проксированный браузер все равно на HTTP/2, использование HTTP/2 в вашем клиенте (где библиотека это поддерживает) приближает вас к тому, как выглядит реальный пользователь через прокси. Примеры в Прокси в Python.
Практические рекомендации
| Ситуация | Что вы получаете | Действие |
|---|---|---|
| Браузер + HTTP-прокси, сайт с HTTP/3 | HTTP/2 через туннель CONNECT | Ничего делать не нужно; это нормально |
| Браузер + SOCKS5-прокси, сайт с HTTP/3 | HTTP/2 (браузер не пытается использовать QUIC через SOCKS) | Ничего делать не нужно |
| Вам нужен HTTP/3 до origin через прокси | Требуется поддержка CONNECT-UDP/MASQUE на всем пути | Спросите провайдера конкретно; предполагайте, что нет, если не подтверждено |
| Сайт ведет себя по-разному через прокси и напрямую | Возможно, связано с протоколом, скорее с IP | Сравните с реальным браузером на том же прокси, прежде чем винить HTTP/3 |
| Имитация клиента для защищенных сайтов | Должен соответствовать HTTP/2 SETTINGS и порядку заголовков браузера | Используйте клиент, который имитирует HTTP/2, а не только TLS |
| Измерение задержки прокси | Сравнивайте сопоставимое: HTTP/2 напрямую против HTTP/2 через прокси | Не сравнивайте HTTP/3 напрямую с HTTP/2 через прокси |
Часто задаваемые вопросы
Работает ли HTTP/2 через прокси?
Да. HTTP/2 работает поверх TCP и TLS, которые туннель CONNECT или соединение SOCKS5 передают прозрачно. Прокси вообще не нужно понимать HTTP/2.
Работает ли HTTP/3 через прокси?
В общем случае нет. HTTP/3 использует QUIC поверх UDP; HTTP-прокси не могут туннелировать UDP, и браузеры не пытаются использовать QUIC, когда настроен прокси. Браузер автоматически переключается на HTTP/2. Только прокси, поддерживающие CONNECT-UDP (MASQUE), могут переносить HTTP/3 до origins, и это редкость.
Может ли SOCKS5-прокси переносить QUIC?
В протоколе есть команда UDP-ретрансляции, но многие коммерческие SOCKS5-сервисы не реализуют ее, и браузеры не используют ее для HTTP/3. Специализированные клиенты могут, если прокси действительно поддерживает UDP ASSOCIATE.
Будет ли использование HTTP/2 вместо HTTP/3 обнаружено?
Само по себе нет — многие легитимные пользователи находятся за прокси, которые принудительно используют HTTP/2. Но это означает, что ваш HTTP/2-отпечаток всегда виден, поэтому он должен соответствовать браузеру, которым вы себя называете.
Быстрее ли HTTP/3 через прокси?
Вы не получаете HTTP/3 через обычный прокси, поэтому вопрос не возникает; вы получаете HTTP/2, который на потерянных линиях немного медленнее, чем был бы HTTP/3. На хороших датацентровых линиях разница незначительна.
Что такое Alt-Svc?
Это заголовок HTTP-ответа, с помощью которого сайт сообщает клиенту, что тот же ресурс доступен по другому протоколу или порту — обычно h3=":443" для рекламы HTTP/3. Браузеры учитывают его при прямых соединениях и игнорируют для целей соединения, когда настроен прокси.