Pourquoi Home Assistant perd-il les sessions après une modification du proxy ou du DNS ?
La perte de session après une modification du proxy ou du DNS provient généralement d’une incohérence entre l’origine de l’URL utilisée par le client et la route que Home Assistant voit désormais, et non de comptes utilisateurs endommagés.
Un navigateur peut encore conserver les cookies et l’état de l’interface correspondant à l’ancien nom d’hôte, tandis qu’un téléphone résout la nouvelle adresse, ou le proxy peut servir la page de connexion tout en échouant à établir le WebSocket authentifié. Commencez par une fenêtre de navigation privée et un test direct sur le réseau local, notez le schéma et le nom d’hôte exacts pour chaque résultat, et évitez de supprimer toutes les sessions avant d’avoir identifié la couche défaillante.
Distinguer l’état d’un seul client d’un problème de chemin partagé
Ouvrez Home Assistant dans une fenêtre privée en utilisant l’URL finale prévue, puis comparez-la au navigateur et à l’application mobile concernés. Notez si la connexion aboutit, si le tableau de bord reste connecté pendant cinq minutes et si une actualisation de la page conserve la session. Cette comparaison réversible teste un éventuel état obsolète du client sans modifier le serveur.
Un proxy peut renvoyer la page de connexion alors que l’interface authentifiée signale ensuite une impossibilité de se connecter. Cet échec de connexion après une connexion réussie montre pourquoi l’affichage du code HTML ne prouve pas que l’ensemble du chemin de session fonctionne.
Si seul l’ancien navigateur échoue et que la fenêtre privée reste stable, supprimez les données de site des anciennes et nouvelles origines Home Assistant sur ce client, puis reconnectez-vous. Si tous les clients échouent avec l’URL du proxy mais que l’accès direct au réseau local fonctionne, conservez l’état des clients et concentrez-vous sur le chemin du proxy.
Vérifier le WebSocket et la gestion de l’origine transmise
Examinez la vue réseau du navigateur ou le journal du proxy pendant la connexion et surveillez la mise à niveau WebSocket, le statut, le délai avant déconnexion, le schéma transmis, l’hôte transmis et l’adresse du client. La distinction utile est celle entre une page HTTP qui se charge et un canal authentifié persistant qui est mis à niveau et reste ouvert.
Le dépannage des reverse proxies Home Assistant identifie régulièrement la transmission WebSocket comme une exigence distincte du proxy HTTP ordinaire. Utilisez ce mécanisme uniquement pour interpréter le chemin de mise à niveau, et non comme preuve qu’une configuration Nginx convient à tous les proxies.
Si la mise à niveau échoue, corrigez uniquement la route du proxy, les en-têtes de mise à niveau, le schéma transmis ou la limite du proxy de confiance que les journaux montrent comme incorrects. Si elle réussit et que la connexion reste établie, ne modifiez pas le proxy et examinez plutôt le DNS ainsi que l’état de l’origine côté client.
Comparer les réponses DNS et les URL finales
Résolvez le nom d’hôte Home Assistant depuis le client défaillant, un client fonctionnel et l’hôte du proxy. Comparez les réponses IPv4, IPv6 et DNS fractionné, le nom du certificat, la destination de la redirection et l’URL enregistrée dans l’application compagnon. Une modification DNS n’est terminée que lorsque les clients atteignent le point de terminaison prévu sous le même nom d’hôte canonique.
La relation plus générale entre découverte, résolution de noms et routage est présentée dans le modèle d’accessibilité de Home Assistant. Utilisez-le pour distinguer une réponse DNS obsolète d’un problème de couche de session.
Si les clients résolvent des points de terminaison différents, attendez le TTL documenté ou videz le cache du résolveur uniquement sur le client concerné et le résolveur local. Ne créez pas de noms d’hôte temporaires concurrents, car chaque origine supplémentaire crée une nouvelle limite de cookies et de redirections.
Retester le chemin de session d’origine et escalader de manière ciblée
Connectez-vous via l’URL publique ou privée finale, laissez un tableau de bord actif ouvert, rechargez une vue imbriquée, changez de réseau une fois si l’accès distant fait partie de la conception, puis recommencez après le redémarrage d’un client. La réussite exige la même URL canonique, un WebSocket stable et une session conservée après le déclencheur initial.
Si le client propre fonctionne mais qu’un seul client existant échoue encore, réparez uniquement le profil de ce client ou sa connexion à l’application. Si tous les clients utilisant le proxy échouent avec les mêmes indices de mise à niveau ou de redirection, annulez la dernière modification du proxy ou du DNS et conservez les journaux avant d’essayer autre chose.
Lors de l’escalade, fournissez la catégorie exacte de l’URL défaillante, les réponses DNS, les codes d’état du proxy, le résultat WebSocket, les horodatages et la comparaison entre clients. Arrêtez-vous lorsque deux clients différents conservent leur session après actualisation et reconnexion ; toute modification supplémentaire des cookies ou du proxy ajouterait alors des risques sans valeur diagnostique.
Produits recommandés
Assistance et conseils
Plus à lire
Comment optimiser les connexions à la base de données d’Immich pour des conteneurs simultanés
N’augmentez pas d’abord max_connections. Mesurez les sessions Immich, totalisez la demande de chaque conteneur, préservez une marge pour l’administration et n’optimisez que le goulot...
Comment empêcher les tâches ou importations en double dans Immich
Séparez les tâches répétées des ressources en double. Utilisez un chemin d’ingestion canonique, contrôlez les nouvelles tentatives et les changements de chemin, puis testez...
Comment réparer Immich après le remplissage de son volume de base de données
Ne supprimez jamais les journaux WAL de PostgreSQL pour libérer de l’espace. Arrêtez les écritures d’Immich, préservez l’état de la base de données, ajoutez...
