Comment vérifier si le DNS provoque des échecs de connexion à Plex
Vérifiez d’abord la connectivité IP directe : n’examinez le DNS que lorsque Plex fonctionne par adresse, mais échoue via le nom d’hôte habituel, la découverte de l’application ou le chemin de connexion sécurisée.
Le DNS peut perturber Plex à cause d’un résolveur fourni par le routeur, d’un filtrage Pi-hole ou Unbound, de réponses obsolètes mises en cache par le client, de règles de DNS fractionné ou de la protection contre le rebinding autour de `plex.direct`. Ces problèmes peuvent donner l’impression que le serveur est hors service alors que le service reste accessible par IP. Utilisez un seul client en échec, une adresse de serveur connue et un résolveur alternatif afin d’isoler la résolution de noms avant de modifier les redirections de ports, les bibliothèques ou les paramètres des conteneurs.
Vérifiez la connectivité IP avant de tester le DNS
Utilisez l’adresse privée connue du serveur Plex sur le réseau local et vérifiez que l’hôte est accessible et que le port Plex répond. Si le chemin IP échoue, le DNS n’est pas la première cause. Corrigez le routage, le pare-feu, l’adressage de l’hôte ou la disponibilité du service avant de modifier les paramètres du résolveur.
Un diagnostic DNS ne devient crédible qu’après vérification de l’accès direct par IP. Si le même client atteint Plex par adresse, mais pas par son nom habituel ou son chemin sécurisé, le comportement du résolveur devient une piste clairement testable.
Notez l’adresse IP fonctionnelle ainsi que le nom d’hôte en échec ou le comportement problématique de l’application. Si les deux échouent, arrêtez le test DNS. Si l’IP fonctionne et que le chemin Plex habituel échoue, vous disposez maintenant d’une piste claire à examiner du côté du résolveur, du nom sécurisé ou de la protection contre le rebinding.
Comparez les réponses du résolveur et le comportement du rebinding
Interrogez le nom d’hôte en échec via le résolveur réellement utilisé par le client et comparez la réponse avec celle d’un client connu comme fonctionnel ou d’un résolveur de confiance temporaire. Si les réponses diffèrent, examinez le DNS fourni par DHCP, les réécritures locales et le filtrage avant de modifier Plex ou le NAT.
`plex.direct` peut renvoyer vers une adresse de serveur privée. La protection contre le rebinding DNS peut donc bloquer la réponse même si l’hôte Plex fonctionne correctement. Consultez les journaux du résolveur pour repérer les requêtes liées à Plex bloquées ou réécrites, au lieu de désactiver globalement la protection contre le rebinding.
Contournez temporairement un résolveur pour un seul client, répétez la même requête Plex et ne conservez que la modification la plus ciblée qui rétablit le chemin en échec. Si le résolveur alternatif ne change rien, annulez le test et passez aux certificats, à la découverte de l’application, au pare-feu ou au routage distant.
Si les deux résolveurs renvoient la même réponse et que le contrôle par IP directe fonctionne toujours, le DNS est moins susceptible d’être la cause active. Conservez ce résultat et examinez plutôt la validation des certificats, la découverte de l’application, la politique du pare-feu ou le chemin distant, au lieu d’ajouter d’autres exceptions au résolveur.
Distinguez une panne de DNS local d’une panne d’accès distant
Un problème de DNS sur le réseau local peut amener les clients locaux à considérer le serveur comme indirect ou indisponible, alors que l’accès distant externe fonctionne encore. L’inverse peut également se produire : les noms locaux se résolvent correctement, mais le port public ou le chemin CGNAT est défaillant. Tester les deux directions évite qu’un symptôme en masque un autre.
Une exception de domaine privé peut rétablir le comportement du résolveur local, mais elle ne crée pas de chemin entrant depuis Internet ; une panne limitée à l’accès distant relève toujours du NAT, du pare-feu ou de la topologie du FAI.
Testez un client du réseau local avec le DNS habituel, ce même client avec un résolveur alternatif temporaire et un client distant utilisant les données cellulaires. Notez quelles cases de la matrice fonctionnent. Ce schéma indique généralement si le problème DNS est local, distant ou sans rapport.
Ne conservez la correction que si elle résiste aux changements de cache et aux redémarrages
Les corrections DNS peuvent sembler fonctionner parce que le cache d’un client contient encore une ancienne réponse ou parce qu’un contournement temporaire du résolveur est toujours actif. Videz ou expirez le cache concerné, renouvelez les paramètres réseau du client et redémarrez une fois le résolveur ou le routeur avant de déclarer le problème résolu.
Le rebinding DNS et les paramètres NAT peuvent se chevaucher. Documentez donc quelle modification unique résout le test en échec au lieu de conserver plusieurs exceptions inutiles.
Si le DNS ne fait que révéler un changement plus large du routeur ou du sous-réseau, le chemin d’accès distant après changement de routeur devient la prochaine piste, une fois les paramètres ordinaires du client rétablis.
Produits recommandés
Assistance et conseils
Plus à lire
Plex peut-il partager un GPU avec un autre conteneur Docker ?
Plex et un autre conteneur peuvent souvent accéder au même GPU, mais vous devez tester la prise en charge des pilotes, le mappage des...
Comment déterminer si une erreur Plex vient du client ou du serveur
Reproduisez le même élément sur un autre client, comparez le chemin de session, puis recueillez les preuves côté serveur uniquement après que la portée...
Comment configurer le cache de Plex et le stockage temporaire du transcodage
Protégez l’état persistant de Plex en plaçant les fichiers temporaires de transcodage sur un stockage local adapté, puis vérifiez le nettoyage, l’espace libre et...
