Supoñamos que east.proxy.example e west.proxy.example resolven no mesmo oínte HTTP simple do proxy. Un cliente que use calquera dos nomes pode enviar:

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

A petición identifica o sitio web. Non leva o alias do proxy que o cliente resolveu antes de abrir TCP. Polo tanto, o nome de host derivado de Host en Express non pode escoller unha ruta baseándose neses subdominios do proxy.

Se controla o cliente e o proxy, proporcione unha entrada de encaminamento explícita. Para un proxy que implemente unha etiqueta X-Route:

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

--proxy-header diríxese á comunicación co proxy, incluído CONNECT. Unha cabeceira -H normal na petición HTTPS pertence ao intercambio HTTP cifrado do destino.

O servidor debe implementar e autorizar a política de encaminamento e despois consumir a etiqueta sen reenviala ao sitio web. Como alternativa, use puntos de escoita ou contas de proxy configurados por separado como entradas de encaminamento.

Para destinos HTTPS, Node recibe a petición inicial do túnel mediante o evento connect do seu servidor HTTP. O middleware de peticións habitual de Express non xestiona ese evento. O seu obxectivo CONNECT segue identificando o servidor de destino, non o alias do proxy.

Artigos relacionados