Die vierte Seite einer langen ZimaOS-Supportdiskussion behandelt die wiederkehrenden Jellyfin- und Nginx-Proxy-Manager-Probleme eines Benutzers nach der ersten erfolgreichen Einrichtung des Fernzugriffs. Die wichtige Erkenntnis ist nicht ein einzelner magischer Port: Ein 502-Fehler kann erneut auftreten, wenn sich das Reverse-Proxy-Ziel, die Jellyfin-Portzuordnung, das Docker-Netzwerk oder der Anwendungsstatus ändert.
Diese Seite konzentriert sich ausschließlich auf die Beiträge 61–80. Die zuvor behandelte Einrichtung von DuckDNS und Zertifikaten wird nicht wiederholt.
Trenne die NPM-API-Meldung vom Jellyfin-502-Fehler
Zuerst sah der Benutzer „Kommunikation mit der API fehlgeschlagen. Läuft NPM ordnungsgemäß?“. Die Auswertung der Community-Protokolle zeigte, dass Nginx Proxy Manager selbst lief und die Erneuerung von Let's Encrypt erfolgreich war. Die vorübergehende API-Meldung konnte daher auf eine veraltete Browsersitzung oder eine kurzzeitige Unterbrechung der Verbindung zwischen Benutzeroberfläche und Backend zurückzuführen sein, während der öffentliche 502-Fehler ein separates Proxy-zu-Jellyfin-Problem blieb.
Halte die drei Adresstypen getrennt
| Adresstyp | Beispielrolle | Soll NPM dorthin weiterleiten? |
|---|---|---|
| Öffentliche WAN-Adresse | Von DuckDNS aktualisierte, aus dem Internet erreichbare Adresse | Nein |
| ZimaOS-LAN-Adresse | Stabile Adresse im Heimnetzwerk wie 192.168.1.50
|
Ja, wenn Jellyfin einen Host-Port veröffentlicht |
| Docker-Containeradresse oder -name | Interner Endpunkt wie jellyfin:8096
|
Ja, aber nur, wenn NPM dasselbe Docker-Netzwerk erreichen kann |
Im Thread wurde wiederholt zwischen einem Containernamen, einer LAN-Adresse des Hosts und einer internen Docker-Adresse gewechselt. Diese sind nicht austauschbar. Wähle eine unterstützte Route und teste sie aus dem NPM-Container, bevor du TLS oder DNS änderst.
Lies die Portzuordnung in der richtigen Richtung
Die Jellyfin-Einstellungen zeigten den Host-Port 8097 dem Container-Port zugeordnet 8096Wenn NPM über die ZimaOS-LAN-Adresse eine Verbindung herstellt, muss es den veröffentlichten Host-Port verwenden. Wenn NPM direkt über den Containernamen in einem gemeinsam genutzten Docker-Netzwerk eine Verbindung herstellt, verwendet es normalerweise den internen Port von Jellyfin.
Ein Verbindungsabbruch innerhalb von NPM zeigte, dass die ausgewählte Route weiterhin keine gültige Jellyfin-Antwort lieferte. Das ist aussagekräftiger, als einfach beide Container neu zu starten.
Verwende eine schrittweise Diagnose
- Öffne Jellyfin lokal und bestätige die Wiedergabe, bevor du den Proxy anfasst.
- Bestätige, dass der Jellyfin-Container läuft, und lies seine gespeicherte Host-/Container-Portzuordnung aus.
- Wähle entweder die stabile ZimaOS-LAN-Adresse plus veröffentlichten Host-Port oder einen Containernamen plus internen Port in einem gemeinsam genutzten Netzwerk.
- Teste genau diesen Endpunkt aus der NPM-Umgebung.
- Erst wenn das HTTP-Routing funktioniert, solltest du TLS wieder aktivieren und die öffentliche Domain testen.
- Nach jeder App-Änderung oder jedem Neustart solltest du die lokalen und Proxy-Tests wiederholen, bevor du DNS änderst.
Eine Änderung des Medienpfads kann einen anderen Fehler auslösen
Später konnten Remote-Benutzer Jellyfin durchsuchen, aber keine Medien abspielen. Der Besitzer änderte die Container-Einstellungen von Jellyfin, woraufhin die öffentliche Website nicht mehr reagierte. Eine anschließende Überprüfung der Community-Protokolle zeigte, dass Jellyfin lief und /Media/Moviesverwies und die Aufmerksamkeit wieder auf das Proxy-Ziel lenkte. Dies zeigt, warum jede Änderung unabhängig dokumentiert und getestet werden sollte.
Bei Sicherungen muss die Groß- und Kleinschreibung von Linux-Pfaden beachtet werden
Eine Konfigurationssicherung schlug fehl, weil der Befehl auf /DATA/AppData/duckdns, während das tatsächliche Verzeichnis /DATA/AppData/DuckDNS. Linux behandelt diese als unterschiedliche Pfade. Im Ausgangsthread wurde ein von der Community erstellter Archivierungsbefehl vorgeschlagen, aber er stammte nicht von IceWhale und wird daher hier nicht als offizielle Sicherungsanleitung wiedergegeben.
Vor der Archivierung von AppData solltest du die exakten Verzeichnisnamen auflisten, Anwendungen stoppen, wenn deren Datenbanken einen konsistenten Snapshot erfordern, und das Archiv überprüfen, indem du eine Kopie an einem temporären Ort wiederherstellst.
Aktuell unterstützter Remotezugriff
Für die Verwaltung und den Dateizugriff dokumentiert das aktuelle ZimaOS den verschlüsselten Peer-to-Peer-Zugriff über den Remotezugriff mit ZimaClient. Ein öffentlicher Jellyfin-Reverse-Proxy bleibt ein fortgeschrittener Workflow eines Drittanbieters und sollte ausschließlich den Mediendienst, nicht das ZimaOS-Dashboard, erreichbar machen.
Jellyfin-FAQ zu 502-Fehlern
Beweist „NPM API failed“, dass NPM gestoppt ist?
Nein. Im Thread waren die NPM-Protokolle und die Zertifikatserneuerung fehlerfrei, während der Browser diese Meldung anzeigte.
Soll NPM Port 8096 oder 8097 verwenden?
Verwende bei direkter Container-Netzwerkverbindung den internen Port oder bei der Weiterleitung an die ZimaOS-LAN-Adresse den veröffentlichten Host-Port.
Warum wurde bei der Sicherung angegeben, dass DuckDNS nicht vorhanden sei?
Der tatsächliche AppData-Ordner verwendete ein großes D, ebenso wie DNS; bei Linux wird zwischen Groß- und Kleinschreibung in Pfaden unterschieden.
