리버스 프록시가 도메인으로는 작동하지만 로컬 IP로는 작동하지 않는 이유는 무엇인가요?

리버스 프록시는 요청된 호스트명에 따라 라우팅 및 TLS 규칙이 달라지기 때문에 도메인 단위로 작동합니다. 이는 목적지 IP뿐만 아니라 요청된 호스트명에 의존합니다.

홈 클라이언트가 https://app.example.com을 열면 DNS가 IP를 제공하지만 브라우저는 여전히 TLS 핸드셰이크와 HTTP Host 헤더를 통해 도메인을 전송합니다. https://192.168.1.20을 열면 이러한 식별자가 변경되어 프록시가 기본 사이트를 선택하거나 인증서를 거부하거나 애플리케이션 경로를 놓치거나 구성된 공개 URL로 리디렉션할 수 있습니다. 올바른 테스트는 의도한 호스트명을 유지하면서 네트워크 목적지만 변경하는 것입니다.

호스트명 요청과 직접 IP 요청 비교하기

도메인에 한 번, 로컬 IP에 한 번 요청을 보내고 상태 코드, 인증서, 응답 헤더, 리디렉션 위치, 리버스 프록시 접근 로그를 비교하세요. 두 요청이 동일한 이더넷 인터페이스에 도달한다고 해서 동일하다고 가정하지 마십시오.

홈랩 리버스 프록시 안내서는 프록시가 HTTP Host 헤더를 검사하여 하나의 IP와 포트로 여러 서비스를 라우팅하는 방식을 설명합니다.

도메인 요청이 애플리케이션 경로와 일치하고 IP 요청이 기본 페이지나 404를 반환하면 프록시가 올바르게 작동하는 것입니다. 다음 결정은 직접 IP 접근이 실제로 필요한지, 아니면 로컬 DNS가 도메인을 유지해야 하는지 여부입니다.

의도한 Host 헤더를 유지하며 로컬 IP 테스트하기

애플리케이션 도메인을 Host 헤더로 보내면서 로컬 프록시 IP에 연결하는 클라이언트 도구를 사용하세요. HTTPS의 경우 IP로 대체하지 말고 TLS 서버 이름으로 도메인을 유지해야 합니다.

Server Fault는 HTTP 리버스 프록시가 Host 헤더를 사용해 경로를 선택하는 방법을 이름 기반 가상 호스트와 동일하게 사용하는 방식을 설명합니다.

강제 Host 요청이 성공하면 프록시 경로와 백엔드가 정상이며, 직접 IP 실패는 신원 불일치입니다. 여전히 실패하면 리스너, 로컬 방화벽, 프록시 진입점, 경로 우선순위를 점검한 후 DNS를 변경하세요.

TLS SNI 및 인증서 일치 확인하기

HTTPS는 HTTP 요청 전에 호스트명 결정을 추가합니다. 클라이언트는 보통 TLS 핸드셰이크 중에 서버 이름 표시(Server Name Indication)를 보내 프록시가 올바른 인증서와 보안 가상 호스트를 선택할 수 있게 합니다.

SNI 리버스 프록시 구현은 HTTPS 백엔드가 클라이언트의 SNI 호스트명을 사용해 일반 HTTP 헤더를 검사하기 전에 선택된다고 설명합니다.

IP로 직접 접근하면 프록시가 도달 가능해도 기본 인증서를 제시하거나 호스트명 검증에 실패할 수 있습니다. 도메인을 로컬 DNS와 함께 사용하거나 직접 IP HTTPS가 실제 운영 요구사항일 때만 IP를 포함한 관리된 인증서를 배포하세요.

Featured

ZimaCube 2 개인용 클라우드 홈 NAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

기본 사이트 및 경로 우선순위 점검하기

구성된 도메인과 일치하지 않는 요청을 처리하는 가상 호스트를 검토하세요. 기본 사이트는 대시보드를 반환하거나 다른 호스트명으로 리디렉션하거나 연결을 종료하거나 일반 오류를 노출할 수 있습니다.

Caddy 토론에서는 요청이 올바른 프록시 IP에 도달해도 Host 헤더와 TLS 이름이 여전히 의도한 업스트림 선택을 결정한다고 설명합니다.

기본 경로는 명확하고 안전하게 유지하세요. IP 접근을 위해 광범위한 catch-all 프록시를 하나의 백엔드에 추가하지 마십시오. 이는 알 수 없는 호스트명이나 스캔 트래픽이 도메인 제한 애플리케이션으로 라우팅될 수 있기 때문입니다.

애플리케이션이 정식 URL로 리디렉션하는지 확인하기

프록시가 IP 요청을 수락해도 백엔드는 구성된 공개 기본 URL을 강제하고 브라우저를 도메인으로 리디렉션할 수 있습니다. 인증 쿠키, OAuth 콜백, WebSocket 출처, CSRF 검사도 해당 정식 호스트에 의존할 수 있습니다.

프록시 로그와 애플리케이션 로그를 비교하고 Location 헤더를 점검하세요. 도메인으로의 리디렉션은 라우팅 실패가 아니라 애플리케이션이 하나의 공개 신원을 기대한다는 증거입니다.

앱이 잘못된 외부 URL을 생성할 때 전달된 호스트 및 프로토콜 헤더를 올바르게 수정하세요. 리디렉션을 우회하기 위해 정식 도메인을 개인 IP로 대체하지 마십시오. 이는 인증서와 원격 접근을 깨뜨릴 수 있습니다.

도메인이 의도된 인터페이스일 때 로컬 DNS 사용하기

애플리케이션 도메인을 로컬 리버스 프록시 주소로 해석하는 내부 DNS 레코드를 만드세요. 그러면 브라우저는 동일한 Host 헤더, SNI 이름, 인증서, 쿠키, 애플리케이션 URL을 유지하면서 효율적인 LAN 경로를 사용합니다.

ZimaSpace의 리버스 프록시와 개인 접근 경로 비교는 도메인이 로컬 및 공개 진입점으로 남아야 하는지, 아니면 개인 네트워크 뒤에 있어야 하는지 결정하는 데 도움을 줍니다.

도메인이 의도적으로 DNS 응답을 통해 내부와 외부 모두에서 작동하고, 직접 IP는 문서화된 기본 사이트에 도달하거나 의도적으로 거부될 때 문제가 해결됩니다. 도메인 라우팅 프록시는 IP 주소 단일 사이트 서버처럼 동작할 필요가 없습니다.