¿Por qué Home Assistant pierde las sesiones después de un cambio de proxy o DNS?

La pérdida de sesión después de un cambio de proxy o DNS suele deberse a una discrepancia entre el origen de la URL que usa el cliente y la ruta que ahora ve Home Assistant, no a cuentas de usuario dañadas.

Es posible que un navegador aún conserve cookies y el estado de la interfaz del nombre de host antiguo mientras un teléfono resuelve la nueva dirección, o que el proxy sirva la página de inicio de sesión pero no consiga establecer el WebSocket autenticado. Empieza con una ventana privada y una prueba directa en la LAN, registra el esquema y el nombre de host exactos de cada resultado, y evita eliminar todas las sesiones hasta identificar la capa que falla.

Separa el estado de un cliente de un fallo de ruta compartida

Abre Home Assistant en una ventana privada usando la URL final prevista y compárala con el navegador y la aplicación móvil afectados. Registra si el inicio de sesión se completa, si el panel permanece conectado durante cinco minutos y si una actualización de la página conserva la sesión. Esta comparación reversible prueba si hay un estado obsoleto del cliente sin cambiar el servidor.

Un proxy puede devolver la página de inicio de sesión mientras la interfaz autenticada informa después de que no puede conectarse. Este fallo de conexión después de iniciar sesión correctamente demuestra por qué mostrar HTML no prueba que toda la ruta de sesión funcione.

Si solo falla el navegador antiguo y la ventana privada permanece estable, elimina los datos del sitio de los orígenes antiguo y nuevo de Home Assistant en ese cliente y vuelve a iniciar sesión. Si todos los clientes fallan en la URL del proxy pero el acceso directo por LAN funciona, conserva el estado de los clientes y pasa a revisar la ruta del proxy.

Verifica el WebSocket y el manejo del origen reenviado

Inspecciona la vista de red del navegador o el registro del proxy durante el inicio de sesión y observa la actualización del WebSocket, el estado, el momento de la desconexión, el esquema reenviado, el host reenviado y la dirección del cliente. La distinción útil es entre una página HTTP que carga y un canal autenticado persistente que se actualiza y permanece abierto.

La solución de problemas de proxies inversos de Home Assistant identifica repetidamente el reenvío de WebSocket como un requisito independiente del proxy HTTP normal. Usa ese mecanismo únicamente para interpretar la ruta de actualización, no como prueba de que una configuración de Nginx sirve para todos los proxies.

Si la actualización falla, corrige únicamente la ruta del proxy, las cabeceras de actualización, el esquema reenviado o el límite del proxy de confianza que los registros indiquen que es incorrecto. Si tiene éxito y permanece conectada, deja el proxy sin cambios e investiga el DNS y el estado del origen del cliente.

Compara las respuestas DNS y las URL finales

Resuelve el nombre de host de Home Assistant desde el cliente que falla, un cliente que funciona y el host del proxy. Compara IPv4, IPv6, las respuestas de DNS dividido, el nombre del certificado, el destino de la redirección y la URL almacenada en la aplicación complementaria. Un cambio de DNS solo está completo cuando los clientes llegan al punto de conexión previsto usando el mismo nombre de host canónico.

La relación más amplia entre descubrimiento, resolución de nombres y enrutamiento se explica en el modelo de accesibilidad de Home Assistant. Úsalo para separar una respuesta DNS obsoleta de un fallo de la capa de sesión.

Si los clientes resuelven puntos de conexión diferentes, espera el TTL documentado o borra la caché del resolvedor únicamente en el cliente afectado y en el resolvedor local. No crees nombres de host temporales que compitan entre sí, porque cada origen adicional crea otra frontera de cookies y redirecciones.

Featured

ZimaCube 2 NAS personal en la nube para el hogar

ZimaCube2

$799.00 - $2,499.00

Buy Now

Vuelve a probar la ruta de sesión original y escala el problema de forma específica

Inicia sesión mediante la URL pública o privada final, mantén abierto un panel activo, vuelve a cargar una vista anidada, cambia de red una vez si el acceso remoto forma parte del diseño y repite la prueba después de reiniciar un cliente. La prueba se considera superada si se mantiene la misma URL canónica, el WebSocket permanece estable y la sesión se conserva tras el desencadenante original.

Si el cliente limpio funciona pero un cliente existente sigue fallando, repara únicamente el perfil de ese cliente o la conexión de la aplicación. Si todos los clientes del proxy fallan con las mismas pruebas de actualización o redirección, revierte el último cambio de proxy o DNS y conserva los registros antes de probar otro cambio.

Escala el problema indicando la clase exacta de URL que falla, las respuestas DNS, los códigos de estado del proxy, el resultado del WebSocket, las marcas de tiempo y la comparación entre clientes. Detente cuando dos clientes diferentes conserven las sesiones después de actualizar y reconectar; cualquier cambio adicional en cookies o proxy añadiría riesgos sin valor diagnóstico.