Семантика HTTP-прокси и запросы браузера

Почему семантика прокси важна в браузере

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

Когда браузер использует HTTP- или HTTPS-прокси, семантика запросов влияет на аутентификацию, cookies, перенаправления, TLS-сертификаты, кэширование, журналы и видимый источник запроса. Ниже описано наблюдаемое поведение и стандарты, а не особенности конкретного поставщика. Практические примеры конфигурации приведены в руководстве Настройка прокси браузера: SOCKS5, HTTP и HTTPS. Если развёртывание использует WebRTC, отдельный путь трафика рассматривается в статье Что такое утечка IP через WebRTC?: настройки HTTP-прокси автоматически его не контролируют.

Основные идеи:

• Запрос к прокси может использовать абсолютный URI, а запрос внутри туннеля: origin-form.
• CONNECT создаёт байтовый туннель к хосту и порту. После успешного ответа прокси обычно пересылает зашифрованные TLS-байты, не разбирая находящиеся внутри HTTP-сообщения.
• Аутентификация прокси и аутентификация источника: разные задачи с разными заголовками.
• Браузер может разрешить имя локально или попросить прокси выполнить разрешение; это зависит от протокола и реализации.
• Перенаправления, сервис-воркеры, кэш и не-HTTP-протоколы создают запросы, которые легко пропустить в простом тесте.

Стандарты точно описывают синтаксис сообщений, но оставляют место для политики развёртывания. Прокси может ограничивать назначения, переписывать выбранные заголовки и записывать метаданные. Относитесь к нему как к сетевому сервису со своим контрактом, а не как к прозрачному кабелю.

Формы запросов и первый переход

HTTP/1.1 определяет четыре формы цели запроса в RFC 9110, раздел 7.1: origin-form, absolute-form, authority-form и asterisk-form. Браузер с forward-прокси обычно отправляет обычный HTTP-запрос в absolute-form. Например, вместо GET /products HTTP/1.1 он может отправить:

GET http://shop.example/products HTTP/1.1
Host: shop.example
Accept: text/html

Прокси использует полный URI, чтобы выбрать следующий переход. Заголовок Host остаётся важным: он обозначает authority, ожидаемый сервером-источником, и обязателен для запросов HTTP/1.1. В корректном запросе authority в URI и поле Host совпадают. Прокси может отклонить несовпадение, вместо того чтобы угадывать назначение клиента.

При прямом подключении к HTTP-источнику браузер обычно использует origin-form. В первой строке есть только путь и query:

GET /products?sort=price HTTP/1.1
Host: shop.example

Это различие полезно при чтении захвата пакетов или журнала доступа прокси. Абсолютный URI в строке запроса подтверждает, что первый переход идёт через forward-прокси, но не означает, что источник получил ту же форму. Обычно прокси преобразует запрос в форму, которую ожидает следующий переход.

Authority-form используется с CONNECT и состоит из хоста и порта, например shop.example:443. Asterisk-form, OPTIONS *, обращается к самому серверу, а не к ресурсу. В обычной загрузке браузеры редко создают такой запрос, но диагностический или совместимый тест может это сделать.

HTTP- и HTTPS-URL: разные случаи

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

Для URL https:// браузер обычно просит HTTP-прокси открыть туннель:

CONNECT shop.example:443 HTTP/1.1
Host: shop.example:443

Прокси возвращает статус вроде 200 Connection Established. Затем браузер начинает TLS-handshake через созданное соединение. HTTP-запрос, заголовки ответа и тело находятся внутри TLS и не видны обычному forward-прокси. Прокси всё же видит authority назначения, время соединения, число байтов и метаданные, необходимые его политике.

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

Особенности HTTP/2 и HTTP/3

RFC 9112 описывает сообщения HTTP/1.1 и правила разбора, защищающие границы сообщений. После создания туннеля современные браузеры могут использовать с источником HTTP/2 или HTTP/3; это зависит от поддержки браузера и прокси. Понятия запроса сохраняются, но представление в сети меняется: HTTP/2 использует бинарные фреймы и псевдозаголовки :method и :authority, а HTTP/3 работает поверх QUIC.

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

Туннели CONNECT, TLS и разрешение имён

CONNECT - метод создания туннеля к authority назначения. Это не произвольный URL с путём, а обычно хост и порт, чаще всего 443 для HTTPS. После успешного ответа прокси перестаёт обрабатывать HTTP-сообщения и пересылает данные в обоих направлениях до закрытия соединения.

Что видит прокси

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

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

SNI и другие детали TLS-handshake могут раскрывать предполагаемый хост сетевому наблюдателю; это зависит от версии TLS и включённых функций приватности. Прокси, который лишь пересылает байты, не устраняет такие сигналы. Приватность DNS, приватность TLS и HTTP-проксирование связаны, но являются разными средствами контроля.

