리버스 프록시는 백엔드 또는 미들웨어가 잘못된 공개 호스트 이름을 기준으로 리디렉션을 생성할 때, 한 앱을 다른 앱의 도메인으로 보낼 수 있습니다.
ZimaSpace 셀프 호스팅 스택에서는 여러 앱이 동일한 프록시를 공유하면서도 각자 고유한 공개 기본 URL을 요구할 수 있습니다. Host, X-Forwarded-Host, 스킴, 미들웨어 또는 앱 수준의 표준 URL이 다른 서비스를 가리키면 첫 페이지는 정상적으로 로드되더라도 다음 301, 302 또는 로그인 콜백에서 도메인이 바뀔 수 있습니다.
백엔드로 전송되는 Host와 스킴 확인
리디렉션을 재현하는 동안 프록시와 백엔드에서 요청 헤더를 캡처합니다.
전달된 호스트와 스킴이 백엔드에 도달하는지 다루는 실용적인 리버스 프록시 구현 가이드는 기본 프로토콜만 정의하는 것이 아니라 동일한 세부 문제를 다루므로 이 원인을 분리하는 데 도움이 됩니다.
앱 URL을 변경하기 전에 프록시 헤더를 바로잡으세요. 백엔드가 요청이 다른 호스트를 통해 들어왔다고 인식하면 올바른 절대 리디렉션을 생성할 수 없습니다.
X-Forwarded-Host를 별도로 확인
일부 프레임워크는 절대 URL을 생성할 때 원본 Host 헤더 대신 X-Forwarded-Host를 사용합니다.
X-Forwarded-Host가 공개 호스트 이름을 유지하는 방식을 설명하는 실용적인 HTTP 헤더 해설은 기본 프로토콜만 정의하는 것이 아니라 동일한 세부 문제를 다루므로 이 원인을 분리하는 데 도움이 됩니다.
정상 작동하는 앱과 잘못된 곳으로 리디렉션되는 앱에서 이 헤더를 비교하세요. 모든 백엔드가 하나의 도메인을 사용하도록 강제하는 전역 재정의를 제거하세요.
앱이 절대 URL을 생성하는지 확인
프록시 헤더를 신뢰하고 표준 링크 또는 리디렉션을 생성하도록 설정된 프레임워크 옵션을 찾아보세요.
프록시 뒤에서 절대 URL이 잘못될 수 있는 상황을 다루는 실제 프록시 디버깅 글은 기본 프로토콜만 정의하는 것이 아니라 동일한 세부 문제를 다루므로 이 원인을 분리하는 데 도움이 됩니다.
모든 리디렉션을 엣지에서 다시 작성하기보다 프레임워크의 프록시 신뢰 설정 또는 공개 URL 설정을 수정하세요.
앱 기본 URL 또는 표준 도메인 확인
많은 셀프 호스팅 앱은 프록시 규칙과 별도로 사이트 URL을 저장합니다.
애플리케이션 기본 URL이 프록시 호스트 이름을 재정의할 수 있는 상황을 다루는 실용적인 프록시 환경 사례 연구는 기본 프로토콜만 정의하는 것이 아니라 동일한 세부 문제를 다루므로 이 원인을 분리하는 데 도움이 됩니다.
마이그레이션 또는 복원 후 저장된 앱 URL 값을 비교하세요. 복사한 데이터베이스에 다른 앱 환경의 표준 호스트 이름이 남아 있을 수 있습니다.
백엔드 앞단의 리디렉션 미들웨어 점검
프록시 규칙은 요청이 애플리케이션에 도달하기 전에 스킴 또는 호스트를 의도적으로 다시 작성할 수 있습니다.
리디렉션 미들웨어가 호스트를 바꿀 수 있는 방식을 다루는 홈랩 Traefik 사용 가이드는 기본 프로토콜만 정의하는 것이 아니라 동일한 세부 문제를 다루므로 이 원인을 분리하는 데 도움이 됩니다.
테스트용 라우터 하나에서 의심되는 리디렉션 미들웨어만 비활성화하세요. HTTPS 강제 적용과 도메인 간 리디렉션은 분리해서 운영하세요.
OAuth 및 OIDC 콜백 URL 확인
인증 흐름에서는 공급자가 정확히 일치하는 리디렉션 URI를 검증하기 때문에 잘못된 공개 호스트 이름이 드러나는 경우가 많습니다.
OIDC 콜백이 공개 프록시 URL에 의존하는 방식을 다루는 OIDC 문제 해결 글은 기본 프로토콜만 정의하는 것이 아니라 동일한 세부 문제를 다루므로 이 원인을 분리하는 데 도움이 됩니다.
발급자, 콜백, 전달된 헤더 및 앱 기본 URL을 함께 비교하세요. 일반 페이지가 정상적으로 로드된다고 해서 로그인 콜백 경로까지 올바르다는 의미는 아닙니다.
정확한 홈 서버 경로로 다시 테스트
변수 하나를 변경한 후에는 다른 경로를 사용할 수 있는 별도의 테스트로 바꾸지 말고, 동일한 클라이언트에서 같은 NAS 또는 셀프 호스팅 작업 흐름을 반복하세요.
관련 홈 서버 네트워크 경로를 다루는 ZimaSpace 가이드는 최종 확인을 동일한 셀프 호스팅 환경에 맞추는 데 도움이 됩니다.
재연결, 서비스 재시작 및 두 번째로 통제된 전송 또는 요청 후에도 원래 증상이 해결된 상태로 유지될 때에만 문제가 완전히 해결된 것입니다.
자주 묻는 질문
DNS가 HTTP 301 또는 302를 발생시킬 수 있나요?
DNS는 주소만 반환합니다. 리디렉션은 프록시, 인증 계층 또는 애플리케이션이 생성합니다.
브라우저가 도메인을 변경하기 전에 올바른 앱이 로드되는 이유는 무엇인가요?
초기 프록시 라우팅은 올바르더라도 백엔드가 잘못된 기본 URL 또는 전달된 호스트를 기준으로 이후 절대 리디렉션을 생성할 수 있습니다.
프록시에서 모든 Location 헤더를 다시 작성해야 하나요?
아니요. 먼저 잘못된 호스트 이름의 출처를 수정하세요. 광범위한 응답 재작성은 애플리케이션 설정 오류를 숨길 수 있습니다.
지원 및 팁
더 읽어보기

Plex가 다른 Docker 컨테이너와 GPU를 공유할 수 있나요?
Plex와 다른 컨테이너가 동일한 GPU에 함께 액세스할 수 있는 경우가 많지만, 드라이버 지원, 디바이스 매핑, 비디오 엔진 부하, 메모리, 복구 동작을 테스트해야 합니다.

Plex 오류가 클라이언트에서 발생한 것인지 서버에서 발생한 것인지 확인하는 방법
다른 클라이언트에서 동일한 항목을 재현하고, 세션 경로를 비교한 다음, 범위 분석을 통해 장애가 실제로 발생한 위치를 확인한 후에만 서버 증거를 수집하세요.

Plex 캐시 및 트랜스코딩 임시 저장소 구성 방법
영구 Plex 상태는 보호하면서 트랜스코딩 임시 파일은 적합한 로컬 저장소에 배치한 다음, 정리 상태와 여유 공간 및 재시작 동작을 확인하세요.

