Jellyfin을 리버스 프록시의 하위 경로에서 사용할 수 있나요?

예. Jellyfin은 https://example.com/jellyfin과 같은 하위 경로에서 리버스 프록시 뒤에 구성할 수 있지만, Jellyfin과 프록시는 동일한 기본 경로를 사용해야 합니다.

하위 경로 문제는 대개 반쯤 작동하는 사이트처럼 나타납니다. 로그인 페이지는 열리지만 JavaScript, 이미지, WebSocket, 리디렉션 또는 네이티브 클라이언트가 작동하지 않을 수 있습니다. 경로를 계층별로 테스트하세요. 먼저 Base URL을 확인하고, 다음으로 프록시 라우팅, 마지막으로 전달된 헤더와 클라이언트 주소를 확인하면 경로 불일치 문제인지 TLS 또는 프록시 식별 문제인지 구분할 수 있습니다.

Jellyfin의 Base URL을 공개 하위 경로와 일치시키기

사용하려는 정확한 공개 접두사로 Jellyfin의 Base URL을 설정하세요. 예를 들면 /jellyfin입니다. 프록시가 이름이 지정된 location 블록을 사용한다는 이유만으로 다른 내부 접두사를 추가하지 마세요. 브라우저에 표시되는 경로와 Jellyfin의 Base URL은 동일한 애플리케이션 루트를 가리켜야 합니다.

Jellyfin의 Apache 리버스 프록시 문서에는 하위 경로 예제가 명시되어 있으며, 클라이언트를 해당 전체 주소에 연결하기 전에 Base URL을 /jellyfin으로 설정하도록 안내합니다. 공식 하위 경로 예제

Base URL을 변경한 후 Jellyfin을 다시 시작하고, 새 시크릿 브라우저 창에서 공개 하위 경로를 여세요. 초기 리디렉션에서 즉시 /jellyfin이 사라지거나 두 번 추가되면 WebSocket 또는 인증 설정을 건드리기 전에 Base URL을 수정하세요.

리버스 프록시를 통해 동일한 접두사 라우팅하기

공개 접두사로 시작하는 요청이 추가적인 경로 변환 없이 Jellyfin으로 전달되도록 리버스 프록시를 구성하세요. 가장 단순한 구성은 하나의 공개 접두사, 이에 대응하는 하나의 Jellyfin Base URL, 하나의 업스트림 서비스입니다.

Caddy의 Jellyfin 가이드도 동일한 패턴을 보여 줍니다. Jellyfin 기본 경로를 구성하고, 접두사만 있는 주소를 끝에 슬래시가 붙은 형식으로 리디렉션한 다음, 해당 접두사 아래의 요청을 Jellyfin 백엔드로 프록시합니다. 일치하는 기본 경로 및 프록시 라우팅

Jellyfin 로그에 요청이 기록되기 전에 브라우저가 프록시에서 404를 받는다면 프록시 계층의 라우팅이 잘못된 것입니다. Jellyfin이 요청을 받았지만 접두사 없이 링크를 생성한다면 애플리케이션 계층의 Base URL이 잘못된 것입니다. 이 두 가지 오류 양상을 구분해서 확인하세요.

로그인 페이지만이 아니라 정적 자산과 WebSocket도 확인하기

HTML 응답이 성공했다고 해서 하위 경로 구성이 정상이라고 판단해서는 안 됩니다. 개발자 도구 또는 프록시 로그를 열고 JavaScript, CSS, 이미지, API 및 WebSocket 요청이 모두 동일한 공개 접두사 아래에 유지되는지 확인하세요.

Jellyfin의 리버스 프록시 예제에는 WebSocket 처리가 포함되어 있습니다. 대화형 클라이언트는 일반 HTTP 요청과 함께 소켓 연결도 유지하기 때문입니다. 따라서 페이지 요청만 처리하는 프록시 규칙은 재생 상태, 세션 업데이트 또는 실시간 UI 동작이 중단될 때까지 정상처럼 보일 수 있습니다. 리버스 프록시 요구 사항

통과 조건은 간단합니다. 접두사가 포함된 자산에 대해 404/502 응답이 반복되지 않고, WebSocket 업그레이드가 성공하며, 탐색이 사이트 루트로 빠져나가지 않아야 합니다. 특정 요청 유형 하나만 실패한다면 Jellyfin의 라이브러리나 인증 설정을 변경하지 말고 해당 프록시 규칙을 수정하세요.

Featured

ZimaCube 2 개인용 클라우드 홈 NAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

프록시를 통해 클라이언트 식별 정보 유지하기

경로가 작동한 후에는 전달된 클라이언트 정보를 확인하세요. Jellyfin은 프록시 신뢰 설정을 사용해 전달된 주소와 프로토콜을 허용할지 결정하며, 이는 로컬 및 원격 동작과 외부 액세스 규칙에 영향을 줍니다.

Jellyfin 네트워킹 가이드에서는 신뢰할 수 없는 프록시에서 전달된 헤더는 폐기된다고 경고하며, Known Proxies에 프록시 주소를 구성할 것을 권장합니다. Known Proxies 설정 사이트는 작동하지만 모든 요청이 프록시에서 시작된 것으로 표시될 때는 별도의 클라이언트 IP 확인도 유용합니다.

모든 사설 서브넷이나 모든 전달 헤더를 신뢰하도록 설정하여 식별 문제를 해결하지 마세요. 실제 프록시 홉 또는 관리되는 프록시 네트워크만 추가한 다음, Jellyfin 로그에서 LAN 요청 하나와 원격 요청 하나를 비교해 예상대로 분류되는지 확인하세요.

브라우저와 네이티브 클라이언트 주소를 별도로 테스트하기

Jellyfin 클라이언트에서 서버 URL을 요청하면 하위 경로를 포함한 전체 서버 주소를 입력하세요. https://example.com으로 저장된 클라이언트는 Jellyfin이 /jellyfin 아래에 있다는 사실을 자동으로 알아낼 수 없습니다.

LAN에서 브라우저 하나와 네이티브 클라이언트 하나를 테스트한 다음, 공개 호스트 이름을 통해 다시 테스트하세요. 호스트 이름은 작동하지만 로컬 IP에 직접 연결하면 작동하지 않는 경우, 프록시 라우팅과 인증서가 호스트 이름에 의존하기 때문일 수 있습니다. 호스트 이름과 IP 비교 테스트를 사용하면 프록시를 약화하지 않고 이 경우를 구분할 수 있습니다.

지원하려는 클라이언트에서 접두사가 포함된 URL로 로그인, 탐색, WebSocket 사용 및 재생이 모두 정상적으로 이루어질 때까지 확인하세요. 브라우저와 다른 클라이언트는 통과하지만 특정 클라이언트 하나만 실패한다면, 작동 중인 프록시 구성을 다시 작성하지 말고 클라이언트 주소 또는 호환성 문제로 처리하세요.