Kann Jellyfin hinter einem Reverse-Proxy in einem Unterpfad betrieben werden?

Eva Wong

IceWhale author

Eva Wong ist die Technische Redakteurin und und leidenschaftliche Tüftlerin bei ZimaSpace. Eine lebenslange Geek mit einer Leidenschaft für Homelabs und Open-Source-Software, sie spezialisiert sich darauf, komplexe technische Konzepte in zugängliche, praktische Anleitungenzu übersetzen. Eva ist der Meinung, dass Self-Hosting Spaß machen und nicht einschüchternd sein sollte. Durch ihre Tutorials befähigt sie die Community, Hardware-Setups zu entmystifizieren, vom Bau ihres ersten NAS bis hin zur Beherrschung von Docker-Containern.

Can Jellyfin Work Behind a Reverse Proxy on a Subpath? - Zima Store Online

Ja. Jellyfin kann hinter einem Reverse-Proxy unter einem Unterpfad wie https://example.com/jellyfin betrieben werden, aber Jellyfin und der Proxy müssen denselben Basispfad verwenden.

Ein Fehler beim Unterpfad zeigt sich meist als teilweise funktionierende Website: Die Anmeldeseite wird möglicherweise geladen, während JavaScript, Bilder, WebSockets, Weiterleitungen oder native Clients ausfallen. Testen Sie den Pfad schrittweise – zuerst die Basis-URL, dann die Proxy-Route und zuletzt weitergeleitete Header sowie die Client-Adresse –, damit Sie einen Pfadkonflikt von einem TLS- oder Proxy-Identitätsproblem unterscheiden können.

Die Jellyfin-Basis-URL an den öffentlichen Unterpfad anpassen

Setzen Sie die Basis-URL von Jellyfin auf das genaue öffentliche Präfix, das Sie verwenden möchten, zum Beispiel /jellyfin. Fügen Sie kein anderes internes Präfix hinzu, nur weil der Proxy einen benannten Location-Block verwendet; der im Browser sichtbare Pfad und die Jellyfin-Basis-URL müssen denselben Anwendungsstamm beschreiben.

Die Apache-Dokumentation von Jellyfin für Reverse-Proxys enthält ausdrücklich ein Beispiel für einen Unterpfad und weist Administratoren an, die Basis-URL auf /jellyfin zu setzen, bevor Clients mit dieser vollständigen Adresse verbunden werden. offizielles Unterpfad-Beispiel

Starten Sie Jellyfin nach der Änderung der Basis-URL neu und öffnen Sie den öffentlichen Unterpfad in einem neuen privaten Browserfenster. Wenn die anfängliche Weiterleitung /jellyfin sofort entfernt oder doppelt einfügt, korrigieren Sie die Basis-URL, bevor Sie WebSocket- oder Authentifizierungseinstellungen ändern.

Dasselbe Präfix durch den Reverse-Proxy weiterleiten

Konfigurieren Sie den Reverse-Proxy so, dass Anfragen, die mit dem öffentlichen Präfix beginnen, an Jellyfin weitergeleitet werden, ohne eine zusätzliche Pfadänderung zu erfinden. Das einfachste Design besteht aus einem öffentlichen Präfix, einer passenden Jellyfin-Basis-URL und einem Upstream-Dienst.

Der Jellyfin-Leitfaden für Caddy zeigt dasselbe Muster: Konfigurieren Sie den Jellyfin-Basispfad, leiten Sie das Präfix ohne abschließenden Schrägstrich auf die Variante mit abschließendem Schrägstrich weiter und proxien Sie Anfragen unter diesem Präfix an das Jellyfin-Backend. passender Basispfad und passende Proxy-Route

Wenn der Browser einen 404-Fehler vom Proxy erhält, bevor Jellyfin die Anfrage protokolliert, ist die Route auf der Proxy-Ebene falsch. Wenn Jellyfin die Anfrage empfängt, aber Links ohne das Präfix erzeugt, ist die Basis-URL auf der Anwendungsebene falsch. Halten Sie diese beiden Fehlersignaturen getrennt.

Statische Ressourcen und WebSockets prüfen, nicht nur die Anmeldeseite

