Come verificare se il DNS sta causando problemi di connessione a Plex
Verifica prima la connettività IP diretta; indaga sul DNS solo quando Plex funziona tramite indirizzo ma non tramite il normale hostname, il rilevamento dell’app o il percorso di connessione sicura.
Il DNS può interrompere il funzionamento di Plex a causa di un resolver fornito dal router, di filtri applicati da Pi-hole o Unbound, di risposte obsolete nella cache del client, di regole split-DNS o della protezione dal DNS rebinding attorno a `plex.direct`. Questi problemi possono sembrare un’interruzione del server, anche se il servizio è raggiungibile tramite IP. Usa un client che presenta il problema, un indirizzo del server noto e un resolver alternativo per isolare la risoluzione dei nomi prima di modificare il port forwarding, le librerie o le impostazioni dei container.
Verifica la connettività IP prima di testare il DNS
Usa l’indirizzo privato noto del server Plex sulla LAN e verifica che l’host sia raggiungibile e che la porta di Plex risponda. Se il percorso IP non funziona, il DNS non è la causa iniziale. Risolvi prima i problemi di routing, firewall, indirizzamento dell’host o disponibilità del servizio, prima di modificare le impostazioni del resolver.
Una diagnosi DNS diventa attendibile solo dopo che l’accesso diretto tramite IP funziona. Se lo stesso client raggiunge Plex tramite indirizzo ma non tramite il nome normale o il percorso sicuro, il comportamento del resolver diventa un’ipotesi da verificare.
Annota l’IP funzionante e l’hostname che non funziona oppure il comportamento anomalo dell’app. Se entrambi non funzionano, interrompi il test DNS. Se l’IP funziona ma il percorso Plex normale non va, hai un caso ben definito da analizzare per verificare il resolver, il nome usato per la connessione sicura o il DNS rebinding.
Confronta le risposte del resolver e il comportamento del DNS rebinding
Interroga l’hostname che presenta il problema tramite il resolver effettivamente utilizzato dal client e confronta la risposta con quella di un client noto per funzionare o con un resolver affidabile temporaneo. Se le risposte differiscono, controlla il DNS assegnato tramite DHCP, le riscritture locali e i filtri prima di modificare Plex o il NAT.
`plex.direct` può risolversi nell’indirizzo privato del server, quindi la protezione dal DNS rebinding potrebbe bloccare la risposta anche se l’host Plex è integro. Controlla i log del resolver per individuare query relative a Plex bloccate o riscritte, invece di disabilitare globalmente la protezione dal rebinding.
Ignora temporaneamente un resolver per un solo client, ripeti la stessa richiesta Plex e mantieni esclusivamente la modifica più circoscritta che risolve il percorso non funzionante. Se il resolver alternativo non cambia nulla, annulla il test e passa ai certificati, al rilevamento dell’app, al firewall o al routing remoto.
Se entrambi i resolver restituiscono la stessa risposta e il test di controllo tramite IP diretto continua a funzionare, è meno probabile che il DNS sia la causa attiva del problema. Conserva questo risultato e passa alla convalida del certificato, al rilevamento dell’app, alle regole del firewall o al percorso remoto, invece di aggiungere altre eccezioni al resolver.
Separa un problema DNS locale da un problema di accesso remoto
Un problema DNS sulla LAN può far considerare il server indiretto o non disponibile ai client locali, mentre l’accesso remoto esterno continua a funzionare. Può verificarsi anche il contrario: i nomi locali si risolvono correttamente, ma la porta pubblica o il percorso CGNAT non funzionano. Testare entrambe le direzioni impedisce che un sintomo nasconda l’altro.
Un’eccezione per il dominio privato può correggere il comportamento del resolver locale, ma non crea un percorso Internet in ingresso; un problema che si verifica solo da remoto riguarda ancora il NAT, il firewall o la topologia dell’ISP.
Testa un client LAN con il DNS normale, lo stesso client con un resolver alternativo temporaneo e un client remoto tramite rete cellulare. Annota quali combinazioni funzionano. Questo schema indica di solito se il problema DNS è locale, remoto o non correlato.
Mantieni la correzione solo se resiste alla cancellazione della cache e ai riavvii
Le correzioni DNS possono sembrare efficaci perché la cache di un client conserva una risposta precedente o perché è ancora attivo un bypass temporaneo del resolver. Svuota o fai scadere la cache pertinente, rinnova le impostazioni di rete del client e riavvia una volta il resolver o il router prima di dichiarare risolto il problema.
Le impostazioni DNS rebinding e NAT possono sovrapporsi, quindi documenta quale singola modifica risolve il test non funzionante invece di conservare diverse eccezioni non necessarie.
Se il DNS si limita a rendere visibile un problema più ampio relativo a una modifica del router o della sottorete, il percorso di accesso remoto dopo la modifica del router diventa il ramo successivo, dopo aver ripristinato le normali impostazioni del client.
Prodotti consigliati
Supporto e consigli
Altro da leggere
Plex può condividere una GPU con un altro container Docker?
Plex e un altro container possono spesso accedere alla stessa GPU, ma è necessario testare il supporto dei driver, la mappatura dei dispositivi, il...
Come capire se un errore di Plex proviene dal client o dal server
Riproduci lo stesso elemento su un altro client, confronta il percorso della sessione, quindi raccogli le prove dal server solo dopo che l’ambito ti...
Come configurare la cache di Plex e l’archiviazione temporanea per la transcodifica
Proteggi lo stato persistente di Plex collocando i file temporanei di transcodifica su un’unità locale adatta, quindi verifica la pulizia, lo spazio libero e...
