Perché Plex perde le sessioni dopo una modifica al proxy o al DNS?

Eva Wong

IceWhale author

Eva Wong è la Technical Writer e smanettatrice residente di ZimaSpace. Una geek da sempre con una passione per homelab e software open-source, si specializza nel tradurre concetti tecnici complessi in guide accessibili e pratiche. Eva crede che l'auto-ospitare debba essere divertente, non intimidatorio. Attraverso i suoi tutorial, dà potere alla comunità di demistificare le configurazioni hardware, dalla costruzione del loro primo NAS al dominio dei container Docker.

Why Does Plex Lose Sessions After a Proxy or DNS Change? - Zima Store Online

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.

-15% OFF

ZimaBoard 2 - Mini server domestico per la tua grande idea

Single board computer zimaboard2

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.