Dieser lange Support-Thread behandelt viele Anfängerthemen, aber das nützlichste durchsuchbare Ergebnis findet sich offenbar auf Seite 3: Ein Jellyfin-Server funktionierte lokal, DuckDNS wurde aufgelöst und ein SSL-Zertifikat war vorhanden, doch die öffentliche Domain gab 502 Bad Gateway zurück. Die Community trennte das Problem schließlich in drei Ebenen: Nginx Proxy Managers Zugriff auf Jellyfin, die TLS-Konfiguration und die Belegung von Port 443 durch den Router.
Der entscheidende Durchbruch kam, als der Benutzer den eigenen NAS-Dienst des Routers auf Port 443 deaktivierte. Danach erreichten sowohl HTTP als auch HTTPS Jellyfin.
Ein 502-Fehler bedeutete, dass der Proxy Jellyfin nicht erreichen konnte
Bei der Fehlersuche konzentrierte sich die Community zunächst auf das Upstream-Ziel von Nginx Proxy Manager. Jellyfins normaler HTTP-Dienst lief auf Port 8096; der Proxy musste Anfragen per HTTP an den Jellyfin-Container weiterleiten, anstatt Jellyfins optionalen HTTPS-Port als Upstream zu verwenden.
Auch die aktuellen Jellyfin-Anleitungen verwenden dasselbe Modell: Die Nginx-Reverse-Proxy-Beispiele leiten normalen Datenverkehr und WebSockets über Port 8096 an Jellyfin weiter.
Proxy und Jellyfin benötigen einen erreichbaren Docker-Pfad
Zu einem Zeitpunkt funktionierte die Verwendung des Containernamens nicht, daher stellte der Helfer aus der Community den Proxy auf Jellyfins interne Docker-Adresse um. Dadurch begann der HTTP-Zugriff zu funktionieren.
Die Verwendung der sich ändernden internen IP-Adresse eines Containers ist weniger robust, als beide Dienste in ein kontrolliertes gemeinsames Docker-Netzwerk mit stabiler Auflösung über Servicenamen aufzunehmen. Der Quellthread dokumentiert, was in dieser Installation funktioniert hat, nicht ein ideales Compose-Design für jeden Server.
HTTP-Routing vor dem Hinzufügen von SSL beheben
Eine große Ursache für Verwirrung war, dass TLS-Optionen geändert wurden, während der Proxy Jellyfin noch nicht erreichen konnte. Die Community entfernte vorübergehend SSL vom Proxy-Host, überprüfte zuerst das reine HTTP-Routing und aktivierte anschließend das Zertifikat wieder und erzwang HTTPS.
Diese Reihenfolge bei der Fehlersuche ist wertvoller, als eine bestimmte IP-Adresse zu kopieren: Zuerst das Upstream-Routing überprüfen, danach TLS diagnostizieren.
Der Router belegte Port 443
Nachdem HTTP Jellyfin endlich öffnete, wurde der Benutzer beim erneuten Aktivieren von HTTPS zur Anmeldeseite des Routers geleitet. Das war der deutlichste Hinweis im Thread: Eingehende Verbindungen auf Port 443 wurden vom eigenen NAS-/Verwaltungsdienst des Routers verarbeitet, statt an Nginx Proxy Manager weitergeleitet zu werden.
Der Benutzer deaktivierte den internen NAS-Dienst des Routers auf Port 443 und bestätigte anschließend, dass HTTPS funktionierte.
Funktionierendes HTTPS aus dem Internet garantiert keine lokale App-Erkennung
Später befasste sich der Thread mit Roku- und Smartphone-Clients. Der Zugriff über die öffentliche Domain funktionierte im Browser, aber die lokale automatische Erkennung sowie Hairpin-/NAT-Loopback-Verbindungen blieben uneinheitlich. Die Community nutzte schließlich DLNA als praktische Roku-Alternative.
Diese nachgelagerte Problematik sollte nicht mit dem gelösten 502-/HTTPS-Pfad vermischt werden. Das Routing über einen Reverse Proxy aus dem Internet und die lokale Geräteerkennung sind voneinander getrennte Netzwerkverhalten.
Dies war Netzwerkhilfe aus der Community, keine IceWhale-Sicherheitsanleitung
Die detaillierten Schritte zum Reverse Proxy stammten von Teilnehmern aus der Community. Die Bereitstellung von Jellyfin über eine Domain erfordert sorgfältige Einstellungen für Router, TLS, Authentifizierung und Updates. Veröffentliche keine anderen administrativen ZimaOS-Dienste, nur weil Port 443 an einen Reverse Proxy weitergeleitet wird.
Jellyfin-NPM-FAQ
Was verursachte den 502 Bad Gateway?
Nginx Proxy Manager konnte den Jellyfin-Upstream zunächst nicht korrekt erreichen. Nachdem das Routing korrigiert war, wurde Jellyfin über HTTP geladen.
Warum öffnete HTTPS die Anmeldeseite des Routers?
Der Router selbst verwendete Port 443. Durch das Deaktivieren oder Verschieben dieses Router-Dienstes konnte Port 443 Nginx Proxy Manager erreichen.
Sollte NPM intern per HTTP oder HTTPS auf Jellyfin zugreifen?
Die erfolgreiche Konfiguration aus dem Thread und Jellyfins aktuelle Nginx-Beispiele verwenden HTTP zum Jellyfin-Dienst auf Port 8096, wobei TLS am Reverse Proxy beendet wird.
Führt Remote-HTTPS dazu, dass Jellyfin auf Roku automatisch erkannt wird?
Nein. Client-Erkennung, WLAN-Isolierung, Docker-Netzwerk und NAT-Loopback sind voneinander getrennte Themen.
