Catch-All 규칙을 추가한 후 하나의 도메인이 잘못된 앱으로 연결되는 리버스 프록시 문제 해결 방법

에바 왕

IceWhale author

에바 왕 는 기술 작가 그리고 이자 ZimaSpace의 상주 장인입니다. 평생을 기술에 열정을 가진 사람으로서 홈랩과 오픈소스 소프트웨어에 열정을 가지고 있으며,복잡한 기술 개념을 쉽게 이해할 수 있는 실습 가이드로 번역하는 데 전문성을 가지고 있습니다.에바는 셀프 호스팅이 어렵지 않고 재미있어야 한다고 믿습니다. 그녀의 튜토리얼을 통해 커뮤니티가 하드웨어 설정의 신비를 풀도록돕고 있습니다. 첫 NAS 구축부터 Docker 컨테이너 마스터링까지.

How to Fix a Reverse Proxy That Sends One Domain to the Wrong App After Adding a Catch-All Rule - Zima Store Online

새로운 포괄 경로가 더 넓게 일치하거나 의도한 호스트 규칙보다 우선순위가 높아지면, 리버스 프록시가 한 도메인을 잘못된 앱으로 보낼 수 있습니다.

이는 일반적인 잘못된 도메인 리디렉션이나 DNS 문제보다 범위가 좁습니다. 핵심 테스트는 올바른 도메인이 여전히 예상한 프록시 IP와 인증서에 도달하지만, 새로운 기본 경로가 존재할 때만 프록시가 잘못된 백엔드를 선택하는지 확인하는 것입니다. DNS, 애플리케이션 기본 URL 또는 인증서를 변경하기 전에 경로 일치와 우선순위를 비교하세요.

포괄 규칙이 백엔드 선택을 변경했음을 입증하기

새로운 포괄 또는 기본 경로만 비활성화한 전후로 동일한 도메인 요청을 전송하세요. 프록시 액세스 로그, 선택된 라우터 또는 서버 블록, 백엔드 주소, 응답 식별자, 인증서를 기록합니다.

실용적인 Nginx 기본 서버 가이드에서는 여러 개의 명시적 가상 호스트가 이미 존재하더라도 포괄 규칙이 트래픽을 가로챌 수 있음을 경고합니다.

대체 경로를 비활성화했을 때 의도한 앱이 즉시 복원된다면 DNS와 백엔드 애플리케이션은 변경하지 마세요. 다음 작업은 알 수 없는 호스트 이름에 대한 안전한 대체 동작을 제거하지 않고 특정 경로가 우선하도록 만드는 것입니다.

특정 호스트 규칙이 여전히 정확히 일치하는지 확인하기

요청된 호스트 이름과 의도한 경로 규칙을 문자 단위로 비교하세요. 서브도메인, 와일드카드 경계, 테스트 도구에서의 끝점, 그리고 해당 규칙이 포괄 경로와 동일한 HTTP 또는 HTTPS 진입점을 수신하는지까지 확인해야 합니다.

멀티 앱 리버스 프록시 가이드에서는 호스트 이름 규칙이 서로 다른 백엔드를 선택함을 보여주지만, 이는 수신 호스트가 프록시가 실제로 불러온 규칙과 일치할 때만 가능합니다.

우선순위를 조정하기 전에 불완전하거나 잘못 입력된 호스트 일치 조건을 수정하세요. 전혀 일치하지 않는 규칙의 우선순위만 높이면 설정을 이해하기 더 어려워집니다.

포괄 경로와 라우팅 우선순위 비교하기

명시적 또는 파생 우선순위를 지원하는 프록시에서는 특정 호스트와 광범위한 대체 경로가 동일한 요청에 모두 일치할 때 어떤 규칙이 승리하는지 확인하세요. 설정 파일 순서뿐 아니라 실제로 평가된 규칙을 기록해야 합니다.

Traefik 포괄 라우터 예시에서는 일반 애플리케이션 경로가 먼저 적용되도록 대체 경로에 실제 경로보다 낮은 우선순위를 의도적으로 부여합니다.

모든 의도한 애플리케이션 경로보다 대체 경로의 우선순위를 낮게 설정한 뒤 다시 테스트하세요. 모든 라우터에 임의의 매우 큰 숫자를 부여해 문제를 해결하지 마세요. 향후 앱을 추가해도 유지되는 단순하고 문서화된 우선순위 체계를 사용해야 합니다.

-15% OFF

ZimaBoard 2 - 당신의 큰 아이디어를 위한 미니 홈 서버

Single board computer zimaboard2

Nginx 스타일 프록시에서 기본 서버 확인하기

Nginx 및 유사한 설정에서는 호스트 이름이 일치하지 않을 때 해당 수신 주소와 포트에서 어떤 서버 블록이 기본값이 되는지 확인하세요. 명시적인 기본값이 정의되지 않았다면 먼저 로드된 블록이 대체 경로가 될 수 있습니다.

집중적인 Nginx 문제 해결 문서에서는 일치하지 않는 호스트가 기본 서버로 전달되는 이유를 설명합니다.

실제 애플리케이션을 대체 경로로 지정하는 대신 중립적인 기본 응답이나 오류 서비스를 사용하세요. 이렇게 하면 알 수 없거나 잘못 입력된 호스트 이름이 다른 셀프 호스팅 앱을 실수로 노출하지 못합니다.

HTTP와 HTTPS 대체 경로를 별도로 확인하기

포트 80에 추가한 포괄 경로가 포트 443에서도 자동으로 동일하게 동작하는 것은 아닙니다. TLS 라우팅, SNI, 별도의 진입점 또는 두 번째 포괄 경로로 인해 HTTPS 요청만 잘못된 앱에 도달할 수 있습니다.

Caddy 문제 해결 사례에서는 스킴에 따라 다르게 동작하는 포괄 경로를 설명하며, 스킴별 경로를 직접 테스트해야 하는 이유를 보여줍니다.

동일한 호스트 이름으로 HTTP와 HTTPS를 모두 요청하고 선택된 핸들러를 기록하세요. 정상적으로 작동하는 프로토콜 경로를 변경하지 말고 영향을 받는 진입점의 대체 경로를 수정하세요.

대체 경로를 중립적으로 유지하고 알려진 모든 도메인을 다시 테스트하기

일치 범위나 우선순위를 수정한 후에는 모든 알 수 없는 호스트 이름을 하나의 운영 앱으로 프록시하는 대신 대체 경로가 중립적인 404, 421 또는 제어된 오류 페이지를 반환하도록 설정하세요. 그런 다음 알려진 각 셀프 호스팅 도메인을 한 번씩 테스트합니다.

리버스 프록시 아키텍처 개요에서는 요청이 프록시에 도달한 후 프록시가 백엔드를 결정함을 강조합니다. 따라서 DNS가 올바르다는 사실만으로는 라우팅이 올바르다고 입증할 수 없습니다.

알려진 모든 호스트 이름이 의도한 앱에 도달하고, 알 수 없는 호스트 이름은 중립적인 대체 경로에만 도달하면 수정이 완료된 것입니다. 프록시가 올바른 백엔드를 선택했지만 이후 애플리케이션이 도메인을 변경하는 경우에는 리버스 프록시가 다른 도메인으로 리디렉션하는 경우에 대한 관련 ZimaSpace 문서로 이동하세요.