Pourquoi Jellyfin perd-il les sessions après une modification du proxy ou du DNS ?

Un changement de proxy ou de DNS ne devrait pas automatiquement détruire toutes les connexions Jellyfin. La perte de session survient généralement lorsque le changement modifie également le nom d’hôte, le schéma, le chemin, l’identité du serveur en amont, la couche d’authentification ou la route client attendue par l’état de connexion existant.

Commencez par distinguer une simple mise à jour d’un enregistrement DNS d’un changement d’origine. Conservez un compte et un appareil connus, comparez l’accès direct au réseau local avec le nom d’hôte public habituel et capturez la première requête échouée avant d’effacer les données client. L’objectif est d’identifier la frontière qui a changé, et non de réinitialiser les utilisateurs jusqu’à disparition du symptôme.

Déterminez d’abord si l’origine publique a réellement changé

Notez l’ancien et le nouveau schéma, nom d’hôte, port, chemin de base et route du proxy. Un enregistrement DNS A ou AAAA peut diriger le même nom d’hôte vers une adresse différente sans modifier l’origine du navigateur, tandis que le passage d’un nom d’hôte à un autre ou la modification du chemin de base de l’application crée une frontière client différente. Les migrations vers un domaine personnalisé exigent également que l’application et le chemin d’authentification utilisent le nouveau domaine de manière cohérente ; cette liste de contrôle pour la migration vers un domaine personnalisé explicite ce couplage entre DNS et application.

L’état d’authentification dépend de l’endroit où il est présenté. Une utile liste de contrôle de la portée des cookies de session commence par cartographier le domaine et le chemin associés à chaque mécanisme d’authentification. Les clients Jellyfin ne stockent pas tous l’état exactement de la même manière ; testez donc le client concerné au lieu de supposer que le comportement du navigateur décrit celui de toutes les applications.

Si l’ancien nom d’hôte fonctionne toujours mais que le nouveau demande une connexion, considérez cela comme une migration d’origine attendue jusqu’à preuve du contraire. Si le même nom d’hôte déconnecte tout le monde uniquement après la modification du proxy, conservez le nom d’hôte et examinez l’identité du serveur en amont, les en-têtes et l’authentification côté proxy.

Vérifiez que le DNS aboutit toujours à la même instance Jellyfin prévue

Résolvez le nom d’hôte depuis un client du réseau local et, si l’accès distant est important, depuis un résolveur externe. Vérifiez que l’adresse renvoyée atteint le reverse proxy prévu et que celui-ci dirige les requêtes vers le service Jellyfin attendu, et non vers un ancien conteneur, une instance de test, un clone restauré ou un second serveur utilisant une base de données persistante différente.

Une bascule DNS peut ressembler à un problème de session alors qu’elle dirige en réalité le client vers un autre backend. Comparez une réponse identifiant le serveur, le comportement de la liste des utilisateurs, l’état des bibliothèques et la cible amont du proxy avant de modifier l’authentification. Si la nouvelle route atteint une instance Jellyfin neuve ou restaurée, les identifiants client existants peuvent ne plus y correspondre à une session valide.

Le processus ZimaSpace associé au fait de séparer les cycles de vie du proxy et de l’état des sessions est utile ici : un redémarrage de la couche d’entrée ne devrait pas remplacer silencieusement l’identité de l’application ni l’état qui valide les sessions existantes.

Comparez l’hôte transmis, le schéma, le chemin et l’authentification du proxy

Capturez la configuration effective du proxy après la modification. Comparez la valeur Host publique, le schéma transmis, l’adresse du client, le chemin de mise à niveau WebSocket, les redirections et tout middleware d’authentification avec la dernière configuration fonctionnelle. Une redirection de HTTPS vers une URL HTTP ou un autre hôte inattendu peut donner l’impression qu’une connexion valide a disparu.

Si une autre couche d’authentification se trouve devant Jellyfin, conservez sa clé de signature, le nom de son cookie, le domaine du cookie et son magasin de sessions lors du remplacement du proxy. Les architectures avec répartiteur de charge utilisent un état de session persistante et de routage pour maintenir une requête sur le backend prévu ; modifier cette couche peut provoquer une déconnexion ou une boucle, même si Jellyfin reste sain.

