Kan Jellyfin achter een reverse proxy op een subpad werken?

Ja. Jellyfin kan achter een reverseproxy werken op een subpad, zoals https://example.com/jellyfin, maar Jellyfin en de proxy moeten hetzelfde basispad gebruiken.

Een probleem met een subpad ziet er meestal uit als een gedeeltelijk werkende website: de aanmeldpagina kan laden, terwijl JavaScript, afbeeldingen, WebSockets, omleidingen of native clients niet werken. Test het pad in lagen—eerst de basis-URL, daarna de proxyrout en pas als laatste doorgestuurde headers en het clientadres—zodat je een niet-overeenkomend pad kunt onderscheiden van een TLS- of proxy-identiteitsprobleem.

Laat de basis-URL van Jellyfin overeenkomen met het openbare subpad

Stel de basis-URL van Jellyfin in op het exacte openbare voorvoegsel dat je wilt gebruiken, bijvoorbeeld /jellyfin. Voeg geen ander intern voorvoegsel toe alleen omdat de proxy een benoemd locatieblok gebruikt; het pad dat in de browser zichtbaar is en de basis-URL van Jellyfin moeten naar dezelfde toepassingsroot verwijzen.

De Apache-documentatie van Jellyfin voor reverseproxy's bevat expliciet een voorbeeld met een subpad en geeft beheerders de instructie om de basis-URL in te stellen op /jellyfin voordat clients met dat volledige adres worden verbonden. officieel voorbeeld van een subpad

Start Jellyfin opnieuw nadat je de basis-URL hebt gewijzigd en open het openbare subpad in een nieuw privébrowservenster. Als de eerste omleiding /jellyfin onmiddellijk verwijdert of verdubbelt, los dan eerst de basis-URL op voordat je WebSocket- of authenticatie-instellingen aanpast.

Stuur hetzelfde voorvoegsel door via de reverseproxy

Configureer de reverseproxy zo dat aanvragen die met het openbare voorvoegsel beginnen naar Jellyfin worden doorgestuurd zonder een extra padtransformatie te verzinnen. Het eenvoudigste ontwerp bestaat uit één openbaar voorvoegsel, één overeenkomstige basis-URL van Jellyfin en één upstreamservice.

De Caddy-handleiding voor Jellyfin toont hetzelfde patroon: configureer het basispad van Jellyfin, stuur het kale voorvoegsel door naar de vorm met een afsluitende slash en proxy aanvragen onder dat voorvoegsel naar de Jellyfin-backend. overeenkomstig basispad en proxyrout

Als de browser een 404 van de proxy ontvangt voordat Jellyfin de aanvraag logt, is de route op proxyniveau onjuist. Als Jellyfin de aanvraag ontvangt maar koppelingen zonder het voorvoegsel genereert, is de basis-URL op applicatieniveau onjuist. Houd deze twee foutsignaturen gescheiden.

Controleer statische assets en WebSockets, niet alleen de aanmeldpagina

Een geslaagde HTML-respons is niet voldoende om de configuratie van het subpad als gezond te beschouwen. Open de ontwikkelaarstools of het proxylogboek en controleer of aanvragen voor JavaScript, CSS, afbeeldingen, API's en WebSockets allemaal hetzelfde openbare voorvoegsel behouden.

De voorbeelden voor reverseproxy's van Jellyfin bevatten WebSocket-verwerking, omdat interactieve clients naast gewone HTTP-aanvragen ook een socketverbinding onderhouden. Een proxyrule die alleen pagina-aanvragen verwerkt, kan daarom correct lijken totdat de afspeelstatus, sessie-updates of live-interfacefunctionaliteit uitvalt. vereisten voor reverseproxy's

De geslaagde toestand is eenvoudig: geen herhaalde 404/502-antwoorden voor assets met het voorvoegsel, de WebSocket-upgrade slaagt en navigatie springt niet naar de hoofdmap van de site. Als slechts één aanvraagtype faalt, herstel dan die proxyrule in plaats van de bibliotheek- of authenticatie-instellingen van Jellyfin te wijzigen.

Featured

ZimaCube 2 Persoonlijke Cloud Home NAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

Behoud de clientidentiteit via de proxy

Controleer nadat het pad werkt de doorgestuurde clientinformatie. Jellyfin gebruikt de proxy-vertrouwensconfiguratie om te bepalen of doorgestuurde adressen en protocollen moeten worden geaccepteerd. Dit heeft invloed op lokaal versus extern gedrag en regels voor externe toegang.

De netwerkhandleiding van Jellyfin waarschuwt dat doorgestuurde headers van een niet-vertrouwde proxy worden genegeerd en adviseert om het proxyadres te configureren onder Bekende proxy's. instelling voor bekende proxy's Een afzonderlijke controle van het client-IP is nuttig wanneer de site werkt, maar elke aanvraag afkomstig lijkt te zijn van de proxy.

Los een identiteitsprobleem niet op door elk privénetwerk of elke doorgestuurde header te vertrouwen. Voeg alleen de daadwerkelijke proxyhop of het beheerde proxynetwerk toe en vergelijk vervolgens één LAN-aanvraag met één externe aanvraag in de Jellyfin-logboeken om te bevestigen dat ze naar verwachting worden geclassificeerd.

Test browser- en native clientadressen afzonderlijk

Voer het volledige serveradres in, inclusief het subpad, wanneer een Jellyfin-client om de server-URL vraagt. Een client die is opgeslagen als https://example.com kan niet automatisch afleiden dat Jellyfin onder /jellyfin staat.

Test één browser en één native client vanaf het LAN en herhaal dit via de openbare hostnaam. Als de hostnaam werkt maar directe lokale IP-toegang niet, kan dat verwacht zijn wanneer de proxyrout en het certificaat afhankelijk zijn van de hostnaam; testen met hostnaam versus IP-adres helpt dit geval te isoleren zonder de proxy te verzwakken.

Stop wanneer de URL met het voorvoegsel inloggen, navigatie, WebSocket-gebruik en afspelen doorstaat op de clients die je daadwerkelijk ondersteunt. Als slechts één client faalt terwijl de browser en andere clients wel werken, behandel dit dan als een probleem met het clientadres of de clientcompatibiliteit in plaats van een werkende proxyconfiguratie opnieuw te schrijven.