HTTP Proxy: посредник клиента, обратный прокси и туннель

RFC 9110 различает клиентский proxy и gateway, также называемый reverse proxy. Метод CONNECT запрашивает туннель до назначения с передачей данных в обе стороны. Название «HTTP-прокси» без схемы не говорит, какая из этих ролей предлагается услугой.

Кто выбирает посредника

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

Не создавайте открытый прокси ради тестового ответа. Доступ, допустимые назначения и ответственность нужно согласовать заранее. Здесь никакого слушающего сервиса, аккаунта или туннеля не создавалось.

Где заканчивается защищенное соединение

Нарисуйте отдельно клиент, посредник и приложение. Уточните, где завершается TLS и есть ли другая защищенная связь дальше. Доступный HTTPS у внешней точки не подтверждает защиту каждого внутреннего участка.

Не устанавливайте чужой центр доверия и не отключайте проверку сертификата как обычный шаг настройки прокси. Если инструкция требует таких действий, нужна отдельная оценка доступа и полномочий. Этот материал не дает разрешения перехватывать трафик пользователей.

Что спросить у поставщика

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

Сравнение должно подтверждать нужную разрешенную операцию, а не только изменение видимого IP. Для вопросов о среде есть VPS для прокси; это отдельное руководство выбора, не определение роли.

Источник прочитан 7 октября 2026 года. Конфигурации клиентов, доверие, firewall и сервер не менялись, обход ограничений не выполнялся. Версии обмена объясняются в HTTP/1.1 и HTTP/2, другие понятия - в словаре.