Где выполняется DNS

Разрешение имён часто вызывает путаницу. При HTTP-прокси браузер может передать имя хоста в абсолютном URI или authority CONNECT и предоставить прокси разрешить его. Некоторые реализации сначала разрешают имя локально, например для локальной политики или выбора семейства адресов. Точное поведение зависит от браузера, типа прокси и настроек.

При локальном разрешении локальный resolver узнаёт назначение, даже если последующее TCP-соединение идёт через прокси. Разрешение на прокси оставляет запрос там, но не гарантирует, что все вспомогательные запросы идут тем же путём. Проверки отзыва сертификатов, captive portal, DNS-prefetch, спекулятивные соединения и расширения могут иметь отдельное сетевое поведение.

Если расположение DNS важно, тестируйте не только навигацию из адресной строки. Проверьте холодный профиль, новый процесс браузера, перенаправление на другое имя, iframe, worker и ошибочное разрешение. Справочник HTTP в MDN помогает отделить семантику HTTP от планирования сети браузером.

Заголовки, аутентификация и политика пересылки

У HTTP-заголовков разные адресаты в конфигурации с прокси. Одни описывают запрос источнику, другие: соединение с прокси, третьи добавляются посредниками. RFC 9110, раздел 5 задаёт общие правила полей и предупреждает, что посредники должны осторожно обрабатывать hop-by-hop-поля.

Аутентификация прокси не равна аутентификации источника

Прокси, которому нужны учётные данные, отвечает 407 Proxy Authentication Required и включает Proxy-Authenticate. Клиент отвечает Proxy-Authorization. Источник, требующий учётные данные, отвечает 401 Unauthorized, использует WWW-Authenticate и ожидает Authorization.

Эти вызовы происходят в разное время. Для HTTP URL вызов прокси может прийти до пересылки запроса. Для HTTPS он обычно является ответом на CONNECT, до начала TLS. Браузер может повторить соединение с учётными данными, но библиотека автоматизации выдаст ошибку навигации, если прокси не настроен через поддерживаемый API.

Не помещайте учётные данные источника в поле прокси и учётные данные прокси в Authorization, предназначенный сайту. У них разные области действия, и их часто записывают разные системы. Используйте защищённое хранилище учётных данных или документированный механизм конфигурации прокси браузера, а не создавайте заголовки в JavaScript страницы.

Поля пересылаемой идентичности

Посредники часто используют Via, Forwarded и X-Forwarded-For, но их наличие: вопрос политики. Прокси может добавить, сохранить или удалить их. Forwarded способен описывать адрес клиента, протокол и хост при прохождении запроса через посредников. Поскольку эти поля могут содержать чувствительные сетевые данные, доверяйте им только от известных переходов прокси.

Браузер не гарантирует, что прокси добавит конкретный forwarding-заголовок. Если приложение зависит от исходного адреса клиента, явно зафиксируйте контракт прокси и приложения. Если этот адрес не нужен, не принимайте произвольные значения пересылки из интернета.

Поля hop-by-hop и end-to-end

Некоторые поля описывают одно соединение и не должны пересылаться через прокси без изменений. Поле Connection в HTTP/1.1 может перечислять hop-by-hop-поля; прокси удаляет или использует их перед пересылкой. End-to-end-поля, например Cache-Control, предназначены для пути до источника и обратно с учётом обычного поведения посредников.

Это важно при отладке. Заголовок в инструментах разработчика может отличаться от полученного источником. И наоборот, прокси может добавить поле, которого страница не создавала. Если различие важно, захватите обмен браузер-прокси и проверьте журнал на стороне источника.

Возможности браузера, создающие дополнительные запросы

Загрузка страницы: последовательность, а не один запрос. Основной документ может запросить стили, скрипты, изображения, шрифты, frames, preload, workers, manifest и API. Для каждого URL выбираются отдельное назначение и состояние кэша. Политика, работающая для документа, может сломаться на хосте шрифта или API.

Перенаправления: распространённый пример. Ответ 301, 302, 303, 307 или 308 заставляет браузер отправить новый запрос к другой authority. Обработка метода и тела зависит от кода и правил браузера. Новый запрос по-прежнему использует настроенный прокси, но может потребовать нового DNS-запроса, нового решения об аутентификации и нового TLS-туннеля.

Cookies тоже пересекают границы запросов. Set-Cookie от одного хоста влияет на следующие запросы по правилам domain, path, secure и same-site. Прокси видит cookies в открытом HTTP, но не внутри HTTPS-туннеля. Журнал, где записан только первый запрос, не объяснит все последующие изменения состояния.

