Pourquoi la connexion à Home Assistant échoue-t-elle après le redémarrage d’un proxy inverse ?

Si la connexion à Home Assistant échoue uniquement après le redémarrage d’un proxy inverse, testez d’abord la connexion directe sur le réseau local et ne modifiez pas la base de données des utilisateurs tant que le chemin du proxy n’est pas isolé.

Un redémarrage du proxy peut modifier l’adresse de son conteneur, les informations client transférées, la gestion des WebSockets, la cible DNS ou le serveur principal en amont, sans modifier aucun mot de passe Home Assistant. La suppression des comptes et la réinitialisation globale des sessions sont donc de mauvaises premières mesures. Comparez l’URL directe de Home Assistant avec le nom d’hôte habituel du proxy, enregistrez les erreurs du navigateur et du proxy, puis déterminez si l’échec survient avant l’authentification, pendant la requête de connexion ou lorsque l’interface ouvre sa connexion persistante.

Commencez par séparer l’authentification Home Assistant du chemin du proxy

Utilisez le même compte connu comme fonctionnel via l’adresse locale directe de Home Assistant, puis via le nom d’hôte public ou interne du proxy. Si la connexion directe fonctionne alors que le chemin du proxy échoue, le compte et l’état de l’authentification de Core sont probablement suffisamment sains pour ne pas être modifiés. Si les deux chemins échouent, reprenez l’investigation du côté de Home Assistant, de l’état restauré ou des identifiants.

Un cas de connexion via proxy inverse a montré un comportement direct différent de celui du chemin Apache jusqu’à la correction des détails relatifs aux WebSockets et au proxy. Ce type de comparaison entre accès direct et proxy est plus instructif que de modifier les mots de passe à répétition.

Avant de modifier la configuration, notez le code HTTP, la chaîne de redirections, l’erreur de la console du navigateur, la réponse du serveur en amont du proxy et l’horodatage correspondant dans les journaux Home Assistant. Une erreur 400 due à un proxy non approuvé, un échec de WebSocket, une redirection vers le mauvais protocole et un mot de passe invalide sont des problèmes différents, même si l’écran affiche la même impossibilité générique de se connecter.

Les quatre causes côté proxy laissent des signatures différentes

Les cas courants sont une adresse source du proxy modifiée qui ne correspond plus à la règle des proxys approuvés, des changements dans les en-têtes transférés ou le protocole, une gestion défaillante de la mise à niveau WebSocket et un routage vers le mauvais serveur principal Home Assistant. La recréation d’un conteneur de proxy peut modifier l’un de ces éléments alors que l’instance Home Assistant elle-même reste stable.

Un cas récent de dépannage d’un proxy inverse montre que Home Assistant rejetait le trafic transféré jusqu’à ce que le proxy immédiat soit placé dans la plage approuvée correcte. Cette vérification de l’identité du proxy approuvé est plus sûre que l’élargissement permanent de la plage : vérifiez quelle adresse du proxy atteint réellement Home Assistant et n’approuvez que cette limite.

Utilisez les signatures ci-dessous et ne modifiez qu’une seule branche à la fois. Après le test, ne laissez pas une plage étendue de proxys approuvés en place : elle supprime une protection importante contre l’usurpation des adresses client transférées.

Cause 1 : le redémarrage a modifié l’adresse source du proxy

• Signature : les requêtes sont rejetées immédiatement et les journaux Home Assistant signalent un proxy inverse non approuvé.
• Vérification : comparez le sous-réseau ou l’adresse du conteneur du proxy avec la plage approuvée configurée.
• SI–ALORS : si le rétablissement de la plage approuvée correcte et limitée résout le problème de connexion, ne modifiez pas l’état du compte ni des sessions.

Cause 2 : l’hôte ou le protocole transféré ne correspond plus à l’origine publique

• Signature : les redirections alternent entre HTTP et HTTPS ou entre différents noms d’hôte, ou les cookies semblent associés à une origine inattendue.
• Vérification : comparez l’hôte et le protocole transféré avant et après le redémarrage.
• SI–ALORS : si la correction de ces valeurs résout la boucle de redirection et de connexion, l’échec concernait l’identité d’entrée et non les utilisateurs Home Assistant.

Cause 3 : la page de connexion se charge, mais la mise à niveau WebSocket échoue

• Signature : l’interface statique se charge, puis l’interface se déconnecte ou ne parvient pas à terminer son initialisation.
• Vérification : examinez la requête WebSocket du navigateur et les en-têtes de mise à niveau du proxy.
• SI–ALORS : si l’accès direct maintient la connexion WebSocket ouverte alors que le nom d’hôte n’y parvient pas, poursuivez l’analyse au niveau du proxy.

Cause 4 : le proxy pointe vers un autre serveur principal ou vers un serveur nouvellement créé

• Signature : le serveur semble nouvellement configuré, des utilisateurs connus ont disparu ou l’état propre au serveur diffère via le proxy.
• Vérification : comparez l’adresse en amont, l’identité de l’instance et le chemin de configuration.
• SI–ALORS : si le proxy atteint le mauvais conteneur ou la mauvaise instance restaurée, corrigez le routage avant de toucher aux données d’authentification.

Utilisez le comportement des WebSockets pour éviter de prendre un échec de l’interface pour un échec de connexion

L’interface de Home Assistant dépend d’une connexion WebSocket persistante après l’échange HTTP initial. Un proxy peut donc servir correctement la page de connexion, puis échouer quelques instants plus tard lorsque la connexion est mise à niveau ou maintenue ouverte. Les utilisateurs décrivent souvent cette séquence comme un échec de connexion, car elle survient immédiatement après l’envoi des identifiants.

Une configuration de proxy inverse Home Assistant sur Synology atteignait le chemin de connexion, mais échouait encore jusqu’à la correction de la gestion de la mise à niveau WebSocket. La vérification du comportement de mise à niveau WebSocket via le proxy évite de réinitialiser inutilement les utilisateurs alors que le chemin de connexion HTTP fonctionne déjà.

Si la connexion échoue, vérifiez la gestion de la mise à niveau HTTP/1.1, les délais d’expiration, la terminaison TLS, le nom d’hôte ainsi que tout intergiciel CDN ou d’authentification placé devant le proxy. Limitez les modifications au strict nécessaire. N’ajoutez pas d’en-têtes sans rapport copiés d’une autre pile de proxy, sauf si la requête défaillante montre pourquoi ils sont nécessaires.

-15% OFF

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

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Validez la correction après deux redémarrages du proxy et avec un client vierge

Une fois la correction appropriée appliquée, connectez-vous et déconnectez-vous via le nom d’hôte habituel, ouvrez un tableau de bord assez longtemps pour confirmer que la connexion WebSocket reste stable, puis recommencez depuis une fenêtre de navigation privée ou un autre client. Redémarrez ensuite le proxy deux fois et redémarrez l’hôte du proxy si l’adresse ou le réseau de son conteneur fait partie de la cause suspectée.

La comparaison de ZimaSpace entre les chemins Home Assistant locaux et distants applique le même principe d’isolation : préservez le chemin local sain de l’application tout en testant les couches supplémentaires de DNS, TLS, proxy et routage utilisées à distance.

La validation est réussie lorsque la connexion directe et celle via le proxy atteignent la même instance Home Assistant, que l’adresse de proxy limitée attendue est approuvée, que les redirections conservent le protocole et l’hôte prévus, que la connexion WebSocket reste stable en utilisation normale et qu’un redémarrage du proxy ne modifie pas le résultat. Ne revenez à l’authentification Home Assistant que si le même compte connu comme fonctionnel échoue également par accès direct.