¿Por qué falla el inicio de sesión de Home Assistant después de reiniciar un proxy inverso?

Si el inicio de sesión de Home Assistant falla únicamente después de reiniciar un proxy inverso, prueba primero el inicio de sesión directo desde la LAN y no modifiques la base de datos de usuarios hasta aislar la ruta del proxy.

Un reinicio del proxy puede cambiar la dirección de su contenedor, la información reenviada del cliente, la gestión de WebSocket, el destino DNS o el backend ascendente sin modificar ninguna contraseña de Home Assistant. Por eso, eliminar cuentas y restablecer todas las sesiones no son buenas primeras medidas. Compara la URL directa de Home Assistant con el nombre de host habitual del proxy, guarda los errores del navegador y del proxy, e identifica si el fallo ocurre antes de la autenticación, durante la solicitud de inicio de sesión o cuando el frontend abre su conexión persistente.

Empieza separando la autenticación de Home Assistant de la ruta del proxy

Usa la misma cuenta conocida y válida mediante la dirección local directa de Home Assistant y mediante el nombre de host público o interno del proxy. Si el inicio de sesión directo funciona mientras falla la ruta del proxy, es probable que la cuenta y el estado de autenticación de Core estén suficientemente sanos como para no modificarlos. Si fallan ambas rutas, dirige la investigación de nuevo hacia Home Assistant, el estado restaurado o las propias credenciales.

En un caso de inicio de sesión mediante proxy inverso, el comportamiento directo difería de la ruta de Apache hasta que se corrigieron los detalles de WebSocket y del proxy. Este tipo de comparación directa frente a proxy resulta más útil para diagnosticar que cambiar las contraseñas repetidamente.

Antes de cambiar la configuración, registra el código de estado HTTP, la cadena de redirecciones, el error de la consola del navegador, la respuesta del backend del proxy y la marca de tiempo correspondiente en el registro de Home Assistant. Un error 400 causado por un proxy no confiable, un WebSocket fallido, una redirección al esquema equivocado y una contraseña no válida son fallos distintos, aunque la pantalla muestre la misma imposibilidad genérica de conectarse.

Las cuatro causas del lado del proxy dejan indicios diferentes

Las ramas habituales son: un cambio en la dirección de origen del proxy que ya no coincide con la regla de proxy confiable; cambios en las cabeceras reenviadas o en el esquema; una gestión defectuosa de la actualización de WebSocket; y el enrutamiento hacia un backend de Home Assistant equivocado. La recreación de un contenedor del proxy puede alterar una de estas condiciones mientras la instancia de Home Assistant permanece estable.

Un caso reciente de resolución de problemas con un proxy inverso muestra que Home Assistant rechazaba el tráfico reenviado hasta que el proxy inmediato se incluyó en el rango confiable correcto. Esta comprobación de la identidad del proxy confiable es más segura que ampliar permanentemente el rango: verifica qué dirección del proxy llega realmente a Home Assistant y confía únicamente en ese límite.

Usa los indicios siguientes y cambia una sola rama cada vez. No dejes un rango amplio de proxies confiables después de las pruebas; elimina una protección importante contra direcciones de cliente reenviadas falsificadas.

Causa 1: el reinicio cambió la dirección de origen del proxy

• Indicio: las solicitudes se rechazan inmediatamente y los registros de Home Assistant identifican un proxy inverso no confiable.
• Comprobación: compara la subred o dirección del contenedor del proxy con el rango confiable configurado.
• SI–ENTONCES: si restaurar el rango confiable correcto y restringido soluciona el inicio de sesión, mantén sin cambios la cuenta y el estado de la sesión.

Causa 2: el host o el esquema reenviado ya no coincide con el origen público

• Indicio: las redirecciones alternan entre HTTP/HTTPS o entre nombres de host distintos, o las cookies parecen estar asociadas a un origen inesperado.
• Comprobación: compara el host y el esquema reenviado antes y después del reinicio.
• SI–ENTONCES: si corregir esos valores soluciona el ciclo de redirección e inicio de sesión, el fallo estaba en la identidad de entrada, no en los usuarios de Home Assistant.

Causa 3: la página de inicio de sesión carga, pero falla la actualización de WebSocket

• Indicio: la interfaz estática carga y después el frontend se desconecta o no puede completar la inicialización.
• Comprobación: inspecciona la solicitud WebSocket del navegador y las cabeceras de actualización del proxy.
• SI–ENTONCES: si el acceso directo mantiene abierto el WebSocket mientras que el nombre de host no lo hace, continúa investigando en la capa del proxy.

Causa 4: el proxy apunta a un backend diferente o recién creado

• Indicio: el servidor parece recién configurado, desaparecen usuarios conocidos o el estado específico del servidor difiere al acceder mediante el proxy.
• Comprobación: compara la dirección ascendente, la identidad de la instancia y la ruta de configuración.
• SI–ENTONCES: si el proxy llega al contenedor equivocado o a una instancia restaurada, corrige el enrutamiento antes de modificar los datos de autenticación.

Usa el comportamiento de WebSocket para no confundir un fallo del frontend con un fallo de inicio de sesión

El frontend de Home Assistant depende de una conexión WebSocket persistente después del intercambio HTTP inicial. Por tanto, un proxy puede servir correctamente la página de inicio de sesión, pero fallar unos instantes después, cuando la conexión se actualiza o permanece abierta. Los usuarios suelen describir esa secuencia como un fallo de inicio de sesión porque ocurre inmediatamente después de enviar las credenciales.

Una configuración de proxy inverso de Home Assistant en Synology alcanzaba la ruta de inicio de sesión, pero seguía fallando hasta que se corrigió la gestión de la actualización de WebSocket. Comprobar el comportamiento de actualización de WebSocket mediante el proxy evita perder tiempo restableciendo usuarios cuando la ruta de inicio de sesión HTTP ya funciona correctamente.

Si el socket falla, valida la gestión de la actualización HTTP/1.1, los tiempos de espera, la terminación TLS, el nombre de host y cualquier CDN o middleware de autenticación situado delante del proxy. Mantén reducido el conjunto de cambios. No añadas cabeceras no relacionadas copiadas de otra pila de proxy salvo que la solicitud fallida demuestre por qué son necesarias.

-15% OFF

ZimaBoard 2 - Mini servidor doméstico para tu gran idea

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Valida la solución mediante dos reinicios del proxy y un cliente limpio

Después de aplicar la solución correspondiente, inicia y cierra sesión mediante el nombre de host habitual, abre un panel el tiempo suficiente para confirmar que el WebSocket permanece estable y repite la prueba desde una ventana de navegación privada o un segundo cliente. Después, reinicia el proxy dos veces y reinicia el host del proxy si la dirección del contenedor o la red forman parte de la causa sospechada.

La comparación de ZimaSpace entre las rutas LAN y remotas de Home Assistant aplica el mismo principio de aislamiento: conserva la ruta local saludable de la aplicación mientras pruebas las capas adicionales de DNS, TLS, proxy y enrutamiento que se usan remotamente.

La prueba es satisfactoria cuando el inicio de sesión directo y mediante proxy llegan a la misma instancia de Home Assistant, se confía en la dirección restringida esperada del proxy, las redirecciones conservan el esquema y el host previstos, el WebSocket permanece estable durante el uso normal y un reinicio del proxy no cambia el resultado. Escala la investigación hacia la autenticación de Home Assistant únicamente cuando la misma cuenta conocida y válida también falla mediante la ruta directa.