Falta el nombre de host del proxy directo en la petición

Suponga que east.proxy.example y west.proxy.example resuelven al mismo receptor HTTP simple del proxy. Un cliente que use cualquiera de los dos nombres puede enviar:

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

La petición identifica el sitio web. No lleva el alias del proxy que el cliente resolvió antes de abrir TCP. Por tanto, el nombre de host derivado de Host en Express no puede elegir una ruta basándose en esos subdominios del proxy.

Si controla el cliente y el proxy, proporcione una entrada de enrutamiento explícita. Para un proxy que implemente una etiqueta X-Route:

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

--proxy-header se dirige a la comunicación con el proxy, incluido CONNECT. Una cabecera -H normal en la petición HTTPS pertenece al intercambio HTTP cifrado del destino.

El servidor debe implementar y autorizar la política de enrutamiento y luego consumir la etiqueta sin reenviarla al sitio web. Como alternativa, use puntos de escucha o cuentas de proxy configurados por separado como entradas de enrutamiento.

Para destinos HTTPS, Node recibe la petición inicial del túnel mediante el evento connect de su servidor HTTP. El middleware de peticiones habitual de Express no gestiona ese evento. Su objetivo CONNECT sigue identificando el servidor de destino, no el alias del proxy.