Jellyfin può funzionare dietro un proxy inverso su un sottopercorso?

Sì. Jellyfin può funzionare dietro un reverse proxy su un sottopercorso come https://example.com/jellyfin, ma Jellyfin e il proxy devono utilizzare lo stesso percorso di base.

Un errore del sottopercorso di solito si manifesta come un sito che funziona solo in parte: la pagina di accesso può caricarsi, mentre JavaScript, immagini, WebSocket, reindirizzamenti o client nativi possono non funzionare. Testa il percorso a livelli: prima il Base URL, poi la route del proxy e infine le intestazioni inoltrate e l'indirizzo del client. In questo modo puoi distinguere un problema di mancata corrispondenza del percorso da un problema di TLS o di identificazione del proxy.

Fai corrispondere il Base URL di Jellyfin al sottopercorso pubblico

Imposta il Base URL di Jellyfin sul prefisso pubblico esatto che intendi utilizzare, ad esempio /jellyfin. Non aggiungere un prefisso interno diverso solo perché il proxy utilizza un blocco di posizione con nome: il percorso visibile nel browser e il Base URL di Jellyfin devono descrivere la stessa radice dell'applicazione.

La documentazione ufficiale di Jellyfin sul reverse proxy Apache fornisce esplicitamente un esempio con sottopercorso e indica agli amministratori di impostare il Base URL su /jellyfin prima di collegare i client a quell'indirizzo completo. esempio ufficiale di sottopercorso

Riavvia Jellyfin dopo aver modificato il Base URL, quindi apri il sottopercorso pubblico in una nuova finestra privata del browser. Se il reindirizzamento iniziale rimuove immediatamente /jellyfin o lo duplica, correggi il Base URL prima di intervenire sulle impostazioni WebSocket o di autenticazione.

Instrada lo stesso prefisso attraverso il reverse proxy

Configura il reverse proxy in modo che le richieste che iniziano con il prefisso pubblico vengano inoltrate a Jellyfin senza introdurre trasformazioni aggiuntive del percorso. La configurazione più semplice prevede un prefisso pubblico, un Base URL di Jellyfin corrispondente e un servizio upstream.

La guida di Caddy per Jellyfin mostra lo stesso schema: configura il percorso di base di Jellyfin, reindirizza il prefisso senza barra finale alla versione con barra finale e inoltra al backend Jellyfin le richieste che utilizzano quel prefisso. percorso di base e route del proxy corrispondenti

Se il browser riceve un errore 404 dal proxy prima che Jellyfin registri la richiesta, la route è errata a livello di proxy. Se Jellyfin riceve la richiesta ma genera collegamenti privi del prefisso, il Base URL è errato a livello applicativo. Mantieni distinti questi due segnali di errore.

Controlla risorse statiche e WebSocket, non solo la pagina di accesso

Una risposta HTML corretta non basta per considerare sana la configurazione del sottopercorso. Apri gli strumenti per sviluppatori o il log del proxy e verifica che le richieste JavaScript, CSS, di immagini, API e WebSocket rimangano tutte sotto lo stesso prefisso pubblico.

Gli esempi di reverse proxy di Jellyfin includono la gestione dei WebSocket perché i client interattivi mantengono una connessione socket oltre alle normali richieste HTTP. Una regola del proxy che gestisce solo le richieste delle pagine può quindi sembrare corretta finché non si interrompono lo stato della riproduzione, gli aggiornamenti della sessione o il comportamento dell'interfaccia in tempo reale. requisiti del reverse proxy

La condizione di riuscita è semplice: non devono verificarsi ripetuti errori 404/502 per le risorse con prefisso, il WebSocket deve completare correttamente l'upgrade e la navigazione non deve uscire verso la radice del sito. Se fallisce una sola classe di richieste, correggi quella regola del proxy invece di modificare la libreria o le impostazioni di autenticazione di Jellyfin.

Featured

ZimaCube 2 NAS personale cloud domestico

ZimaCube2

$799.00 - $2,499.00

Buy Now

Preserva l'identità del client attraverso il proxy

Dopo aver verificato il funzionamento del percorso, controlla le informazioni inoltrate del client. Jellyfin utilizza la configurazione di attendibilità del proxy per decidere se accettare gli indirizzi e i protocolli inoltrati; questo influisce sul comportamento locale o remoto e sulle regole di accesso esterno.

La guida al networking di Jellyfin avverte che le intestazioni inoltrate da un proxy non attendibile vengono scartate e consiglia di configurare l'indirizzo del proxy nella sezione Proxy conosciuti. impostazione Proxy conosciuti Un controllo separato dell'IP del client è utile quando il sito funziona, ma ogni richiesta sembra provenire dal proxy.

Non risolvere un problema di identità fidandoti di ogni sottorete privata o di ogni intestazione inoltrata. Aggiungi solo il passaggio effettivo del proxy o una rete proxy controllata, quindi confronta nei log di Jellyfin una richiesta dalla LAN e una remota per verificare che vengano classificate come previsto.

Testa separatamente gli indirizzi del browser e dei client nativi

Inserisci l'indirizzo completo del server, incluso il sottopercorso, quando un client Jellyfin richiede l'URL del server. Un client salvato come https://example.com non può dedurre che Jellyfin si trovi sotto /jellyfin.

Testa un browser e un client nativo dalla LAN, quindi ripeti il test utilizzando l'hostname pubblico. Se l'hostname funziona ma l'accesso diretto tramite IP locale non funziona, potrebbe essere normale quando la route del proxy e il certificato dipendono dall'hostname; test tra hostname e IP aiuta a isolare il caso senza indebolire il proxy.

Interrompi i test quando l'URL con prefisso supera l'accesso, la navigazione, l'utilizzo dei WebSocket e la riproduzione sui client effettivamente supportati. Se non funziona solo un client mentre il browser e gli altri client funzionano, consideralo un problema relativo all'indirizzo o alla compatibilità del client, invece di riscrivere una configurazione del proxy che funziona.