¿Puede Home Assistant funcionar detrás de un proxy inverso en una subruta?
Home Assistant puede ejecutarse detrás de un proxy inverso, pero servirlo de forma fiable desde una subruta reescrita generalmente no es un límite de implementación compatible.
Una página en example.com/homeassistant puede devolver HTML mientras las solicitudes posteriores siguen dirigiéndose a recursos relativos a la raíz, rutas de autenticación, WebSockets o callbacks de integraciones. Prueba algo más que la primera pantalla: usa un navegador nuevo, inicia sesión, abre un panel en tiempo real, vuelve a cargar una ruta anidada y completa un callback. Si alguna capa elimina el prefijo, mueve Home Assistant a su propio nombre de host en lugar de añadir más reescrituras.
Separa la compatibilidad con proxies inversos de la compatibilidad con subrutas
Un proxy inverso puede terminar TLS y reenviar a Home Assistant una solicitud cuyo origen sea la raíz del nombre de host. Una subruta añade un requisito diferente: cada URL generada, recurso, llamada a la API, WebSocket, redirección y callback debe conservar de forma coherente un prefijo que la aplicación entienda. El éxito en la capa del proxy no establece ese contrato con la aplicación.
Las pruebas de la comunidad de Home Assistant llegan a una conclusión directa: la aplicación no admite implementaciones bajo un prefijo de URL. La respuesta resuelta sobre colocar Home Assistant en una subruta recomienda un subdominio independientemente de la elección del proxy.
APROBADO para la compatibilidad con proxies inversos significa que Home Assistant funciona en la raíz de un nombre de host dedicado con el reenvío correcto. FALLIDO para la subruta propuesta significa que una o más rutas de la aplicación pierden el prefijo. No combines esas conclusiones para afirmar que los proxies inversos son incompatibles.
Usa los recursos del frontend como primera prueba de bajo riesgo
Abre la subruta propuesta en un perfil de navegador privado e inspecciona las solicitudes de red antes de cambiar Home Assistant. Si el documento base se carga, pero JavaScript, los iconos, los manifiestos o las traducciones solicitan rutas desde la raíz del nombre de host, la topología ya ha fallado su primer criterio reversible.
Un intento documentado de reescritura de rutas devolvió la página principal, mientras que los recursos del frontend solicitaron URL con una barra inicial sin el prefijo de Home Assistant. Ese fallo de recursos relativos a la raíz es una discrepancia de rutas de la aplicación, no un archivo ausente en el proxy.
APROBADO significa que todos los recursos del frontend se devuelven correctamente bajo la ruta prevista. FALLIDO significa que aparecen respuestas 404 o solicitudes a rutas de la raíz. Detente ahí y prueba un nombre de host dedicado; sustituir el contenido de las respuestas es frágil porque futuras compilaciones del frontend pueden introducir rutas nuevas que la reescritura no cubra.
Prueba WebSockets, autenticación y rutas anidadas
Un shell de panel estático no constituye una sesión completa. Inicia sesión desde un perfil limpio, observa las actualizaciones de entidades durante varios minutos, actualiza la URL de un panel anidado, cierra sesión y vuelve a iniciarla. Después, comprueba si las actualizaciones HTTP, los tokens, las redirecciones y las recargas de rutas conservan el mismo origen y ruta públicos.
Home Assistant depende en gran medida de WebSockets para la comunicación en tiempo real del frontend, por lo que un proxy debe conservar la ruta y las cabeceras de actualización. El relato de un operador sobre el funcionamiento de WebSockets en un proxy inverso muestra por qué cargar solo HTML no es una prueba suficiente de compatibilidad.
APROBADO significa que la autenticación, las actualizaciones en tiempo real, la navegación y las recargas directas funcionan sin errores de traducción de rutas. Un resultado FALLIDO limitado a sockets o redirecciones sigue rechazando el diseño de subruta. Corregir una directiva del proxy no demuestra que los callbacks y las rutas futuras vayan a reconocer el prefijo.
Elige un nombre de host dedicado como límite estable
Publica Home Assistant en la raíz de un nombre de host dedicado, como ha.example.com, y dirige ese nombre de host mediante el proxy inverso al servicio interno. Esto conserva un único origen público sin exigir que la aplicación entienda un prefijo de ruta. Una VPN privada o un túnel pueden proporcionar el mismo límite raíz limpio sin exponerlo públicamente.
Cuando una ruta remota existente deja de funcionar después de cambios de red, verifica de forma independiente el DNS, la dirección pública, NAT, el túnel y el enrutamiento del proxy. El diagnóstico de ZimaSpace sobre el acceso remoto tras un cambio de router ofrece esa comprobación relacionada.
La alternativa se considera aprobada cuando un navegador limpio puede cargar recursos, establecer un WebSocket, autenticarse, actualizar rutas anidadas y acceder a Home Assistant después de reiniciar el proxy. Mantén la ruta antigua disponible solo el tiempo suficiente para revertir los cambios de DNS o del proxy; no operes indefinidamente con dos URL públicas ambiguas.
Detente cuando la sesión completa sobreviva a un reinicio
Reinicia una vez el proxy y Home Assistant, y luego repite la prueba completa desde la LAN y desde la red remota prevista. Confirma el nombre del certificado, la dirección del cliente reenviada, el límite del proxy de confianza, el inicio de sesión, el estado en tiempo real, el cierre de sesión y un callback de integración. Esta es la carga de trabajo original, no una comprobación reducida de una página estática.
Declara el éxito solo para el diseño con nombre de host raíz que supere todos los pasos. Una subruta que funcione únicamente después de una reescritura personalizada de las respuestas sigue siendo deuda operativa no compatible, porque una actualización puede cambiar el comportamiento de los recursos o callbacks. Documenta el nombre de host válido, la dirección del upstream y la configuración de reversión.
Escala el problema si el diseño con nombre de host raíz sigue fallando, porque la causa restante probablemente sea la confianza del proxy, el reenvío de WebSockets, el DNS, el certificado o el enrutamiento, no la compatibilidad con una ruta base. No expongas Home Assistant directamente en un puerto sin protección solo para conservar la forma de URL deseada.
Productos recomendados
Soporte y Consejos
Más para leer
Home Assistant funciona con Wi-Fi, pero falla con Ethernet o VPN
Prueba cada ruta de red por separado, verifica el estado de la interfaz y del enrutamiento, distingue entre IP directa y descubrimiento, y luego...
Cómo retirar Home Assistant sin dejar datos desprotegidos
Demuestra el reemplazo o archivado, revoca todas las rutas de confianza, sanea cada dispositivo que contenga datos y conserva únicamente copias de recuperación protegidas...
¿Deberías usar actualizaciones automáticas para Home Assistant en un servidor doméstico?
Elige actualizaciones manuales, solo de notificación o automáticas escalonadas según el impacto en el hogar, el riesgo de compatibilidad, el tiempo de observación y...
