Plex può perdere le sessioni dopo una modifica al proxy o al DNS, quando i client si riconnettono tramite un hostname, un percorso, un certificato o un endpoint memorizzato nella cache diversi.
Durante il test del percorso di connessione, mantieni invariati il server e i contenuti multimediali. Le sessioni esistenti possono durare più a lungo di quelle nuove perché i client memorizzano indirizzi e stato di autenticazione in modo diverso. Riproduci una sessione locale e una tramite proxy, quindi confronta la risoluzione DNS, i reindirizzamenti, il comportamento dei websocket e l'indirizzo utilizzato effettivamente dal client.
Conferma che l'accesso diretto a Plex funzioni ancora
Un problema del proxy è molto più semplice da isolare quando il backend è stato verificato come funzionante. Testa lo stesso account e lo stesso contenuto direttamente sulla LAN prima di modificare i certificati o lo stato del database.
Il backend può essere testato separatamente dall'hostname pubblico quando un percorso proxy inverso di Plex mantiene distinti questi due percorsi.
Apri Plex direttamente, riproduci un contenuto noto e annota l'indirizzo del server. Se anche l'accesso diretto non funziona, lascia invariati il DNS e le regole del proxy finché il backend non sarà operativo.
Controlla il DNS prima dell'autenticazione
Un nuovo hostname o indirizzo può indirizzare i client all'endpoint sbagliato, anche se l'errore di accesso sembra un problema dell'account. Confronta ciò che risolve ciascun client, soprattutto quando sono coinvolte cache o configurazioni DNS separate.
Le metriche delle route dell'interfaccia possono inoltre cambiare il percorso di rete utilizzato dopo un aggiornamento DNS, quindi verifica sia la risoluzione sia la selezione della route.
Risolvi i nomi pubblico e locale dai client interessati e da quelli funzionanti. Svuota la cache solo del client che presenta il problema, dopo aver registrato il risultato errato.
Verifica le riscritture del proxy e i percorsi websocket
Le riscritture dei sottopercorsi, le intestazioni, i reindirizzamenti e gli aggiornamenti websocket possono interrompere le sessioni dopo una modifica al proxy, mentre una semplice pagina web continua a caricarsi. È necessario testare l'intero flusso del client.
Una modifica al proxy può influire sugli asset relativi alla root e sul comportamento dell'integrità quando è coinvolta la riscrittura del percorso proxy di Plex, quindi non si tratta soltanto di un semplice inoltro di porta.
Controlla gli errori di rete del browser e i log del proxy durante l'accesso e la riproduzione. Se il percorso tramite proxy non funziona mentre l'accesso diretto sì, correggi il livello del proxy prima di reimpostare gli utenti. Dopo aver stabilizzato il proxy, verifica lo stesso percorso di streaming remoto di Plex da una rete esterna e conserva questo risultato come riferimento per le future modifiche al DNS o al perimetro di rete.
Ripeti il test con un unico percorso di sessione noto
Dopo aver stabilizzato il comportamento del DNS e del proxy, crea una nuova sessione e verifica che il client rimanga sull'hostname previsto. In questo modo eviti che un vecchio percorso memorizzato nella cache faccia sembrare funzionante una configurazione difettosa.
Una connessione a un servizio altrimenti valida può non funzionare quando il traffico di risposta esce tramite il percorso VPN invece che dall'interfaccia che ha ricevuto la richiesta.
Testa da una rete esterna e da una rete locale utilizzando lo stesso account. Se solo uno dei due percorsi interrompe le sessioni, continua a esaminare il routing e le policy del perimetro di rete anziché lo stato del server.
Supporto e consigli
Altro da leggere

È meglio eseguire il backup di Jellyfin mentre è in funzione o arrestare prima il servizio?
Per semplicità, preferisci i backup con il servizio arrestato; usa gli snapshot a caldo solo quando lo stato dell’applicazione viene acquisito in modo coerente...

Perché Jellyfin funziona a temperature elevate o è rumoroso quando nessuno sta guardando contenuti in streaming?
Il calore in stato di inattività di solito indica attività in background o un carico di lavoro su un host condiviso, quindi identifica il...

Quando dovresti ricostruire Jellyfin invece di ripararlo?
Scegli la ricostruzione invece della riparazione quando il problema è la deriva dell’ambiente di esecuzione e lo stato persistente è stato sottoposto a backup;...

