Vidarebefordringsproxyns värdnamn saknas i begäran

Anta att east.proxy.example och west.proxy.example pekar på samma enkla HTTP-proxylyssnare. En klient som använder något av namnen kan skicka:

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

Begäran identifierar webbplatsen. Den bär inte det proxyalias som klienten löste upp innan TCP öppnades. Därför kan Express värdnamn, som härleds från Host, inte välja en rutt baserat på dessa proxysubdomäner.

Om du kontrollerar klienten och proxyn, tillhandahåll en explicit routinginmatning. För en proxy som implementerar en X-Route-etikett:

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

--proxy-header riktar sig mot kommunikationen med proxyn, inklusive CONNECT. En vanlig -H-rubrik i HTTPS-begäran hör hemma inne i målets krypterade HTTP-utbyte.

Servern måste implementera och auktorisera routingpolicyn och sedan använda etiketten utan att vidarebefordra den till webbplatsen. Alternativt kan du använda separat konfigurerade lyssningsändpunkter eller proxykonton som routinginmatning.

För HTTPS-mål tar Node emot den inledande tunnelbegäran via connect-händelsen i sin HTTP-server. Vanlig Express-begärandemiddleware hanterar inte den händelsen. CONNECT-målet identifierar fortfarande målservern, inte proxyaliaset.