Qué hacer si Hyperion no abre en Windows por el puerto 8090

Cuando el panel web de Hyperion no carga en Windows, la causa suele estar en una de estas piezas: el programa no se está ejecutando, el puerto 8090 está ocupado o una regla de seguridad bloquea la conexión. Antes de reinstalar, prueba http://localhost:8090 y después http://127.0.0.1:8090; ambas direcciones llevan al propio ordenador, aunque la segunda evita algunos problemas de resolución de localhost.

Hyperion utiliza HTTP de forma predeterminada, no HTTPS. Escribir https://localhost:8090 puede provocar un error de protocolo aunque el servidor funcione. Si el programa está instalado en otro equipo, localhost tampoco sirve: hay que usar la IP de ese ordenador o dispositivo, seguida del puerto correspondiente. Identificar dónde se ejecuta el servidor y qué dirección está escuchando evita buena parte de los falsos diagnósticos.

Qué ocurre detrás de la página que no carga

Hyperion procesa una señal de vídeo y calcula los colores que deben mostrar las luces conectadas, como una tira LED gestionada por WLED o una bombilla compatible. El panel web es la interfaz desde la que se configura esa instalación; no es, por sí solo, el sistema que captura la imagen o alimenta las luces. El puerto 8090 comunica el navegador con esa interfaz, por lo que un fallo al abrirlo no demuestra necesariamente que haya un problema con los LED.

La imagen que se captura puede proceder del propio ordenador, de un dispositivo conectado a la red o de un montaje con una capturadora. La salida luminosa, a su vez, puede depender de una controladora física o de otro sistema, como WLED. Son partes distintas: es posible que las luces sigan respondiendo mientras la página de configuración no está disponible, o que el panel abra aunque la captura no esté activada. Conviene separar el acceso web del funcionamiento de la iluminación para no cambiar ajustes que no tienen relación con el fallo.

En una instalación local, el navegador contacta con un servidor que debe estar activo en el mismo equipo. En una Raspberry Pi, un mini PC o un ordenador distinto, la petición viaja por la red doméstica. Y en Docker o WSL intervienen además interfaces virtuales y reglas de publicación de puertos. La dirección correcta depende del lugar donde corre Hyperion, no del dispositivo desde el que se abre el navegador.

Comprueba primero que Hyperion esté ejecutándose

Abre el Administrador de tareas con Ctrl + Mayús + Esc y busca hyperiond.exe en la lista de procesos. Si no aparece, el navegador no tiene ningún servicio al que conectarse en ese equipo. Puede que Hyperion no se haya iniciado, que se haya cerrado al arrancar o que la instalación esté configurada para ejecutarse como servicio. La ausencia del proceso explica un rechazo inmediato de la conexión y hace inútil empezar por borrar la caché del navegador.

Si se instaló como servicio, escribe services.msc en el menú Inicio y localiza la entrada de Hyperion. Revisa si figura como iniciada y comprueba su tipo de inicio. Si está detenida, intenta arrancarla y observa si Windows muestra un error. Si el servicio parece iniciarse pero se detiene enseguida, abre sus propiedades y revisa la ruta del ejecutable: una actualización o una migración puede dejar una referencia a una carpeta antigua. El servicio debe apuntar a la versión que realmente está instalada, no a un archivo que ya no existe.

También puedes iniciar Hyperion manualmente para ver si aparece un mensaje útil durante el arranque. Los registros ayudan a distinguir un fallo del servidor web de un problema de permisos o de un puerto ocupado. Si el proceso desaparece inmediatamente, busca el motivo antes de reinstalar: el mensaje puede señalar la causa concreta. Una línea que indique un conflicto de dirección apunta al puerto; un error de permisos dirige la atención a la cuenta del servicio o a las carpetas de datos.

Averigua si el puerto 8090 está libre

Windows no permite que dos programas escuchen al mismo tiempo en una dirección y un puerto idénticos. Si otro servidor local, una herramienta de desarrollo o una aplicación de administración ya ocupa el 8090, Hyperion puede no conseguir abrir su interfaz en ese número. El resultado para el usuario se parece al de un servicio apagado, aunque hyperiond.exe siga activo. Proceso en ejecución no significa necesariamente servidor web disponible.

