이 긴 지원 스레드는 초보자를 위한 여러 주제를 다루지만, 검색에 가장 유용한 결론은 3페이지에 나와 있습니다. Jellyfin 서버는 로컬에서 정상 작동했고 DuckDNS도 확인되었으며 SSL 인증서도 있었지만, 공개 도메인에서는 502 Bad Gateway가 반환되었습니다. 커뮤니티에서는 결국 문제를 세 가지 계층으로 나누었습니다. Nginx Proxy Manager가 Jellyfin에 연결되는지, TLS 구성, 그리고 라우터가 포트 443을 관리하고 있는지였습니다.
최종적인 해결책은 라우터 자체의 포트 443 NAS 서비스를 비활성화하는 것이었습니다. 그 후 HTTP와 HTTPS 모두 Jellyfin에 연결되었습니다.
502 오류는 프록시가 Jellyfin에 연결할 수 없다는 의미였습니다
커뮤니티의 초기 문제 해결은 Nginx Proxy Manager의 업스트림 대상에 집중되었습니다. Jellyfin의 일반 HTTP 서비스는 포트 8096에서 실행되고 있었으므로, 프록시는 Jellyfin의 선택적 HTTPS 포트를 업스트림으로 취급하는 대신 HTTP를 통해 Jellyfin 컨테이너로 전달해야 했습니다.
현재 Jellyfin 안내도 같은 방식을 사용합니다. Jellyfin의 Nginx 리버스 프록시 예시는 일반 트래픽과 WebSocket을 포트 8096의 Jellyfin으로 전달합니다.
프록시와 Jellyfin 사이에 연결 가능한 Docker 경로가 필요합니다
한때 컨테이너 이름이 작동하지 않아 커뮤니티 지원 담당자는 프록시가 Jellyfin의 내부 Docker 주소를 사용하도록 변경했습니다. 그 결과 HTTP 경로가 작동하기 시작했습니다.
컨테이너의 변경될 수 있는 내부 IP를 사용하는 방식은 두 서비스를 안정적인 서비스 이름 확인이 가능한 관리형 공유 Docker 네트워크에 배치하는 것보다 견고하지 않습니다. 원문 스레드는 해당 설치 환경에서 작동한 방법을 설명한 것이며, 모든 서버에 적합한 이상적인 Compose 설계를 제시하는 것은 아닙니다.
SSL을 추가하기 전에 HTTP 라우팅을 먼저 해결하세요
프록시가 여전히 Jellyfin에 연결하지 못하는 상태에서 TLS 옵션을 변경한 것이 큰 혼란의 원인이었습니다. 커뮤니티에서는 프록시 호스트에서 SSL을 일시적으로 제거하고, 먼저 일반 HTTP 라우팅을 확인한 다음 인증서를 다시 설정하고 HTTPS 강제 적용을 활성화했습니다.
이 문제 해결 순서는 특정 IP 주소를 그대로 복사하는 것보다 더 중요합니다. 먼저 업스트림 라우팅을 확인한 뒤 TLS를 진단해야 합니다.
라우터가 포트 443을 사용하고 있었습니다
HTTP로 Jellyfin이 마침내 열렸지만 HTTPS를 다시 활성화하자 라우터 로그인 페이지로 이동했습니다. 이는 이 스레드에서 가장 강력한 단서였습니다. 인바운드 포트 443이 Nginx Proxy Manager로 전달되지 않고 라우터 자체의 NAS/관리 기능에서 처리되고 있었던 것입니다.
사용자는 라우터 내부의 포트 443 NAS 서비스를 비활성화했고, 이후 HTTPS가 작동하는 것을 확인했습니다.
원격 HTTPS가 작동한다고 해서 로컬 앱 검색까지 보장되는 것은 아닙니다
이후 스레드에서는 Roku와 휴대폰 클라이언트도 다루었습니다. 공개 도메인을 통한 브라우저 접속은 작동했지만, 로컬 자동 검색과 헤어핀/NAT 루프백 동작은 일관되지 않았습니다. 커뮤니티에서는 결국 Roku의 실용적인 우회 방법으로 DLNA를 사용했습니다.
이 후속 문제는 해결된 502/HTTPS 경로와 혼동해서는 안 됩니다. 원격 리버스 프록시 라우팅과 로컬 장치 검색은 서로 다른 네트워크 동작입니다.
이는 IceWhale의 보안 레시피가 아니라 커뮤니티의 네트워크 지원이었습니다
자세한 리버스 프록시 설정 단계는 커뮤니티 참여자들이 제공했습니다. Jellyfin을 도메인을 통해 외부에 공개하려면 라우터, TLS, 인증 및 업데이트 방식을 신중하게 관리해야 합니다. 포트 443이 리버스 프록시로 전달된다는 이유만으로 관련 없는 ZimaOS 관리 서비스를 외부에 공개하지 마세요.
Jellyfin NPM FAQ
502 Bad Gateway의 원인은 무엇이었나요?
Nginx Proxy Manager가 처음에는 Jellyfin 업스트림에 올바르게 연결하지 못했습니다. 라우팅을 수정한 후 Jellyfin이 HTTP를 통해 로드되었습니다.
HTTPS로 접속하면 왜 라우터 로그인 페이지가 열렸나요?
라우터 자체가 포트 443을 사용하고 있었기 때문입니다. 라우터 서비스를 비활성화하거나 다른 포트로 이동하면 포트 443이 Nginx Proxy Manager에 도달할 수 있습니다.
NPM은 내부적으로 Jellyfin에 HTTP와 HTTPS 중 어떤 방식으로 프록시해야 하나요?
성공한 스레드의 설정과 Jellyfin의 현재 Nginx 예시는 모두 포트 8096의 Jellyfin 서비스에 HTTP로 연결하고, 리버스 프록시에서 TLS를 종료하는 방식을 사용합니다.
원격 HTTPS가 작동하면 Roku에서 Jellyfin이 자동으로 검색되나요?
아니요. 클라이언트 검색, Wi-Fi 격리, Docker 네트워킹 및 NAT 루프백은 서로 별개의 문제입니다.