Сервис-воркер добавляет ещё один уровень. После установки он может вернуть fetch из кэша или программно создать запрос. Отсутствие записи в сети не доказывает обход прокси: возможно, сеть не понадобилась. Обратная ситуация также возможна: воркер обращается к API-хосту, которого нет в исходном документе.

Не-HTTP-трафик требует отдельной проверки. WebSocket начинает с HTTP-handshake, но затем становится долгоживущим двунаправленным потоком. Медиа- и data-каналы WebRTC используют ICE и могут обращаться к STUN- или TURN-серверам вне обычного HTTP. Документация WebRTC API в MDN объясняет, почему такие потоки нужно тестировать отдельно. Руководство, охватывающее только GET и CONNECT, не является полной сетевой инвентаризацией.

Практический метод проверки

Надёжная проверка сравнивает намерение браузера, полученное прокси и наблюдение источника. Следующая последовательность разделяет эти наблюдения.

1. Создайте базовый вариант

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

2. Проверьте handshake прокси

Используйте журнал доступа прокси или контролируемую тестовую конечную точку. Для HTTP подтвердите получение absolute-form. Для HTTPS подтвердите CONNECT с ожидаемой authority и успешный ответ туннеля. 407 означает незавершённую аутентификацию прокси. Отказ или timeout указывают на проблему маршрута или политики до обращения к источнику.

3. Проверьте вид источника

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

4. Проверьте граф запросов

Откройте страницу с перенаправлением, cross-origin изображением, шрифтом, iframe, worker и fetch-вызовом. Добавьте несуществующее имя и хост с записями IPv4 и IPv6. Это показывает, одинаково ли работают разрешение имён, выбор семейства адресов и аутентификация прокси после первого документа.

5. Повторите с прогретым состоянием

Повторите навигацию после создания cookies, сервис-воркера и записей кэша. Сравните сетевые запросы с холодным запуском. Исчезнувший запрос может означать попадание в кэш, а не изменение маршрута. Между контролируемыми опытами очищайте состояние и записывайте, какое состояние использовалось.

Частые симптомы и их значение

Если HTTP-страницы открываются, а HTTPS нет, проверьте авторизацию CONNECT, политику целевого порта и ошибки TLS-сертификата. Если документ загружается, но API не работает, проверьте имя API-хоста, ответ CORS и не обработал ли вызов сервис-воркер. Если не работают только некоторые домены, сравните их DNS-записи и список разрешённых адресов прокси. Неожиданный адрес клиента на источнике требует проверки Forwarded и X-Forwarded-For на каждом посреднике.

Не считайте одну внешнюю страницу «мой IP» полной проверкой. Она измеряет один HTTP-путь и может быть закэширована, перенаправлена или обслуживаться CDN. Проверки по стандартам и журналы обеих сторон дают намного более надёжное объяснение поведения браузера.

Выбор конфигурации для согласованных запросов

Используйте HTTP-прокси, если нужна обычная схема прямого проксирования и поставщик поддерживает HTTP- и HTTPS-направления. Выбирайте SOCKS, когда провайдеру или приложению нужен более общий TCP-релей; заранее уточните, где разрешается имя хоста. Руководство по конфигурации прокси описывает URL для разных протоколов и работу с учётными данными в BotBrowser.

Держите один источник истины для настроек прокси. Смешивание прокси командной строки, proxy-объекта фреймворка автоматизации и перехвата запросов на уровне страницы создаёт конфликтующие маршруты. Настройте учётные данные через поддерживаемый интерфейс браузера или фреймворка и подтвердите результат (407 и CONNECT) по журналам.

Согласуйте географический выход прокси с ожиданиями приложения, если от региона зависит контент, но не считайте, что IP определяет все сигналы браузера. Локаль, часовой пояс, язык, DNS, WebRTC и семейство адресов могут быть независимыми. Для WebRTC используйте отдельный тест из руководства об утечке IP WebRTC.

Наконец, документируйте границы сервиса прокси: принимаемые протоколы, разрешённые порты, место разрешения DNS, ротацию учётных данных, добавляемые заголовки и срок хранения журналов. Такой операционный контракт превращает расплывчатую «проблему прокси» в проверяемый путь запроса.

Семантика HTTP-прокси предсказуема, если определить каждый переход. Читайте форму запроса, различайте 407 и 401, понимайте, когда CONNECT создаёт туннель, и проверяйте полный граф запросов браузера. Это упрощает отладку автоматизации и обычного просмотра без предположений о том, что прокси делает «за кулисами».

Источники

• RFC 9110: HTTP Semantics
• RFC 9112: HTTP/1.1
• MDN: HTTP overview
• MDN: CONNECT method
• MDN: HTTP authentication