Hyperion Ambilight Windows no abre 8090 web​: ¿qué hacer?

Hyperion en Windows no abre en 8090; guía directa para recuperar la web UI: proceso, puerto, firewall, WSL/Docker y pasos claros, hoy mismo.

Si el panel de Hyperion no carga en Windows al entrar en http://localhost:8090 o http://127.0.0.1:8090, la salida rápida y efectiva pasa por tres comprobaciones, en este orden: verificar que el proceso de Hyperion está ejecutándose, asegurar que el puerto 8090 no está ocupado por otra aplicación y permitir el acceso en el firewall. Cuando esas tres piezas encajan, la interfaz web responde. Si una falla, aparecen errores del navegador (“no se puede acceder a este sitio”, “ERR_CONNECTION_REFUSED”, páginas en blanco…); no hace falta reinstalar nada todavía.

Para desbloquear el acceso de inmediato, abre el Administrador de tareas y confirma que hyperiond.exe está activo. Si no lo está, inícialo o arráncalo como servicio desde services.msc. A continuación, comprueba si 8090 ya lo usa otro proceso y, si es necesario, cierra al intruso o cambia el puerto del panel de Hyperion. Por último, crea una excepción en Windows Defender Firewall (o en tu suite de seguridad) para hyperiond.exe o, como mínimo, para TCP 8090. Prueba de nuevo con http://localhost:8090 y, si el navegador insiste, usa http://127.0.0.1:8090 o la IP local del equipo. Con eso suele bastar.

Lo esencial para que el panel responda en el puerto 8090

Hyperion actúa como cerebro de la iluminación ambiental y su panel web es el tablero de mandos. En Windows, ese panel responde por HTTP en el puerto 8090 de forma predeterminada. No utiliza HTTPS, salvo que se haya configurado expresamente, así que conviene escribir la dirección exacta y evitar el “https://” por inercia. Si el navegador fuerza HTTPS, puede devolver ERR_SSL_PROTOCOL_ERROR o quedarse en un candado tachado que confunde. Es http, no https, y esto, aunque parezca menor, ahorra tiempo.

Primero, asegurar que Hyperion está vivo. Con Ctrl + Mayús + Esc abre el Administrador de tareas, pestaña Procesos, y busca hyperiond.exe. Si no aparece, puede que la instalación no cree servicio y toque lanzarlo manualmente; si instalaste como servicio, entra en services.msc, localiza Hyperion, revisa el estado y el tipo de inicio (mejor Automático para olvidarte). Otra causa común: se ha actualizado el programa, pero el servicio apunta a una ruta antigua. En Propiedades del servicio, revisa el “Ruta de acceso al archivo ejecutable” y corrige si no coincide con la instalación real.

Segundo, recordar dónde está corriendo Hyperion. Localhost apunta al equipo desde el que navegas, nada más. Si Hyperion se ejecuta en otro dispositivo (un mini PC, un NUC o una Raspberry Pi), la dirección correcta es http://IP_DEL_SERVIDOR:8090. Es frecuente teclear localhost en el portátil mientras Hyperion vive en el salón. Si accediendo por IP abre y por localhost no, no es culpa del programa: es ubicación.

Tercero, descartar problemas triviales del navegador. Una ventana privada o un navegador secundario, sin extensiones, ayuda a evitar interferencias de bloqueadores, proxies o extensiones que interceptan tráfico local. En entornos corporativos, el navegador puede forzar un proxy incluso para 127.0.0.1. Añadir excepciones para direcciones locales (127.0.0.1, 192.168.x.x, 10.x.x.x) suele ser suficiente.

Cuando el 8090 está ocupado o bloqueado

Lo habitual cuando el proceso existe y la dirección es la correcta es topar con algo prosaico: el puerto 8090 está ocupado por otro servicio. Windows no permite que dos procesos escuchen en el mismo puerto. Un servidor local, una herramienta de desarrollo, una utilidad de administración, un túnel o incluso una suite de seguridad pueden haberse adelantado y “coger sitio”.

Cómo saber quién está usando 8090 sin perder tiempo

