Ten długi wątek pomocy technicznej obejmuje wiele tematów dla początkujących, ale jego najbardziej przydatne i łatwe do wyszukania rozwiązanie znajduje się na stronie 3: serwer Jellyfin działał lokalnie, DuckDNS poprawnie rozwiązywał nazwę, a certyfikat SSL istniał, jednak domena publiczna zwracała błąd 502 Bad Gateway. Społeczność ostatecznie podzieliła problem na trzy warstwy: połączenie Nginx Proxy Manager z Jellyfin, konfigurację TLS oraz obsługę portu 443 przez router.
Ostateczny przełom nastąpił po wyłączeniu własnej usługi NAS routera na porcie 443. Następnie zarówno HTTP, jak i HTTPS zaczęły docierać do Jellyfin.
Błąd 502 oznaczał, że serwer proxy nie mógł połączyć się z Jellyfin
W pierwszej kolejności podczas rozwiązywania problemu społeczność skupiła się na serwerze docelowym Nginx Proxy Manager. Zwykła usługa HTTP Jellyfin działała na porcie 8096; serwer proxy musiał przekazywać ruch do kontenera Jellyfin przez HTTP, zamiast traktować opcjonalny port HTTPS Jellyfin jako serwer docelowy.
Aktualne zalecenia Jellyfin wykorzystują ten sam model: przykłady odwrotnego serwera proxy Nginx przekazują zwykły ruch i WebSockety do Jellyfin na porcie 8096.
Serwer proxy i Jellyfin potrzebują dostępnej ścieżki Docker
W pewnym momencie użycie nazwy kontenera nie działało, więc pomocnik ze społeczności przełączył serwer proxy na wewnętrzny adres Docker Jellyfin. Dzięki temu ścieżka HTTP zaczęła działać.
Używanie zmieniającego się wewnętrznego adresu IP kontenera jest mniej niezawodne niż umieszczenie obu usług we wspólnej, kontrolowanej sieci Docker ze stabilnym rozpoznawaniem nazw usług. Wątek źródłowy opisuje rozwiązanie działające w tamtej instalacji, a nie idealny projekt Compose dla każdego serwera.
Najpierw napraw routing HTTP, dopiero potem dodaj SSL
Dużym źródłem nieporozumień była zmiana opcji TLS, gdy serwer proxy nadal nie mógł połączyć się z Jellyfin. Społeczność tymczasowo usunęła SSL z hosta proxy, najpierw zweryfikowała zwykłe przekierowanie HTTP, a dopiero potem ponownie włączyła certyfikat i wymuszanie HTTPS.
Ta kolejność diagnostyki jest cenniejsza niż kopiowanie dowolnego adresu IP: najpierw potwierdź routing do serwera docelowego, a dopiero potem diagnozuj TLS.
Router zajmował port 443
Gdy HTTP w końcu otworzył Jellyfin, ponowne włączenie HTTPS przekierowywało użytkownika do strony logowania routera. Była to najmocniejsza wskazówka w całym wątku: przychodzący ruch na porcie 443 był obsługiwany przez własną funkcję NAS/zarządzania routera, zamiast być przekazywany do Nginx Proxy Manager.
Użytkownik wyłączył wewnętrzną usługę NAS routera na porcie 443, a następnie potwierdził, że HTTPS działa.
Działające zdalne HTTPS nie gwarantowało wykrywania lokalnych aplikacji
W dalszej części wątku omawiano klientów Roku i telefonów. Dostęp przez przeglądarkę za pośrednictwem domeny publicznej działał, ale lokalne automatyczne wykrywanie oraz działanie hairpin/NAT loopback pozostawały niespójne. Społeczność ostatecznie wykorzystała DLNA jako praktyczne obejście dla Roku.
Nie należy mieszać tego uzupełniającego problemu z rozwiązanym procesem dotyczącym błędu 502/HTTPS. Zdalny routing przez odwrotny serwer proxy i lokalne wykrywanie urządzeń to odrębne zachowania sieci.
Była to pomoc społeczności dotycząca sieci, a nie recepta bezpieczeństwa IceWhale
Szczegółowe instrukcje dotyczące odwrotnego serwera proxy pochodziły od uczestników społeczności. Udostępnienie Jellyfin przez domenę wymaga starannej konfiguracji routera, TLS, uwierzytelniania i aktualizacji. Nie publikuj niezwiązanych usług administracyjnych ZimaOS tylko dlatego, że port 443 jest przekierowany do odwrotnego serwera proxy.
FAQ dotyczące Jellyfin i NPM
Co spowodowało błąd 502 Bad Gateway?
Nginx Proxy Manager początkowo nie mógł poprawnie połączyć się z serwerem Jellyfin. Po skorygowaniu routingu Jellyfin zaczął ładować się przez HTTP.
Dlaczego HTTPS otwierał stronę logowania routera?
Router sam korzystał z portu 443. Wyłączenie tej usługi routera lub przeniesienie jej na inny port pozwoliło kierować port 443 do Nginx Proxy Manager.
Czy NPM powinien przekazywać ruch do Jellyfin wewnętrznie przez HTTP czy HTTPS?
W działającej konfiguracji opisanej w wątku oraz w aktualnych przykładach Nginx dla Jellyfin używa się HTTP do usługi Jellyfin na porcie 8096, a TLS kończy się na odwrotnym serwerze proxy.
Czy zdalne HTTPS sprawi, że Jellyfin będzie automatycznie wykrywany przez Roku?
Nie. Wykrywanie klienta, izolacja Wi‑Fi, sieć Docker i NAT loopback to odrębne kwestie.