Eine erfolgreiche HTML-Antwort reicht nicht aus, um die Unterpfad-Konfiguration als fehlerfrei zu betrachten. Öffnen Sie die Entwicklertools oder das Proxy-Protokoll und überprüfen Sie, dass JavaScript-, CSS-, Bild-, API- und WebSocket-Anfragen alle unter demselben öffentlichen Präfix bleiben.

Die Reverse-Proxy-Beispiele von Jellyfin enthalten eine WebSocket-Konfiguration, da interaktive Clients zusätzlich zu normalen HTTP-Anfragen eine Socket-Verbindung aufrechterhalten. Eine Proxy-Regel, die nur Seitenanfragen verarbeitet, kann daher zunächst korrekt erscheinen, bis Wiedergabestatus, Sitzungsaktualisierungen oder dynamische Oberflächenfunktionen ausfallen. Anforderungen an den Reverse-Proxy

Die Erfolgsbedingung ist einfach: keine wiederholten 404-/502-Antworten für Ressourcen mit Präfix, die WebSocket-Verbindung wird erfolgreich hochgestuft und die Navigation führt nicht zum Stammverzeichnis der Website. Wenn nur eine Anfrageklasse fehlschlägt, reparieren Sie diese Proxy-Regel, statt die Bibliotheks- oder Authentifizierungseinstellungen von Jellyfin zu ändern.

Featured

ZimaCube 2 Persönliche Cloud Home NAS

ZimaCube2

Die Client-Identität durch den Proxy bewahren

Nachdem der Pfad funktioniert, überprüfen Sie die weitergeleiteten Client-Informationen. Jellyfin verwendet die Proxy-Vertrauenseinstellungen, um zu entscheiden, ob weitergeleitete Adressen und Protokolle akzeptiert werden sollen. Dies beeinflusst das Verhalten für lokale und entfernte Verbindungen sowie die Regeln für den externen Zugriff.

Der Jellyfin-Netzwerkleitfaden warnt davor, dass Header von einem nicht vertrauenswürdigen Proxy verworfen werden, und empfiehlt, die Proxy-Adresse unter „Bekannte Proxys“ zu konfigurieren. Einstellung „Bekannte Proxys“ Eine separate Prüfung der Client-IP ist hilfreich, wenn die Website funktioniert, aber jede Anfrage so erscheint, als stamme sie vom Proxy.

Lösen Sie kein Identitätsproblem, indem Sie jedem privaten Subnetz oder jedem weitergeleiteten Header vertrauen. Fügen Sie nur den tatsächlichen Proxy-Hop oder ein kontrolliertes Proxy-Netzwerk hinzu und vergleichen Sie anschließend eine Anfrage aus dem LAN mit einer entfernten Anfrage in den Jellyfin-Protokollen, um zu bestätigen, dass beide wie erwartet klassifiziert werden.

Browser- und native Client-Adressen getrennt testen

Geben Sie die vollständige Serveradresse einschließlich des Unterpfads ein, wenn ein Jellyfin-Client nach der Server-URL fragt. Ein Client, der unter https://example.com gespeichert ist, kann nicht automatisch erkennen, dass Jellyfin unter /jellyfin läuft.

Testen Sie einen Browser und einen nativen Client aus dem LAN und wiederholen Sie den Test anschließend über den öffentlichen Hostnamen. Wenn der Hostname funktioniert, der direkte Zugriff über die lokale IP-Adresse jedoch nicht, kann dies erwartungsgemäß sein, wenn Proxy-Route und Zertifikat vom Hostnamen abhängen; Tests mit Hostname und IP-Adresse helfen, diesen Fall zu isolieren, ohne den Proxy zu schwächen.

Beenden Sie den Test, wenn die URL mit Präfix Anmeldung, Navigation, WebSocket-Nutzung und Wiedergabe auf den tatsächlich unterstützten Clients übersteht. Wenn nur ein Client fehlschlägt, während Browser und andere Clients funktionieren, behandeln Sie dies als Problem mit der Client-Adresse oder der Client-Kompatibilität, statt eine funktionierende Proxy-Konfiguration umzuschreiben.