En PowerShell, ejecuta Test-NetConnection -ComputerName localhost -Port 8090. Si el resultado muestra TcpTestSucceeded como True, hay algo que acepta conexiones en ese puerto; todavía hay que averiguar si se trata de Hyperion. Para identificar el proceso, usa Get-NetTCPConnection -LocalPort 8090 | Select-Object LocalAddress,LocalPort,State,OwningProcess y anota el identificador PID. Después puedes consultar el proceso con Get-Process -Id <PID>, sustituyendo el marcador por el número obtenido. Esta comprobación indica quién ocupa el puerto sin cerrar aplicaciones a ciegas.

La misma revisión puede hacerse desde el Símbolo del sistema con netstat -aon | findstr :8090. El último valor de la línea es el PID; se puede relacionar con un nombre mediante tasklist /FI PID eq <PID>. Si pertenece a otra aplicación, lo más prudente es cerrar esa aplicación solo si sabes que no la necesitas, o cambiar el puerto de uno de los servicios. No finalices un proceso desconocido únicamente para liberar el número.

Si Hyperion permite cambiar el puerto del servidor web en su configuración, puede trasladarse a uno que esté libre, como 8091. En adelante, la dirección incluirá ese nuevo número, por ejemplo http://localhost:8091. El cambio solo tiene sentido después de confirmar el conflicto y debe quedar anotado: si se sigue probando el 8090, el error persistirá aunque el panel esté funcionando en otro puerto. Un puerto distinto resuelve el choque, pero cambia la dirección de acceso.

Descarta una dirección o una ruta de red equivocadas

Localhost significa este equipo, no el ordenador que está al otro lado de la habitación. Si Hyperion corre en una Raspberry Pi, un HTPC o un mini PC, escribe en el navegador su dirección IP local con el puerto 8090, como http://192.168.1.50:8090. La IP de ejemplo debe sustituirse por la dirección real del dispositivo. Puede consultarse en la configuración del router o en el propio equipo. El navegador debe apuntar a la máquina que ejecuta hyperiond.

Cuando no se conoce la IP de un ordenador Windows, el comando ipconfig muestra los datos de sus adaptadores de red. Si se accede por IP y no por un nombre como hyperion.local, el servidor puede estar bien y el problema limitarse a la resolución de ese nombre. Algunos routers o configuraciones no resuelven nombres locales mediante mDNS. En ese caso, probar directamente la IP permite separar un fallo de nombre de un fallo de conexión. Un nombre que no resuelve no equivale a un servidor apagado.

La conexión también puede fallar si los dispositivos están en redes distintas. Una red Wi-Fi de invitados, el aislamiento entre clientes del punto de acceso o una VLAN pueden impedir que un móvil llegue al ordenador, aunque ambos tengan conexión a Internet. Si la página abre en el propio servidor pero no desde otro dispositivo, el problema suele estar en el acceso de red, en el firewall o en la dirección de escucha. Que dos equipos compartan router no garantiza que puedan comunicarse entre sí.

En algunos equipos, localhost puede resolverse como la dirección IPv6 ::1, mientras que el servicio solo escucha en IPv4. Prueba http://127.0.0.1:8090 para forzar la conexión IPv4. Si esa dirección funciona y localhost no, la diferencia da una pista sobre cómo está enlazado el servidor o cómo resuelve el sistema el nombre local. No hace falta modificar IPv6 de inmediato: primero conviene confirmar el comportamiento con ambas direcciones. La comparación entre localhost y 127.0.0.1 ayuda a aislar el problema.

Revisa el firewall y las aplicaciones de seguridad

El Firewall de Windows puede bloquear el tráfico entrante hacia Hyperion, sobre todo si el programa se instaló en una ruta poco habitual o si cambió su ejecutable durante una actualización. En el equipo donde corre el servidor, abre Firewall de Windows con seguridad avanzada y revisa las reglas de entrada para hyperiond.exe. Una regla para el programa limita el permiso a ese ejecutable; otra opción es permitir TCP 8090. La excepción debe corresponder al proceso o al puerto que realmente utiliza Hyperion.

