Plex fonctionne en Wi-Fi, mais échoue en Ethernet ou via VPN : comment isoler le chemin

Si Plex fonctionne sur un chemin réseau mais échoue sur un autre, gardez la configuration du serveur inchangée et testez le chemin qui varie.

Les interfaces Wi-Fi, Ethernet et VPN peuvent utiliser des adresses IP, des serveurs DNS, des routes, des MTU, des VLAN et des politiques de pare-feu différents, même sur le même client. Une modification globale du serveur n’est pas la bonne première étape lorsque les mêmes contenus et le même compte fonctionnent sur un chemin. Comparez l’accessibilité directe du serveur, la résolution DNS, la sélection de route et le mode de lecture sur chaque interface.

Comparez l’adresse et la route avant les paramètres de Plex

L’interface défaillante peut accéder à un autre sous-réseau ou choisir une autre route par défaut. Vérifiez l’adresse IP et la route du serveur depuis le client au lieu de vous fier au nom du réseau.

Lorsque l’Ethernet et le Wi-Fi sont actifs simultanément, les métriques de route peuvent amener les interfaces à choisir des chemins différents vers la même destination. Commencez donc par examiner le routage et les politiques d’interface plutôt que les paramètres de Plex.

Envoyez une requête ping ou connectez-vous à l’adresse du serveur via les deux chemins, comparez l’adresse IP et le sous-réseau du client, puis examinez la route utilisée pour le port 32400. Si l’Ethernet ne peut pas atteindre directement le serveur, limitez la correction à la couche réseau.

Vérifiez séparément le DNS et le routage VPN

Un VPN peut modifier à la fois la priorité des routes et le DNS sans changer l’application Plex. Le tunneling fractionné peut également faire sortir les réponses par une interface différente de celle qui a reçu la requête.

Le tunneling fractionné peut échouer lorsque le trafic de réponse passe par la route VPN au lieu de l’interface qui a reçu la requête, ce qui interrompt un chemin Plex pourtant valide.

Désactivez le VPN uniquement le temps d’établir un résultat de contrôle, puis réactivez-le et comparez les tables de routage. Corrigez le routage asymétrique ou la politique de tunneling fractionné avant de modifier les paramètres des contenus multimédias ou de la base de données.

Testez le MTU lorsque les petites requêtes fonctionnent, mais que les flux se bloquent

Un chemin peut laisser passer le petit trafic de contrôle tandis que les paquets plus volumineux sont fragmentés ou expirent. Ce schéma est particulièrement fréquent avec les tunnels VPN et certains liens mobiles ou de FAI.

Une connectivité partielle peut être due à des échecs Plex sensibles au MTU sur un moyen de transport, tandis qu’un autre chemin fonctionne. La taille des paquets constitue donc un test ciblé pour les blocages propres au VPN ou au FAI.

Utilisez un test de MTU du chemin ou réduisez temporairement le MTU du tunnel de manière contrôlée. Si la lecture devient stable sans aucune modification de Plex, poursuivez le diagnostic au niveau du transport.

Featured

ZimaCube 2 NAS personnel Cloud à domicile

ZimaCube2

$799.00 - $2,499.00

Buy Now

Retestez Plex uniquement après avoir stabilisé la connectivité de base

Une fois l’accessibilité directe, la route, le DNS et le MTU cohérents, testez le même élément Plex et la même qualité sur chaque chemin. Vous éviterez ainsi de confondre une correction réseau avec un changement de transcodage côté client.

Avant de revenir aux paramètres de Plex, confirmez l’absence de d’erreurs réseau et de saturation sur le chemin corrigé, puis reproduisez le même élément et la même qualité en maintenant la variable réseau stable.

Si le chemin réseau est stable, mais qu’un seul client échoue encore, poursuivez avec la compatibilité du client ou l’état mis en cache. Conservez un chemin de diffusion Plex à distance connu comme référence au lieu de rouvrir les paramètres réseau globaux du serveur.