Plex peut perdre des sessions après une modification du proxy ou du DNS lorsque les clients se reconnectent via un nom d’hôte, une route, un certificat ou un point de terminaison mis en cache différent.
Ne modifiez pas le serveur ni les médias pendant le test du chemin de connexion. Les sessions existantes peuvent durer plus longtemps que les nouvelles, car les clients mettent en cache les adresses et l’état d’authentification de manière différente. Reproduisez une session locale et une session via proxy, puis comparez la résolution DNS, les redirections, le comportement des websockets et l’adresse réellement utilisée par le client.
Confirmer que l’accès direct à Plex fonctionne toujours
Un problème de proxy est beaucoup plus facile à isoler lorsque le bon fonctionnement du serveur principal est confirmé. Testez le même compte et le même média directement sur le réseau local avant de modifier les certificats ou l’état de la base de données.
Le serveur principal peut être testé séparément du nom d’hôte public lorsqu’une route de proxy inverse Plex maintient ces deux chemins distincts.
Ouvrez Plex directement, lisez un élément connu et notez l’adresse du serveur. Si l’accès direct échoue également, ne modifiez ni le DNS ni les règles du proxy jusqu’à ce que le serveur principal fonctionne.
Vérifier le DNS avant l’authentification
Un nouveau nom d’hôte ou une nouvelle adresse peut diriger les clients vers le mauvais point de terminaison, même si l’erreur de connexion ressemble à un problème de compte. Comparez ce que chaque client résout, en particulier lorsque des caches ou un DNS fractionné sont utilisés.
Les métriques de route de l’interface peuvent également modifier le chemin réseau utilisé après une mise à jour DNS. Vérifiez donc à la fois la résolution et la sélection de la route.
Résolvez les noms publics et locaux depuis les clients concernés et ceux qui fonctionnent. Ne videz le cache que du client défaillant après avoir enregistré le mauvais résultat.
Vérifier les réécritures du proxy et les chemins websocket
Les réécritures de sous-chemins, les en-têtes, les redirections et les mises à niveau websocket peuvent interrompre les sessions après une modification du proxy, alors qu’une simple page web continue de se charger. L’ensemble du flux client doit être testé.
Une modification du proxy peut affecter les ressources relatives à la racine et le comportement d’intégrité lorsque la réécriture du chemin du proxy Plex est utilisée. Il ne s’agit donc pas simplement d’une redirection de port.
Surveillez les erreurs réseau du navigateur et les journaux du proxy pendant la connexion et la lecture. Si le chemin via proxy échoue alors que l’accès direct fonctionne, corrigez la couche proxy avant de réinitialiser les utilisateurs. Une fois le proxy stable, vérifiez le même chemin de diffusion Plex à distance depuis un réseau externe et conservez ce résultat comme référence pour les futures modifications du DNS ou de l’infrastructure en périphérie.
Retester avec un chemin de session connu
Une fois le comportement du DNS et du proxy stabilisé, créez une nouvelle session et confirmez que le client reste sur le nom d’hôte prévu. Cela évite qu’une ancienne route mise en cache fasse paraître saine une configuration défaillante.
Une connexion valide au service peut échouer lorsque le trafic de réponse repart via la route du VPN au lieu de l’interface qui a reçu la requête.
Testez depuis un réseau externe et un réseau local avec le même compte. Si une seule voie interrompt les sessions, poursuivez l’analyse du routage et des règles en périphérie plutôt que de modifier l’état du serveur.
Assistance et conseils
Plus à lire

Faut-il sauvegarder Jellyfin à chaud ou arrêter le service au préalable ?
Privilégiez les sauvegardes lorsque le service est arrêté pour plus de simplicité ; n’utilisez des instantanés à chaud que lorsque l’état de l’application est...

Pourquoi Jellyfin chauffe-t-il ou est-il bruyant lorsque personne ne regarde de contenu en streaming ?
La chaleur au repos indique généralement une activité en arrière-plan ou une charge de travail d’hébergement partagé. Identifiez donc le processus actif et la...

Quand faut-il reconstruire Jellyfin plutôt que le réparer ?
Choisissez la reconstruction plutôt que la réparation lorsque la dérive de l’environnement d’exécution est à l’origine du problème et que l’état persistant est sauvegardé...