Para un uso doméstico, comprueba que la regla se aplica al perfil de red adecuado, normalmente el privado cuando el equipo está conectado a la red de casa. Habilitar permisos en todos los perfiles sin necesidad amplía el acceso más de lo que hace falta. Si el panel abre en el propio ordenador, pero no desde otro dispositivo, una regla de entrada o una dirección de escucha limitada son causas más probables que un problema del navegador remoto. El acceso local y el acceso desde la red son pruebas distintas.

Algunas suites de seguridad incorporan su propio cortafuegos y pueden interceptar las conexiones locales incluso cuando la regla de Windows parece correcta. Una prueba temporal, controlada y breve, puede ayudar a localizar la interferencia; después hay que reactivar la protección y crear la excepción correspondiente en esa suite. No es una solución dejar el antivirus o el firewall desactivados. La prueba sirve para diagnosticar, no para mantener el equipo desprotegido.

Si funciona desde otro dispositivo al usar la IP, pero falla mediante localhost, revisa también el proxy del navegador o del sistema. En equipos corporativos puede haber un proxy forzado que intente enviar incluso las direcciones locales fuera del ordenador. Excluir localhost, 127.0.0.1 y las direcciones privadas puede corregirlo, siempre dentro de las políticas del equipo. Un proxy mal aplicado puede desviar una petición que debería quedarse en el dispositivo.

Cuando el servidor web está desactivado o mal configurado

Hyperion puede estar funcionando y, aun así, no ofrecer la interfaz web en el puerto esperado. Una configuración importada desde otro ordenador, una actualización o una copia de archivos puede haber dejado el servidor web deshabilitado, con otro puerto o enlazado a una interfaz concreta. Si el panel abre desde el icono de la bandeja o desde otro canal de control, entra en los ajustes y revisa la sección del servidor web. El estado habilitado, el puerto y la dirección de escucha deben ser coherentes.

La dirección de escucha determina desde qué interfaces se aceptan conexiones. Si se limita a 127.0.0.1, el panel puede abrir en el propio ordenador, pero no desde un móvil o un segundo equipo. Para acceder desde la red local, el servidor debe escuchar en una interfaz que acepte esas conexiones; en algunas configuraciones se utiliza 0.0.0.0 para todas las interfaces IPv4. Esa opción aumenta la exposición dentro de la red, por lo que debe combinarse con reglas de firewall razonables. Escuchar en todas las interfaces no es lo mismo que abrir el servicio a Internet.

Si no puedes entrar en el panel, busca el archivo de configuración de Hyperion y haz primero una copia de seguridad. La ubicación depende del método de instalación y de la cuenta con la que se ejecuta el servicio, por lo que no conviene asumir que siempre está en la misma carpeta. Revisa la configuración del servidor web y confirma si está habilitado y qué puerto utiliza. Evita editar claves cuyo significado no conozcas: un cambio incorrecto puede impedir que arranque el resto del servicio. Conservar una copia permite revertir cualquier modificación.

Otra causa menos evidente es que el servidor acepte la conexión, pero no encuentre los archivos que forman la página. En ese caso el navegador puede mostrar una pantalla en blanco o cargar el marco sin los controles. Los registros pueden señalar errores al leer recursos o rutas que ya no existen. Si abrir el programa como administrador cambia el resultado, eso apunta a permisos, pero no es recomendable ejecutar Hyperion de forma permanente con privilegios elevados. La solución duradera es corregir permisos o rutas, no convertir la elevación en un requisito habitual.

Qué cambia con WSL, Docker, VPN y otros equipos

En WSL2, Hyperion se ejecuta dentro de un entorno Linux con una interfaz de red virtual. Por eso, que el panel responda a una prueba hecha dentro de WSL no garantiza que Windows pueda acceder a él. Comprueba primero desde WSL con curl http://127.0.0.1:8090. Si responde allí, pero no en el navegador de Windows, revisa en qué dirección escucha el servicio y cómo se publica o reenvía el puerto hacia el sistema anfitrión. La frontera entre WSL y Windows añade una capa de red.

