Предположим, что east.proxy.example и west.proxy.example указывают на один и тот же простой HTTP-прослушиватель прокси. Клиент, использующий любое из этих имён, может отправить:

GET http://www.example.org/report HTTP/1.1
Host: www.example.org

Запрос идентифицирует веб-сайт. Он не содержит псевдоним прокси, который клиент разрешил перед открытием TCP. Поэтому имя хоста Express, производное от Host, не может выбрать маршрут на основе этих поддоменов прокси.

Если вы контролируете клиент и прокси, задайте явный вход маршрутизации. Для прокси, реализующего метку X-Route:

curl --proxy http://east.proxy.example:8080 \
  --proxy-header 'X-Route: east' \
  https://www.example.org/

--proxy-header адресует обмен с прокси, включая CONNECT. Обычный заголовок -H в HTTPS-запросе находится внутри зашифрованного HTTP-обмена с пунктом назначения.

Сервер должен реализовать и авторизовать политику маршрутизации, а затем использовать метку, не передавая её на веб-сайт. В качестве альтернативы используйте отдельно настроенные точки прослушивания или учётные записи прокси как входы маршрутизации.

Для HTTPS-назначений Node получает первоначальный запрос туннеля через событие connect своего HTTP-сервера. Обычное промежуточное ПО запросов Express не обрабатывает это событие. Цель CONNECT по-прежнему определяет сервер назначения, а не псевдоним прокси.

Похожие статьи