업스트림 Host 헤더 유지

리버스 프록시는 기본적으로 방문자 요청의 Host를 업스트림에 그대로 전달합니다. 예를 들어 https://nas.example.com에 접속하면 업스트림에도 Host: nas.example.com이 표시됩니다. 애플리케이션은 이 값을 바탕으로 외부 링크를 만들고, 쿠키 도메인을 설정하고, 가상 호스트를 선택하거나 콜백 주소를 검증할 수 있습니다.

시스템 설정 → 게이트웨이 → Host 응답은 Host 라우트를 사용하는 서브도메인 모드에서만 편집할 수 있습니다. 공인 IP로 직접 연결하는 서브도메인 모드와 리버스 프록시 모드 → 서브도메인 매핑이 여기에 해당합니다. 경로 모드와 직접 연결 모드에는 이 항목이 없으며 인증 서비스 Host도 편집 목록에 포함되지 않습니다.

비활성화해야 하는 경우

업스트림이 자체 주소를 Host로 명확히 요구하는 경우가 아니라면 기본값인 활성화 상태를 유지합니다. 다음과 같은 상황에서 비활성화를 고려할 수 있습니다.

• 업스트림 웹 서버에 내부 가상 호스트 이름만 설정된 경우
• 애플리케이션이 Host 허용 목록을 검증하지만 외부 도메인을 아직 추가할 수 없는 경우
• 오래된 애플리케이션이 외부 Host를 받으면 400, 잘못된 리디렉션 또는 다른 사이트를 반환하는 경우

비활성화하면 게이트웨이가 외부 Host를 강제로 유지하지 않고 업스트림이 리버스 프록시 대상(타깃) 주소를 기준으로 Host를 처리합니다. 업스트림의 Host 검증 문제를 해결할 수 있지만 애플리케이션이 127.0.0.1, 컨테이너 서비스 이름 또는 LAN 도메인을 포함한 링크를 만들 수도 있습니다. 변경한 뒤에는 로그인 리디렉션, 절대 링크, 쿠키 및 WebSocket을 반드시 확인합니다.

대상(타깃)별 적용

페이지에는 Host별 스위치가 표시되지만 실행 중인 게이트웨이에서는 업스트림 대상(타깃)을 기준으로 컴파일됩니다. 다음 두 Host는 같은 대상(타깃)을 사용합니다.

photos.example.com -> http://127.0.0.1:8080
files.example.com  -> http://127.0.0.1:8080

한 Host에서 Host 유지 기능을 끄면 이 공유 대상(타깃)을 사용하는 다른 Host에도 영향을 줍니다. 서로 다른 정책이 필요하다면 두 Host에 서로 다른 대상(타깃) 주소를 설정합니다. 최종적으로 같은 애플리케이션에 도달하더라도 별도의 수신 주소, 포트 또는 리버스 프록시 계층으로 구분할 수 있습니다.

경로 응답의 리버스 프록시 동작도 자체 실제 대상(타깃)을 기준으로 같은 런타임 규칙을 사용합니다. 고정 응답에는 업스트림이 없으므로 Host 유지가 적용되지 않습니다.

검증 및 문제 해결

1. 변경 후 저장 및 동기화가 완료되었다는 페이지 안내를 기다립니다.
2. 실제 서비스 도메인으로 접속하여 상태 코드, 리디렉션 주소 및 로그인 절차를 확인합니다.
3. 요청 로그에서 일치한 Host, 라우트 유형 및 업스트림 대상(타깃)을 확인합니다.
4. 업스트림 접근 로그에 수신한 Host를 기록하여 애플리케이션의 예상값과 일치하는지 확인합니다.
5. 여러 Host가 동시에 바뀌었다면 같은 대상(타깃)을 재사용하는지 확인합니다.

Host 유지 설정은 fn-knock가 클라이언트 IP를 식별하는 방식에 영향을 주지 않으며 TLS 인증서나 DNS도 변경하지 않습니다. 클라이언트 출발지는 프록시 헤더로 전달합니다. 자세한 내용은 업스트림으로 프록시 헤더 전달을 참고합니다.

• 서브도메인 매핑
• 경로 응답
• 요청 로그