La comprobación es directa. Abre PowerShell y ejecuta Test-NetConnection -ComputerName localhost -Port 8090. Si devuelve TcpTestSucceeded: True hay algo escuchando. ¿Es Hyperion? Para identificar al dueño, lanza Get-NetTCPConnection -LocalPort 8090 | Select-Object LocalAddress,LocalPort,State,OwningProcess. Anota el PID y resuélvelo con Get-Process -Id <PID>. Clásico de toda la vida: en Símbolo del sistema, netstat -aon | findstr :8090 y luego tasklist /FI "PID eq <PID>". Con eso sabrás si hyperiond.exe es quien escucha o si otra aplicación ha tomado el puerto.

Si el intruso es ajeno, hay dos salidas limpias: cerrar esa aplicación o cambiar su puerto. Si no es viable, mover el panel de Hyperion a un puerto libre, por ejemplo 8091 o 8080. Importante: documenta el cambio. Anotar “Web UI de Hyperion en 8091” evita volver al bucle de 8090 dentro de una semana. Y, desde luego, entrarás por http://localhost:8091 a partir de ese momento.

Hay una variante escurridiza: localhost resolviendo a IPv6 (::1) mientras Hyperion sólo escucha en IPv4 (127.0.0.1). El navegador intenta conectar a ::1, no encuentra quién le atienda y muestra un Connection refused. Forzar http://127.0.0.1:8090 aclara si el problema es esa dualidad IPv4/IPv6. También puedes comprobarlo con netsh interface ipv6 show tcpconnections o, más fácil, mirando si Hyperion está enlazado a 0.0.0.0 (todas las interfaces) en los registros de arranque.

Abrir paso en el firewall de Windows sin agujerear la red

El firewall es el otro sospechoso habitual. Si Hyperion se instaló en una ruta poco común o la suite de seguridad no reconoció el binario, el sistema puede bloquear el tráfico entrante al 8090 o incluso el saliente. En el primer caso, el panel abrirá en local pero no desde otros dispositivos de la red. En el segundo, ni siquiera en el propio equipo.

La solución robusta es crear una regla de entrada por Programa para hyperiond.exe desde “Firewall de Windows con seguridad avanzada” y marcar “Permitir la conexión” en Privado y Público si el equipo se mueve. Como refuerzo, una regla por Puerto para TCP 8090 sirve cuando prefieres controlar servicios por número. En algunas políticas, además, se exigen reglas de salida: duplicar la lógica por salida evita sorpresas.

Ojo con las suites de terceros. Muchas incluyen su propio firewall o una capa de inspección que intercepta tráfico local. Si al desactivar temporalmente la suite el panel abre al instante, ya está localizada la causa: toca añadir Hyperion a las exclusiones o crear reglas equivalentes en su panel. Y conviene no olvidarlo: reactivar la suite tras la prueba.