En Docker sucede algo parecido: un puerto que solo está disponible dentro del contenedor no queda automáticamente accesible desde Windows. Al crear el contenedor hay que publicar el puerto del servicio hacia el equipo anfitrión, y Hyperion debe escuchar en una interfaz accesible dentro del contenedor. Si falta esa publicación, localhost:8090 en Windows no llegará al servidor, aunque este se vea activo desde Docker. El contenedor necesita un mapeo de puerto para exponer la interfaz.

Las VPN y los adaptadores virtuales de Hyper-V o VirtualBox pueden alterar la ruta que Windows utiliza para llegar a una dirección. Para probarlo, desconecta temporalmente la VPN si las normas de la red lo permiten y vuelve a intentar la conexión local. Si entonces funciona, revisa la configuración de rutas o las exclusiones de red de la VPN. No es necesario desinstalar adaptadores por una sola prueba: el objetivo es comprobar si una interfaz virtual está desviando el tráfico. Una conexión local puede verse afectada por rutas que parecen ajenas a Hyperion.

Si Hyperion está en otro dispositivo, prueba primero desde un navegador instalado en ese mismo equipo y después desde Windows. Si abre localmente pero no desde el ordenador, revisa el firewall del servidor, el aislamiento de la red y la dirección de escucha. Si tampoco abre en el propio dispositivo, vuelve a comprobar el proceso y los registros. Comparar una conexión local con otra remota permite acotar dónde se corta la comunicación.

Lee los registros antes de reinstalar

Los registros de arranque suelen dar una respuesta más precisa que los intentos repetidos en el navegador. Busca mensajes sobre el servidor HTTP, el puerto seleccionado y los errores de enlace. Una indicación de que el servidor web se ha iniciado en 0.0.0.0:8090 confirma que escucha en ese puerto en todas las interfaces IPv4; un fallo de enlace, un permiso denegado o un aviso de puerto en uso conducen a diagnósticos distintos. El mensaje exacto importa más que el aspecto del error en pantalla.

Si el puerto está ocupado, identifica el proceso responsable y decide si conviene liberar ese número o cambiar el de Hyperion. Si el registro revela permisos, comprueba la cuenta del servicio y los permisos de las carpetas de datos. Si no aparece ningún inicio del servidor web, revisa si está deshabilitado o si se configuró otro puerto. No todos los errores del navegador son equivalentes: una conexión rechazada, una página vacía y un error de certificado no señalan necesariamente el mismo origen. El síntoma orienta, pero el registro confirma la causa.

Cuando el panel carga de forma incompleta después de una actualización, puede haber datos antiguos en la caché del navegador o una diferencia entre los archivos de la interfaz y el servicio instalado. Prueba una ventana privada o borra la caché del sitio antes de cambiar la configuración del servidor. Si la página abre en otro navegador, las extensiones, el proxy o los datos guardados son sospechosos. Una prueba con el navegador limpio evita tocar una instalación que quizá está sana.

Reinstalar solo cuando las comprobaciones no bastan

La reinstalación tiene sentido cuando el ejecutable está dañado, el servicio apunta a una instalación desaparecida o la configuración no puede recuperarse con seguridad. Antes de hacerlo, guarda la carpeta de datos y cualquier configuración que quieras conservar. Desinstalar y borrar archivos sin una copia puede eliminar ajustes de las instancias LED, dispositivos o captura, obligando a reconstruir la configuración. La copia de seguridad debe preceder a la limpieza.

Después de instalar, comprueba que el panel abre con la configuración inicial antes de importar archivos antiguos o restaurar preferencias. Así se distingue un problema de instalación de uno heredado de la configuración previa. Si el panel funciona recién instalado y deja de hacerlo tras recuperar los ajustes, el origen probablemente está en alguno de esos datos o en un puerto o enlace que no coincide con el equipo nuevo. Restaurar por etapas ayuda a no reintroducir el fallo entero.

El objetivo no es que el puerto 8090 responda a cualquier precio, sino que el navegador llegue al servidor correcto con una configuración coherente y un acceso limitado a la red necesaria. En la mayoría de los casos, revisar el proceso, el puerto, la dirección local y el firewall basta para localizar el bloqueo; los registros y la configuración quedan para los casos menos claros. Un diagnóstico por capas conserva la instalación y evita cambios innecesarios.