east.proxy.example과 west.proxy.example이 같은 일반 HTTP 프록시 리스너로 해석된다고 가정합니다. 어느 이름을 쓰든 클라이언트는 다음을 보낼 수 있습니다.

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

요청이 식별하는 것은 웹사이트입니다. TCP를 열기 전에 클라이언트가 해석한 프록시 별칭은 담기지 않습니다. 따라서 Express의 Host에서 파생된 hostname은 그 프록시 하위 도메인을 근거로 경로를 고를 수 없습니다.

클라이언트와 프록시를 모두 제어한다면 명시적인 라우팅 입력을 제공하세요. X-Route 라벨을 구현하는 프록시라면:

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

--proxy-header는 CONNECT를 포함해 프록시와의 통신을 대상으로 합니다. HTTPS 요청의 일반 -H 헤더는 목적지의 암호화된 HTTP 교환 안쪽에 속합니다.

서버는 라우팅 정책을 구현하고 승인한 뒤, 라벨을 웹사이트로 전달하지 않고 소비해야 합니다. 또는 별도로 구성한 수신 엔드포인트나 프록시 계정을 라우팅 입력으로 사용하세요.

HTTPS 목적지의 경우 Node는 최초 터널 요청을 자체 HTTP 서버의 connect 이벤트로 받습니다. 일반 Express 요청 미들웨어는 그 이벤트를 처리하지 않습니다. 그 CONNECT 대상은 여전히 목적지 서버를 가리키며 프록시 별칭이 아닙니다.

관련 글