Perché Jellyfin perde le sessioni dopo una modifica al proxy o al DNS?
Una modifica al proxy o al DNS non dovrebbe eliminare automaticamente tutti gli accessi a Jellyfin. La perdita della sessione si verifica di solito quando la modifica altera anche il nome host, lo schema, il percorso, l’identità del server backend, il livello di autenticazione o il percorso del client previsto dallo stato di accesso esistente.
Inizia distinguendo un semplice aggiornamento del record DNS da una modifica dell’origine. Mantieni invariati un account e un dispositivo noti, confronta l’accesso diretto dalla LAN con il normale nome host pubblico e acquisisci la prima richiesta non riuscita prima di cancellare i dati del client. L’obiettivo è identificare quale confine è cambiato, non reimpostare gli utenti finché il sintomo non scompare.
Per prima cosa, stabilisci se l’origine pubblica è realmente cambiata
Annota lo schema, il nome host, la porta, il percorso di base e il percorso del proxy vecchi e nuovi. Un record DNS A o AAAA può puntare lo stesso nome host a un indirizzo diverso senza modificare l’origine del browser, mentre il passaggio da un nome host a un altro o la modifica del percorso di base dell’applicazione crea un confine client diverso. Le migrazioni verso un dominio personalizzato richiedono inoltre che l’applicazione e il percorso di autenticazione siano allineati al nuovo dominio; una checklist per la migrazione a un dominio personalizzato rende esplicito questo collegamento tra DNS e applicazione.
Lo stato di autenticazione è sensibile al punto in cui viene presentato. Un’utile checklist dell’ambito dei cookie di sessione inizia mappando il dominio e il percorso associati a ciascun meccanismo di autenticazione. I client Jellyfin non memorizzano tutti lo stato esattamente nello stesso modo, quindi verifica il client interessato invece di presumere che il comportamento del browser descriva ogni app.
Se il vecchio nome host funziona ancora ma quello nuovo richiede l’accesso, consideralo una migrazione dell’origine prevista finché non viene dimostrato il contrario. Se lo stesso nome host disconnette tutti solo dopo le modifiche al proxy, mantieni invariato il nome host e passa a verificare l’identità upstream, le intestazioni e l’autenticazione lato proxy.
Verifica che il DNS conduca ancora alla stessa istanza Jellyfin prevista
Risolvi il nome host da un client LAN e, se l’accesso remoto è importante, anche da un resolver esterno. Conferma che l’indirizzo restituito raggiunga il reverse proxy previsto e che il proxy instradi verso il servizio Jellyfin corretto, non verso un vecchio container, un’istanza di test, un clone ripristinato o un secondo server con un database persistente diverso.
Un cambio DNS può sembrare un problema di sessione quando in realtà invia il client a un backend diverso. Confronta una risposta che identifichi il server, il comportamento dell’elenco utenti, lo stato delle librerie e la destinazione upstream del proxy prima di modificare l’autenticazione. Se il nuovo percorso raggiunge un’istanza Jellyfin nuova o ripristinata, le credenziali client esistenti potrebbero non rappresentare più una sessione valida su quella istanza.
Il relativo flusso di lavoro ZimaSpace per mantenere separati i cicli di vita del proxy e dello stato delle sessioni è utile in questo caso: il riavvio dell’ingresso non dovrebbe sostituire silenziosamente l’identità dell’applicazione o lo stato che convalida le sessioni esistenti.
Confronta Host inoltrato, schema, percorso e autenticazione del proxy
Acquisisci la configurazione effettiva del proxy dopo la modifica. Confronta il valore Host pubblico, lo schema inoltrato, l’indirizzo del client, il percorso di aggiornamento WebSocket, i reindirizzamenti e qualsiasi middleware di autenticazione con l’ultima configurazione funzionante. Un reindirizzamento da HTTPS a un URL HTTP o con un host alternativo imprevisto può far sembrare scomparso un accesso valido.
Se davanti a Jellyfin è presente un altro livello di autenticazione, mantieni invariati la chiave di firma, il nome del cookie, il dominio del cookie e l’archivio delle sessioni durante la sostituzione del proxy. Le architetture con bilanciamento del carico usano stato di sessione persistente e di instradamento per mantenere una richiesta sul backend previsto; la modifica di questo livello può creare una disconnessione o un ciclo di reindirizzamento anche se Jellyfin continua a funzionare correttamente.
Non copiare alla cieca le intestazioni da un esempio di proxy non correlato. Modifica un solo valore quando la richiesta non riuscita o il reindirizzamento dimostrano che quello attuale è errato. La configurazione del proxy più sicura è quella minima che preserva l’origine pubblica e raggiunge sempre il backend corretto.
Usa un test client pulito senza cancellare le prove originali
Prima di cancellare qualsiasi elemento, salva l’ora del problema, la versione del browser o dell’app, lo stato della richiesta, la catena dei reindirizzamenti, la riga del registro del proxy e la voce del registro di Jellyfin. Poi usa una finestra di navigazione privata o un secondo dispositivo di test per accedere tramite il nuovo percorso. Un nuovo accesso riuscito dimostra la raggiungibilità, ma non spiega perché lo stato precedente sia diventato inutilizzabile.
Confronta i tre percorsi nel seguente ordine: indirizzo diretto di Jellyfin sulla LAN, nome host normale dalla LAN e nome host normale dall’esterno della LAN. Se l’accesso diretto funziona mentre quello tramite nome host non funziona, lascia invariati utenti e database e verifica DNS, TLS, proxy o middleware. Se tutti i percorsi rifiutano lo stesso account sicuramente valido, il problema è tornato all’interno di Jellyfin o del suo stato persistente.
Cancella lo stato specifico del sito solo sul client interessato dopo aver acquisito le prove del percorso della richiesta. Evita di eliminare subito tutti i dispositivi registrati o revocare tutte le sessioni, perché perderesti il confronto necessario a distinguere una migrazione del percorso da un errore di autenticazione lato server.
Convalida la modifica attraverso la scadenza DNS, il riavvio del proxy e il riavvio del sistema
Dopo aver applicato la correzione appropriata, attendi la scadenza della finestra TTL DNS precedente, riavvia solo il proxy, quindi riavvia il servizio Jellyfin e infine il sistema host. Ripeti i test di accesso, disconnessione, avvio della riproduzione, ricerca nella riproduzione e riconnessione tramite lo stesso nome host dopo ogni evento.
Un risultato stabile significa che il nome host continua a risolversi verso il proxy previsto, il proxy si riconnette all’istanza Jellyfin prevista, le sessioni esistenti sopravvivono ai normali riavvii dei componenti quando dovrebbero e un nuovo accesso rimane valido. Se i problemi compaiono solo durante l’avvio dell’intero stack, usa il percorso di ripristino dal proxy all’upstream per distinguere la disponibilità del servizio dall’autenticazione.
Annota nelle note della distribuzione il nome host finale, il nome upstream del proxy, il percorso di base, l’origine del certificato e qualsiasi segreto di sessione lato proxy. In questo modo le future modifiche DNS o al proxy potranno essere verificate rispetto a un contratto di identità noto, invece di essere ricostruite dai sintomi del browser.
Domande frequenti
La modifica di un record DNS invalida da sola le sessioni Jellyfin?
Di solito no, se continuano a essere utilizzati lo stesso nome host, schema, percorso e istanza Jellyfin. Una modifica DNS diventa rilevante per la sessione quando indirizza i client a un backend diverso, cambia l’origine pubblica, modifica TLS o i reindirizzamenti oppure cambia un livello di autenticazione davanti a Jellyfin.
Devo revocare tutte le sessioni Jellyfin dopo aver modificato un proxy?
Non come prima soluzione. Conserva un client che presenta il problema come prova, verifica che il nuovo percorso raggiunga il server previsto e testa separatamente un nuovo accesso. Revoca le sessioni solo se hai ruotato intenzionalmente le credenziali, sospetti un’esposizione dei token o hai confermato che lo stato precedente del client non deve più essere considerato affidabile.
Prodotti consigliati
Supporto e consigli
Altro da leggere
Jellyfin dovrebbe usare un unico account condiviso o account separati per i membri della famiglia?
Scegli gli account domestici di Jellyfin in base ai confini di identità, accesso, controllo parentale e recupero di cui hai bisogno.
Perché l’utilizzo della memoria di Jellyfin rimane elevato al termine delle attività?
Distingui la crescita del processo Jellyfin dalla cache di Linux e indaga solo quando la memoria continua ad aumentare o crea una pressione effettiva.
Segnali che la struttura di archiviazione di Jellyfin sta diventando un rischio per il ripristino
Verifica i ruoli di archiviazione di Jellyfin, separa lo stato operativo dai backup e dai dati ricostruibili, quindi dimostra la validità della struttura con...