Ne copiez pas aveuglément les en-têtes d’un exemple de proxy sans rapport. Ne modifiez une valeur que lorsque la requête échouée ou la redirection montre que la valeur actuelle est incorrecte. La configuration de proxy la plus sûre est la plus minimale possible, tout en préservant l’origine publique et en atteignant systématiquement le backend correct.

-15% OFF

ZimaBoard 2 - Mini serveur domestique pour votre grande idée

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Effectuez un test avec un client vierge sans effacer les éléments de preuve d’origine

Avant d’effacer quoi que ce soit, enregistrez l’heure de l’échec, la version du navigateur ou de l’application, le statut de la requête, la chaîne de redirections, la ligne du journal du proxy et l’entrée correspondante du journal Jellyfin. Utilisez ensuite une fenêtre de navigation privée ou un second appareil de test pour vous connecter via la nouvelle route. Une nouvelle connexion réussie prouve l’accessibilité ; elle n’explique pas pourquoi l’ancien état est devenu inutilisable.

Comparez les trois chemins dans cet ordre : l’adresse Jellyfin directe du réseau local, le nom d’hôte habituel depuis le réseau local, puis le nom d’hôte habituel depuis l’extérieur du réseau local. Si l’accès direct fonctionne tandis que le nom d’hôte échoue, ne modifiez ni les utilisateurs ni l’état de la base de données et examinez le DNS, TLS, le proxy ou le middleware. Si tous les chemins refusent le même compte connu comme valide, le problème se situe de nouveau dans Jellyfin ou dans son état persistant.

Effacez les données propres au site sur le client concerné uniquement après avoir capturé les éléments de preuve liés au chemin de requête. Évitez de supprimer tous les appareils enregistrés ou de révoquer toutes les sessions en première intention, car cela éliminerait la comparaison permettant de distinguer une migration de routage d’un échec d’authentification côté serveur.

Validez la modification après expiration du DNS, redémarrage du proxy et redémarrage du serveur

Après avoir appliqué la correction appropriée, laissez expirer la période du TTL DNS précédent, redémarrez uniquement le proxy, puis redémarrez le service Jellyfin et enfin le serveur hôte. Répétez les tests de connexion, de déconnexion, de démarrage de lecture, de déplacement dans la vidéo et de reconnexion via le même nom d’hôte après chaque étape.

Un résultat stable signifie que le nom d’hôte continue de se résoudre vers le proxy prévu, que le proxy se reconnecte à l’instance Jellyfin prévue, que les sessions existantes survivent aux redémarrages normaux des composants lorsque cela est attendu et qu’une nouvelle connexion reste valide. Si les échecs apparaissent uniquement lors du démarrage de toute la pile, utilisez le chemin de reprise entre le proxy et le service en amont pour distinguer la disponibilité de l’authentification.

Consignez dans les notes de déploiement le nom d’hôte final, le nom du service amont du proxy, le chemin de base, la source du certificat et tout secret de session côté proxy. Les prochaines modifications DNS ou de proxy pourront ainsi être testées par rapport à un contrat d’identité connu, au lieu d’être rediagnostiquées à partir des symptômes du navigateur.

FAQ

La modification d’un enregistrement DNS suffit-elle à invalider les sessions Jellyfin ?

Généralement non, si le même nom d’hôte, le même schéma, le même chemin et la même instance Jellyfin restent utilisés. Une modification DNS devient pertinente pour les sessions lorsqu’elle dirige les clients vers un autre backend, modifie l’origine publique, change TLS ou les redirections, ou modifie une couche d’authentification placée devant Jellyfin.

Dois-je révoquer toutes les sessions Jellyfin après avoir modifié un proxy ?

Pas comme première mesure corrective. Conservez un client en échec comme élément de preuve, vérifiez que la nouvelle route atteint le serveur prévu et testez séparément une nouvelle connexion. Révoquez les sessions uniquement si vous avez volontairement renouvelé les identifiants, si vous soupçonnez une compromission de jeton ou si vous avez confirmé que l’ancien état client ne doit plus être approuvé.