Un apunte práctico: si por IP local (por ejemplo, http://192.168.1.23:8090) abre, pero por localhost no, el bloqueo tal vez no sea del firewall sino una resolución rara de localhost o un proxy mediando donde no debe. Si es al revés —abre en local y no desde otro equipo—, es casi siempre firewall en el equipo servidor o binding limitado a 127.0.0.1.

Ajustes de Hyperion que cierran su propia puerta

No todo lo provoca Windows. Hyperion permite configurar su servidor web y basta un ajuste heredado de otra máquina para que 8090 quede fuera de juego. Tras importar una copia de configuración, actualizar a una versión mayor o copiar una instalación portable de un equipo a otro, pueden quedar restos: puerto cambiado, web UI deshabilitada, binding encadenado a una interfaz específica.

Revisar y editar la configuración con criterio

Si aún conservas algún canal de control —por ejemplo, la API, un icono de bandeja o una integración—, entra a Ajustes y comprueba la sección del servidor web. Debe estar habilitado, con puerto correcto y —si quieres acceso desde otros dispositivos— enlazado a 0.0.0.0. Si no tienes acceso a la interfaz, toca editar el archivo de configuración. En Windows, Hyperion.ng suele guardar el JSON en la carpeta de datos del usuario o en la carpeta de instalación, según método. Abre el archivo con un editor de texto, localiza la sección del web server y corrige “enabled”, “port” y “binding”. Guardar, reiniciar hyperiond.exe y probar.

Otra pista fina: algunos paquetes incluyen rutas relativas hacia el webroot (los archivos estáticos del panel). Si la carpeta se movió o la ruta perdió permisos, el servidor arranca, abre el socket, pero la página queda en blanco. En los logs aparecen errores de lectura de recursos o rutas no encontradas. Ejecutar una vez como administrador permite confirmar si es permisos NTFS. Si así sí funciona, lo correcto no es vivir eternamente como administrador: mueve la carpeta de datos a una ruta con permisos adecuados o ajusta los permisos de la ruta actual para la cuenta del servicio.

Rutas, servicios y migraciones que se cruzan

Las actualizaciones pueden dejar un pequeño rompecabezas. El instalador coloca el binario nuevo en C:\Program Files\Hyperion (por ejemplo), pero el servicio sigue apuntando a otra ruta o a un ejecutable obsoleto. El resultado: el servicio no arranca o cae al iniciar, y el panel, claro, no responde en 8090. Abre Servicios, entra en Propiedades del servicio de Hyperion y valida la ruta de inicio. Si falló una migración, considera desinstalar con limpieza, eliminar la carpeta de datos tras una copia de seguridad y reinstalar en una ruta conocida; después, validar el panel antes de importar ajustes.

También es posible que Hyperion haya cambiado de puerto porque detectó “address already in use” en el arranque. Sucede: para no chocar, salta a otro. El usuario, mientras, insiste en 8090 y la sensación es que “no abre”. Mirar el log de arranque aclara estas situaciones. Si no ves ninguna línea sobre el web UI, mala señal: lo más probable es que esté deshabilitado en el JSON. Rehabilítalo y vuelve a arrancar.

Entornos mixtos: remoto, WSL y contenedores

Los montajes de iluminación ambiental suelen mezclar equipos y capas. Ahí aparecen matices de red, túneles, interfaces virtuales y segmentaciones que confunden a cualquiera.

Hyperion en otro equipo de la red doméstica

Si Hyperion corre en un HTPC, un mini PC o una Raspberry Pi, Windows no es el servidor. El panel abre en http://IP_DEL_SERVIDOR:8090. Si al introducir la IP no abre, prueba un ping a esa dirección. Si responde al ping pero el navegador no conecta al 8090, hay un firewall en el servidor bloqueando. Configura allí la excepción. Si ni responde al ping, probablemente estás en otra subred o en un Wi-Fi de invitados que bloquea tráfico lateral. Conectar ambos dispositivos al mismo segmento (mismo SSID, misma VLAN, sin aislamiento AP) resuelve lo que no es problema de Hyperion, sino de topología.

En redes con DNS mDNS (hyperion.local), a veces el nombre no resuelve según la configuración de tu router o de Windows. Si escribes http://hyperion.local:8090 y no abre pero por http://192.168.1.50:8090 sí, ya está el diagnóstico: nombre que no resuelve. Puedes añadir una entrada en el archivo hosts o, más simple, usar la IP.

WSL, Docker y el puente con Windows

Con WSL2, Linux vive detrás de una interfaz virtual. El puerto 8090 que escucha dentro puede no ser visible para Windows si sólo está enlazado a 127.0.0.1 dentro de WSL o si no hay reenvío de puertos. Comprobación básica: en WSL, curl http://127.0.0.1:8090. Si responde dentro y no desde Windows, hay que publicar el puerto. Dos vías: enlazar Hyperion a 0.0.0.0 dentro de WSL o crear un portproxy con netsh interface portproxy add v4tov4 listenport=8090 listenaddress=0.0.0.0 connectport=8090 connectaddress=<IP_WSL>. En Docker, si levantaste el contenedor sin -p 8090:8090, Windows jamás verá ese puerto. Hay que mapearlo y asegurarse de que el servicio escucha en 0.0.0.0 dentro del contenedor.

Una observación que evita tirarse de los pelos: adaptadores virtuales (VPNs, Hyper-V, VirtualBox) y métricas de interfaz. Windows a veces prioriza la interfaz equivocada; el navegador intenta llegar al 8090 por un túnel que no devuelve tráfico. Desactivar temporalmente la VPN, ajustar la métrica o entrar por la IP de la interfaz correcta aclara dudas. Si por IP funciona y por nombre no, o si con la VPN desactivada abre al instante, la causa no está en Hyperion sino en la ruta de red.

VPN, proxies y DNS que meten la cuchara

En entornos corporativos, el sistema puede forzar un proxy para todo HTTP, incluso local. El intento de http://localhost:8090 se dirige a un proxy que no sabe llegar a tu loopback y responde con error. La solución es excluir 127.0.0.1, localhost y los rangos privados de esa configuración. Otra variante: localhost resolviendo a ::1 (IPv6) mientras el servicio sólo escucha en IPv4. Con http://127.0.0.1:8090 se bordea esa trampa. Si te has liado en cambios de DNS, limpiar caché con ipconfig /flushdns ayuda a empezar de cero.

Un procedimiento de diagnóstico que funciona

Cuando lo simple falla, conviene aplicar una secuencia que evita pasos en falso y reinstalaciones a ciegas. No hace falta obsesionarse con el orden perfecto; basta con mantener el método.

Arranque. Verificar hyperiond.exe en el Administrador de tareas. Si no está, lanzarlo. Si cae al instante, abrirlo en consola para leer el log en vivo. Mensajes como “address already in use” apuntan a conflicto de puerto. “Permission denied” sugiere permisos NTFS o antivirus. Ausencia total de mensajes del web UI delata web desactivada en la configuración. Cuando se aclare, reiniciar el proceso.

Puerto. Comprobar ocupación de 8090 con PowerShell o netstat. Si otro proceso manda, decidir: liberar 8090 o mudar el panel de Hyperion a otro puerto libre. Lo importante es no improvisar: cambiar de puerto sin confirmar la causa sólo enreda más. Si el cambio es la solución, dejarlo por escrito.

Firewall. Permitir hyperiond.exe y, si la política lo exige, TCP 8090 en entrada y salida. Verificar si abre en local y desde otro dispositivo. Si en el propio equipo responde y desde fuera no, es casi seguro firewall en el servidor o binding a 127.0.0.1. Si ni en local, tal vez la suite de seguridad intercepta. Desactivar temporalmente para confirmar y luego crear exclusión.

Navegador. Probar ventana privada o navegador limpio. Desactivar extensiones con capacidad de red. Revisar configuración de proxy del sistema y del navegador. Asegurar excepciones para direcciones locales.

Direcciones. Usar 127.0.0.1 (no sólo localhost) y la IP local del equipo; si el servicio vive en otro dispositivo, su IP. Si tecleas hyperion.local y no resuelve, entrar por IP; si es imprescindible el nombre, añadir al hosts o activar mDNS en el router.

Entornos. Si Hyperion corre en WSL o Docker, publicar el puerto y enlazar a 0.0.0.0. Si hay VPN, pausarla para la prueba o añadir bypass a la red local. Con túneles o adaptadores virtuales, ajustar la métrica de interfaz si Windows insiste en la ruta equivocada.

Configuración. Si todo lo anterior encaja y no abre, revisar el JSON de Hyperion: web UI habilitada, puerto correcto, binding adecuado. Si huele a config corrupta, respaldar el archivo y permitir que Hyperion regenere una nueva por defecto. Confirmar que el panel abre con valores limpios y reaplicar ajustes poco a poco, validando en cada paso.

Reinstalación. Último recurso. Cuando se elige, que sea limpia: desinstalar, eliminar carpeta de datos (tras copia), instalar de nuevo, abrir el panel antes de importar perfiles y crear reglas en el firewall cuando Windows lo proponga. Si aquí abre, Hyperion está bien; los problemas venían de residuos de la configuración anterior.

A lo largo del proceso emergen patrones útiles. Si la página queda completamente blanca, suele haber un problema de recursos estáticos o de rutas: por IP a veces carga cuando por nombre no, o al revés. Si el navegador avisa de CORS en su consola, suele significar orígenes cruzados mal resueltos por usar proxys o puertos distintos: entrar directamente por http://IP:8090 corta ese nudo. Si Hyperion sólo abre como administrador, no es el puerto: son permisos en la carpeta de datos o en el webroot. Ajustar ACLs de NTFS soluciona sin vivir elevado para siempre.

Casuística real que ahorra horas

Casos vistos una y otra vez. 8080 ocupado por un servidor web local y 8090 tomado por una herramienta de desarrollo, con Hyperion saltando a un puerto alto que nadie recuerda; la web no abre “en 8090” porque ya no está ahí. Usuarios que copian la carpeta de Hyperion de un PC a otro y arrastran un binding atado a 127.0.0.1; en su máquina abre, desde el móvil no. Solución: binding 0.0.0.0. Equipos con DNS corporativo que reescribe localhost a un alias IPv6; con 127.0.0.1 todo responde, misterio resuelto. Gente peleándose con https por costumbre; basta quitar la “s”.

Luego están los antivirus. Algunos interceptan tráfico loopback y TLS local; no es lo más común, pero cuando sucede, la prueba con suite desactivada ilumina. El remedio no es vivir sin protección, sino excluir el binario y whitelistear el puerto. En entornos con políticas corporativas que sólo permiten 80/443, el 8090 puede estar bloqueado por política; ahí sólo cabe negociar una excepción o mover el panel a 8080 o 443 (sin TLS si no se configura), documentándolo.

Si el panel abre pero se rompe a mitad —carga el marco, no los controles— suele ser un mismatch entre frontend y backend tras actualizar. Una limpieza de caché dura (borrar caché del navegador) puede bastar, aunque lo sólido es alinear versiones. Otra rareza: tarjetas de red múltiples y rutas métricas mal priorizadas; el servidor escucha bien, pero la respuesta sale por la interfaz equivocada. Ajustar el métrico o desactivar adaptadores virtuales durante la prueba evita perseguir fantasmas.

Los logs siguen siendo los mejores amigos. Lanzar hyperiond.exe desde PowerShell y observar línea a línea regala diagnósticos: “HTTP server started at 0.0.0.0:8090” es la música que se quiere oír. “Bind failed”, “permission denied”, “port in use” o “webserver disabled” orientan con precisión quirúrgica. A partir de ahí, todo es mecánico.

Luz verde para el 8090

Cuando aparece el clásico “Hyperion Ambilight Windows no abre 8090 web”, la solución suele estar al alcance de la mano con proceso activo, puerto libre y regla de firewall bien montada. A veces es una cuestión de ruta de servicio tras una actualización; otras, de binding caprichoso a 127.0.0.1 que impide conectar desde el salón; de vez en cuando, un proxy corporativo metiendo ruido o una VPN con ganas de protagonismo. El camino para salir del bucle, sin embargo, no cambia: confirmar que hyperiond.exe vive, diagnosticar 8090, permitir el tráfico, probar por 127.0.0.1 y por IP, quitar HTTPS por inercia, publicar el puerto si corre en WSL o Docker y, sólo si todo falla, reconfigurar o reinstalar limpio.

No hay magia negra aquí. Hay método, un puñado de comandos que cualquiera puede ejecutar y un par de decisiones informadas. La recompensa es inmediata: el panel vuelve a abrir en http://localhost:8090, la configuración responde, y la iluminación acompasa por fin la pantalla como debía desde el principio. Con el 8090 despejado y a la vista, el resto —perfiles, efectos, fuentes de captura— vuelve a ser lo divertido de esta historia. Y así debería ser.

🔎​ Contenido Verificado ✔️

Este artículo ha sido redactado basándose en información procedente de fuentes oficiales y confiables, garantizando su precisión y actualidad. Fuentes consultadas: Soporte de Microsoft, Microsoft Learn, INCIBE, Universidad Rey Juan Carlos.