Deze lange supportthread behandelt veel onderwerpen voor beginners, maar de nuttigste doorzoekbare uitkomst staat waarschijnlijk op pagina 3: een Jellyfin-server werkte lokaal, DuckDNS werd correct omgezet en er was een SSL-certificaat aanwezig, maar het openbare domein gaf 502 Bad Gateway terug. De community splitste het probleem uiteindelijk op in drie lagen: Nginx Proxy Manager die Jellyfin moest bereiken, de TLS-configuratie en het routerbeheer van poort 443.
De definitieve doorbraak kwam toen de gebruiker de eigen NAS-service van de router op poort 443 uitschakelde. Daarna bereikten zowel HTTP als HTTPS Jellyfin.
Een 502-fout betekende dat de proxy Jellyfin niet kon bereiken
Bij het oplossen van het probleem richtte de community zich eerst op het upstreamdoel van Nginx Proxy Manager. De normale HTTP-service van Jellyfin draaide op poort 8096; de proxy moest via HTTP naar de Jellyfin-container doorsturen, in plaats van de optionele HTTPS-poort van Jellyfin als upstream te behandelen.
De huidige Jellyfin-richtlijnen gebruiken hetzelfde model: de Nginx-voorbeelden sturen normaal verkeer en WebSockets door naar Jellyfin op poort 8096.
De proxy en Jellyfin hebben een bereikbaar Docker-pad nodig
Op een bepaald moment werkte het gebruik van de containernaam niet, waarna de helper uit de community de proxy instelde op het interne Docker-adres van Jellyfin. Daardoor begon het HTTP-pad te werken.
Het gebruik van een veranderend intern IP-adres van een container is minder robuust dan beide services op een beheerd gedeeld Docker-netwerk plaatsen, met stabiele resolutie via servicenamen. De bronthread documenteert wat in die installatie werkte, niet een ideaal Compose-ontwerp voor elke server.
Los HTTP-routering op voordat je SSL toevoegt
Een belangrijke bron van verwarring was het aanpassen van TLS-opties terwijl de proxy Jellyfin nog steeds niet kon bereiken. In de community werd tijdelijk SSL van de proxyhost verwijderd, vervolgens werd eerst gewone HTTP-routering gecontroleerd en pas daarna werden het certificaat en de HTTPS-doorverwijzing teruggezet.
Deze volgorde voor probleemoplossing is waardevoller dan het kopiëren van één specifiek IP-adres: bewijs eerst dat de upstream-routering werkt en onderzoek daarna TLS.
De router gebruikte poort 443
Nadat HTTP Jellyfin eindelijk opende, stuurde het opnieuw inschakelen van HTTPS de gebruiker naar de inlogpagina van de router. Dat was de sterkste aanwijzing in de thread: inkomend verkeer op poort 443 werd verwerkt door de eigen NAS-/beheerfunctie van de router, in plaats van doorgestuurd te worden naar Nginx Proxy Manager.
De gebruiker schakelde de interne NAS-service van de router op poort 443 uit en bevestigde daarna dat HTTPS werkte.
Werkende externe HTTPS garandeerde geen lokale appdetectie
Later onderzocht de thread Roku- en telefoonclients. Toegang via de openbare domeinnaam werkte in de browser, maar lokale autodetectie en hairpin-/NAT-loopbackgedrag bleven inconsistent. Uiteindelijk gebruikte de community DLNA als praktische workaround voor Roku.
Deze vervolgvraag moet niet worden vermengd met het opgeloste 502-/HTTPS-pad. Externe reverse-proxy-routering en lokale apparaatdetectie zijn afzonderlijke netwerkfuncties.
Dit was hulp van de community bij netwerken, geen beveiligingsrecept van IceWhale
De gedetailleerde stappen voor de reverse proxy kwamen van deelnemers uit de community. Jellyfin via een domein beschikbaar maken vereist zorgvuldige router-, TLS-, authenticatie- en updatepraktijken. Publiceer geen andere administratieve services van ZimaOS alleen omdat poort 443 naar een reverse proxy wordt doorgestuurd.
Veelgestelde vragen over Jellyfin en NPM
Wat veroorzaakte de 502 Bad Gateway?
Nginx Proxy Manager kon de Jellyfin-upstream aanvankelijk niet correct bereiken. Nadat de routering was gecorrigeerd, laadde Jellyfin via HTTP.
Waarom opende HTTPS de inlogpagina van de router?
De router zelf gebruikte poort 443. Door die routersservice uit te schakelen of te verplaatsen, kon poort 443 Nginx Proxy Manager bereiken.
Moet NPM intern via HTTP of HTTPS naar Jellyfin proxien?
De werkende configuratie uit de thread en de huidige Nginx-voorbeelden van Jellyfin gebruiken HTTP naar de Jellyfin-service op poort 8096, waarbij TLS op de reverse proxy wordt beëindigd.
Zorgt externe HTTPS ervoor dat Jellyfin automatisch op Roku wordt gevonden?
Nee. Clientdetectie, wifi-isolatie, Docker-netwerken en NAT-loopback zijn afzonderlijke problemen.
