O nome do host do proxy de encaminhamento falta no pedido

Suponha que east.proxy.example e west.proxy.example resolvem para o mesmo ouvinte de proxy HTTP simples. Um cliente que use qualquer dos nomes pode enviar:

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

O pedido identifica o site. Não transporta o apelido do proxy que o cliente resolveu antes de abrir TCP. Por isso o nome do host do Express derivado de Host não pode escolher uma rota com base nesses subdomínios do proxy.

Se controla o cliente e o proxy, forneça uma entrada de encaminhamento explícita. Para um proxy que implementa uma etiqueta X-Route:

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

--proxy-header visa a comunicação com o proxy, incluindo CONNECT. Um cabeçalho -H comum no pedido HTTPS pertence à troca HTTP cifrada do destino.

O servidor tem de implementar e autorizar a política de encaminhamento e depois consumir a etiqueta sem a reencaminhar para o site. Em alternativa, use pontos finais de escuta ou contas de proxy configurados separadamente como entradas de encaminhamento.

Para destinos HTTPS, o Node recebe o pedido de túnel inicial através do evento connect do seu servidor HTTP. O middleware de pedidos do Express comum não trata esse evento. O alvo CONNECT continua a identificar o servidor de destino, não o apelido do proxy.