Den här långa supporttråden tar upp många nybörjarämnen, men det mest användbara och sökbara resultatet verkar finnas på sida 3: en Jellyfin-server fungerade lokalt, DuckDNS löste adressen och ett SSL-certifikat fanns, men den offentliga domänen returnerade 502 Bad Gateway. Communityn delade så småningom upp problemet i tre lager: Nginx Proxy Managers anslutning till Jellyfin, TLS-konfigurationen och routerns hantering av port 443.
Det avgörande genombrottet kom när användaren inaktiverade routerns egen NAS-tjänst på port 443. Därefter nådde både HTTP och HTTPS Jellyfin.
Ett 502-fel innebar att proxyn inte kunde nå Jellyfin
Felsökningen i communityn fokuserade först på Nginx Proxy Managers mål för uppströmsanslutningen. Jellyfins vanliga HTTP-tjänst fanns på port 8096; proxyn behövde vidarebefordra till Jellyfin-containern via HTTP i stället för att behandla Jellyfins valfria HTTPS-port som uppströmsanslutning.
Aktuella riktlinjer för Jellyfin använder samma modell: Jellyfins Nginx-exempel för reverse proxy vidarebefordrar vanlig trafik och WebSockets till Jellyfin på port 8096.
Proxyn och Jellyfin behöver en nåbar Docker-väg
Vid ett tillfälle fungerade det inte att använda containernamnet, så communityns hjälpare ändrade proxyn till Jellyfins interna Docker-adress. Då började HTTP-vägen fungera.
Att använda en containers föränderliga interna IP-adress är mindre robust än att placera båda tjänsterna i ett kontrollerat, gemensamt Docker-nätverk med stabil namnupplösning för tjänster. Källtråden dokumenterar vad som fungerade i den installationen, inte en idealisk Compose-design för alla servrar.
Åtgärda HTTP-dirigeringen innan du lägger till SSL
En stor källa till förvirring var att TLS-alternativen ändrades medan proxyn fortfarande inte kunde nå Jellyfin. Communityn tog tillfälligt bort SSL från proxyvärden, verifierade vanlig HTTP-dirigering först och återställde därefter certifikatet och tvingad HTTPS.
Den här felsökningsordningen är mer värdefull än att kopiera en viss IP-adress: bevisa först att uppströmsdirigeringen fungerar och felsök sedan TLS.
Routern använde port 443
När HTTP till slut öppnade Jellyfin skickade aktivering av HTTPS tillbaka användaren till routerns inloggningssida. Det var den tydligaste ledtråden i tråden: inkommande trafik på port 443 hanterades av routerns egen NAS-/administrationsfunktion i stället för att vidarebefordras till Nginx Proxy Manager.
Användaren inaktiverade routerns interna NAS-tjänst på port 443 och bekräftade sedan att HTTPS fungerade.
Fungerande fjärråtkomst via HTTPS garanterade inte lokal appidentifiering
Tråden undersökte senare Roku- och telefonklienter. Åtkomst via webbläsare genom den offentliga domänen fungerade, men lokal automatisk identifiering och hairpin-/NAT-loopback-beteende förblev inkonsekventa. Communityn använde till slut DLNA som en praktisk lösning för Roku.
Den uppföljningen bör inte blandas ihop med den lösta vägen för 502/HTTPS. Fjärråtkomst via reverse proxy och lokal enhetsidentifiering är separata nätverksbeteenden.
Detta var nätverkshjälp från communityn, inte ett säkerhetsrecept från IceWhale
De detaljerade stegen för reverse proxy kom från deltagare i communityn. Att exponera Jellyfin via en domän kräver noggranna rutiner för router, TLS, autentisering och uppdateringar. Publicera inte orelaterade administrativa ZimaOS-tjänster bara för att port 443 vidarebefordras till en reverse proxy.
Vanliga frågor om Jellyfin och NPM
Vad orsakade 502 Bad Gateway?
Nginx Proxy Manager kunde inledningsvis inte nå Jellyfins uppströmsanslutning korrekt. När dirigeringen korrigerades lästes Jellyfin in via HTTP.
Varför öppnade HTTPS routerns inloggningssida?
Routern använde själv port 443. Genom att inaktivera eller flytta den routertjänsten kunde port 443 nå Nginx Proxy Manager.
Bör NPM proxya Jellyfin via HTTP eller HTTPS internt?
Den fungerande konfigurationen i tråden och Jellyfins aktuella Nginx-exempel använder HTTP till Jellyfin-tjänsten på port 8096, medan TLS avslutas vid reverse proxyn.
Gör fjärråtkomst via HTTPS att Jellyfin automatiskt identifieras på Roku?
Nej. Klientidentifiering, Wi-Fi-isolering, Docker-nätverk och NAT-loopback är separata problem.
