La consola de Proxmox no se abre (SPICE/noVNC): dónde falla y cómo arreglarlo

Cómo funciona realmente la consola de Proxmox (y dónde falla)

Proxmox te ofrece dos rutas principales de consola para VMs:

• noVNC (basada en el navegador): la interfaz web abre una página que establece un WebSocket de vuelta al nodo y proxya el flujo VNC de la VM.
• SPICE (cliente o lanzado desde el navegador): la interfaz genera un archivo .vv y un ticket de un solo uso; un cliente SPICE se conecta a través de un proxy.

Ambas se basan en la misma verdad operativa: la interfaz web no es el servidor de consola. Es un controlador de tráfico. Te autentica, solicita un ticket de corta duración y luego espera que tu navegador/cliente llegue al nodo correcto y al puerto correcto, con las expectativas TLS correctas y las reglas de firewall permitidas.

La cadena de noVNC (simplificada, pero lo bastante precisa para depurar)

1. Cargas la interfaz web de PVE (normalmente https://NODE:8006).
2. La interfaz pide a la API un ticket VNC para VMID/CTID.
3. La interfaz abre una página noVNC y intenta una conexión WebSocket al nodo (todavía por el puerto 8006 en muchas configuraciones).
4. pveproxy acepta el WebSocket, valida el ticket y reenvía los datos al endpoint VNC local expuesto por QEMU.
5. QEMU habla VNC. noVNC pinta píxeles. Escribes y envía eventos de teclado de vuelta.

Puntos comunes de fallo: WebSocket bloqueado por un reverse proxy, desajuste TLS, dirección de nodo incorrecta en un clúster, ticket rechazado por deriva de reloj, o un firewall que deja caer el salto interno.

La cadena de SPICE

1. La interfaz solicita un ticket de proxy SPICE y genera un archivo .vv.
2. Tu cliente SPICE lee el archivo y se conecta al endpoint del proxy (a menudo a través de pveproxy en 8006, a veces en un puerto dedicado según la configuración).
3. El proxy reenvía al servidor SPICE de QEMU (configurado por VM).

SPICE suele fallar porque el cliente no puede alcanzar el nodo (enrutamiento/NAT), el proxy anuncia mal la dirección del nodo, o el cliente tiene problemas con TLS/confianza de certificados.

Una cita operativa que ha envejecido bien: “You build it, you run it.” — Werner Vogels. Si ejecutas Proxmox, también eres responsable de toda la cadena de consola: política del navegador, cabeceras del proxy y el tedioso sincronizado del tiempo.

Un chiste rápido, porque lo vas a necesitar: que la consola falle mientras el nodo parece verde es como un coche con pintura perfecta y sin volante.

Guía rápida de diagnóstico

Este es el camino de “deja de desplazarte y arréglalo”. El objetivo es identificar qué eslabón de la cadena está roto en cinco minutos.

Primero: decide si es problema del navegador/GUI, proxy del nodo o backend de la VM

1. Prueba desde la dirección directa del nodo (no vía VIP, no vía reverse proxy). Si la consola funciona directa pero no vía tu frontend, ya conoces al culpable: tu proxy/WAF/cabeceras/TLS.
2. Revisa DevTools → Console/Network en el navegador buscando errores de WebSocket. Si ves WebSocket connection failed o un 401/403 en un endpoint websocket, estás ante autenticación/tickets/proxy.
3. Revisa logs de pveproxy y pvedaemon. Si muestran errores de ticket, arregla sincronización horaria o problemas de realms de autenticación. Si no muestran nada, tu tráfico no está llegando (firewall/proxy/enrutamiento).

Segundo: comprueba la salud del nodo donde importa para consolas

1. ¿Está pveproxy en ejecución y escuchando en 8006?
2. ¿El hostname/IP del nodo es consistente con lo que el clúster anuncia? Una “dirección anunciada” incorrecta rompe la redirección de consola de maneras extrañas.
3. ¿Está el tiempo sincronizado? La validación de tickets depende del tiempo. La deriva del reloj convierte la autenticación en una moneda fuera de control.

Tercero: valida el backend de la consola de la VM

1. ¿La VM está configurada para una pantalla y funcionando? (VNC o SPICE habilitado, no deshabilitado por configuración.)
2. ¿Responde QEMU? Un QEMU bloqueado puede mantener la VM “en ejecución” pero nunca aceptar una consola.

Tareas prácticas: comandos, salidas, decisiones

Estas son tareas reales que puedes ejecutar en un nodo Proxmox (o en una estación de administración donde se indique). Cada una incluye: un comando, cómo se ve una salida sensata y qué hacer a continuación.

Tarea 1: Comprueba que el proxy web está en ejecución (la pasarela de consola)

cr0x@server:~$ systemctl status pveproxy --no-pager
● pveproxy.service - PVE API Proxy Server
     Loaded: loaded (/lib/systemd/system/pveproxy.service; enabled)
     Active: active (running) since Fri 2025-12-26 09:12:11 UTC; 2h 3min ago
   Main PID: 1322 (pveproxy)
      Tasks: 4 (limit: 38391)
     Memory: 62.4M
        CPU: 1min 12.204s

Decisión: Si no está activo/en ejecución, reinícialo y luego busca por qué murió (a menudo permisos de archivos TLS, disco lleno o configuración rota). Si está en ejecución, sigue: tu problema probablemente sea alcanzabilidad, tickets, WebSockets o comportamiento del reverse proxy.

Tarea 2: Confirma que algo escucha en el puerto 8006

cr0x@server:~$ ss -ltnp | awk '$4 ~ /:8006$/ {print}'
LISTEN 0      4096         0.0.0.0:8006      0.0.0.0:*    users:(("pveproxy",pid=1322,fd=6))
LISTEN 0      4096            [::]:8006         [::]:*    users:(("pveproxy",pid=1322,fd=7))

Decisión: Si nada escucha, tu consola no funcionará. Arregla primero pveproxy. Si escucha sólo en IPv6 y tus clientes sólo son IPv4 (o viceversa), ajusta el binding o el DNS.

Tarea 3: Busca errores obvios del proxy en el journal

cr0x@server:~$ journalctl -u pveproxy -S -2h --no-pager | tail -n 30
Dec 26 10:55:41 pve1 pveproxy[1322]: proxy detected vanished client connection
Dec 26 10:58:03 pve1 pveproxy[1322]: worker 1377 finished
Dec 26 11:12:09 pve1 pveproxy[1322]: starting 1 worker(s)

Decisión: “Vanished client connection” suele ser un navegador/proxy/WAF cerrando WebSockets. Si ves fallos de handshake TLS o errores de permisos, eso es del nodo. Si el journal está en silencio mientras haces clic en Console, probablemente tu tráfico no llega al nodo (enrutamiento, firewall, reverse proxy).

Tarea 4: Observa el log del proxy mientras reproduces el problema

cr0x@server:~$ tail -f /var/log/pveproxy/access.log
10.10.20.55 - root@pam [26/Dec/2025:11:18:09 +0000] "GET /api2/json/nodes/pve1/qemu/101/vncproxy HTTP/1.1" 200 460
10.10.20.55 - root@pam [26/Dec/2025:11:18:09 +0000] "GET /api2/json/nodes/pve1/qemu/101/vncwebsocket?port=5901&vncticket=PVEVNC:... HTTP/1.1" 101 0

Decisión: Un 200 en vncproxy seguido de un 101 en vncwebsocket es saludable: la actualización a WebSocket funcionó. Si ves 401/403, céntrate en auth/tickets/tiempo. Si nunca ves la petición websocket, enfoca el proxy/navegador y el soporte de WebSocket.

Tarea 5: Valida la sincronización horaria (a los tickets les encanta fallar por relojes mal sincronizados)

cr0x@server:~$ timedatectl
               Local time: Fri 2025-12-26 11:19:55 UTC
           Universal time: Fri 2025-12-26 11:19:55 UTC
                 RTC time: Fri 2025-12-26 11:19:55
                Time zone: Etc/UTC (UTC, +0000)
System clock synchronized: yes
              NTP service: active
          RTC in local TZ: no

Decisión: Si System clock synchronized es no o NTP está inactivo, arréglalo. Los tickets de consola son de corta duración; la deriva rompe todo de formas que parecen “flakiness” aleatoria.

Tarea 6: Revisa las direcciones de nodo que el clúster anuncia a la UI

cr0x@server:~$ pvecm nodes
Membership information
----------------------
    Nodeid      Votes Name
         1          1 pve1 (local)
         2          1 pve2

cr0x@server:~$ grep -R "^\s*address" /etc/pve/corosync.conf
        address: 10.10.20.11
        address: 10.10.20.12

Decisión: Si esas direcciones no son alcanzables desde la red de tu navegador (por ejemplo, están en una VLAN de almacenamiento o en una red privada de replicación), las consolas fallarán cuando la UI intente alcanzar la interfaz “incorrecta”. Arregla la estrategia de direccionamiento (enrutamiento o usando la IP correcta del nodo para acceso de gestión).

Tarea 7: Prueba la alcanzabilidad al puerto 8006 desde una red cliente

cr0x@server:~$ nc -vz 10.10.20.11 8006
Connection to 10.10.20.11 8006 port [tcp/*] succeeded!

Decisión: Si falla, deja de culpar a Proxmox. Eso es enrutamiento/firewall/security group. Arregla la alcanzabilidad de red primero; noVNC no puede teletransportarse a través de TCP bloqueado.

Tarea 8: Comprueba el estado y reglas del firewall de Proxmox

cr0x@server:~$ pve-firewall status
Status: enabled/running

cr0x@server:~$ iptables -S | head -n 25
-P INPUT ACCEPT
-P FORWARD ACCEPT
-P OUTPUT ACCEPT
-N PVEFW-FORWARD
-N PVEFW-INPUT
-A INPUT -j PVEFW-INPUT
-A FORWARD -j PVEFW-FORWARD

Decisión: Si el firewall está activado, verifica que permites 8006/tcp desde tus redes de administración. Si ejecutas un firewall estricto en host más un firewall upstream, asegúrate de que ambos coincidan. “Defensa en profundidad” es genial hasta que ambas capas discrepan sobre quién puede hacer clic en Console.

Tarea 9: Confirma que la actualización WebSocket funciona en la capa HTTP (lado nodo)

cr0x@server:~$ curl -k -I https://127.0.0.1:8006/
HTTP/1.1 200 OK
server: pve-api-daemon/3.0
content-type: text/html; charset=UTF-8
content-length: 1783

Decisión: Si esto falla incluso localmente, tienes un proxy o una pila TLS rota. Arregla servicios/nodos/certs. Si local funciona pero remoto no, es red o proxy delante.

Tarea 10: Recrea la petición VNC proxy vía API (ruta de auth y ticket)

cr0x@server:~$ pvesh create /nodes/pve1/qemu/101/vncproxy --websocket 1
port: 5901
ticket: PVEVNC:root@pam:6760E0C2::vO3o2oZ...
user: root@pam

Decisión: Si este comando da error (permiso denegado, bloqueo de config del clúster, timeout), tu problema no es “el navegador”. Es API/auth/backend. Si devuelve un ticket y puerto, entonces el lado servidor puede generar una sesión de consola; tu fallo probablemente sea transporte WebSocket o política del cliente.

Tarea 11: Comprueba que QEMU está en ejecución y no está bloqueado

cr0x@server:~$ qm status 101
status: running

cr0x@server:~$ ps -o pid,cmd -C kvm | head -n 3
  PID CMD
 2417 /usr/bin/kvm -id 101 -name vm101 -no-shutdown ...

Decisión: Si la VM está “running” pero no hay proceso QEMU (raro, pero he visto desincronización del estado de gestión), reconcilia con qm stop/qm start. Si QEMU está presente pero la consola aún falla, céntrate en proxying/tickets/firewall.

Tarea 12: Inspecciona la configuración de pantalla de la VM (¿VNC/SPICE habilitado?)

cr0x@server:~$ qm config 101 | egrep '^(vga|spice|serial|args)'
vga: std
serial0: socket

Decisión: Si has deshabilitado la salida VGA (por ejemplo con ciertas configuraciones de passthrough GPU) y no tienes una consola serial configurada, la “consola” puede aparecer en blanco. Añade un dispositivo serial y usa la consola serial para sistemas sin cabeza.

Tarea 13: Encuentra fallos de auth/ticket en los logs de daemon

cr0x@server:~$ journalctl -u pvedaemon -S -2h --no-pager | egrep -i "ticket|auth|permission|vnc|spice" | tail -n 20
Dec 26 11:18:09 pve1 pvedaemon[1203]: authentication successful: user root@pam
Dec 26 11:18:09 pve1 pvedaemon[1203]: VM 101: start vnc proxy

Decisión: Si ves “authentication failed” o errores de ticket, comprueba la sincronización horaria y el realm de usuario, y confirma que tu navegador no esté cacheando sesiones antiguas entre nodos.

Tarea 14: Si usas un reverse proxy, verifica que realmente está encaminando WebSockets

cr0x@server:~$ nginx -T 2>/dev/null | egrep -n "proxy_set_header (Upgrade|Connection)|proxy_http_version" | head -n 40
123:    proxy_http_version 1.1;
124:    proxy_set_header Upgrade $http_upgrade;
125:    proxy_set_header Connection "upgrade";

Decisión: Si estas cabeceras no están presentes para el bloque de la ubicación PVE, noVNC a menudo colgará o fallará con un error de WebSocket. Arregla la configuración del reverse proxy o deja de usarlo para las rutas de consola.

Tarea 15: Comprueba problemas de MTU/ruta cuando los WebSockets conectan y luego se congelan

cr0x@server:~$ ping -M do -s 1472 10.10.20.55 -c 3
PING 10.10.20.55 (10.10.20.55) 1472(1500) bytes of data.
1472 bytes from 10.10.20.55: icmp_seq=1 ttl=63 time=0.518 ms
1472 bytes from 10.10.20.55: icmp_seq=2 ttl=63 time=0.511 ms
1472 bytes from 10.10.20.55: icmp_seq=3 ttl=63 time=0.527 ms

Decisión: Si ves “Frag needed” o pérdida solo en paquetes grandes, sospecha desajuste de MTU (común con VLANs, túneles u overlays). Los WebSockets pueden “conectar” y luego comportarse como poseídos bajo problemas de MTU. Arregla el MTU; no lo tapes con timeouts.

Tarea 16: Valida DNS y coincidencia de nombres en certificados (especialmente en clústeres)

cr0x@server:~$ hostname -f
pve1.example.internal

cr0x@server:~$ openssl s_client -connect 127.0.0.1:8006 -servername pve1.example.internal 

cr0x@server:~$ openssl x509 -noout -subject -issuer -in /etc/pve/local/pve-ssl.pem
subject=CN = pve1.example.internal
issuer=CN = Proxmox VE

Decisión: Si la UI se accede vía un nombre que no coincide con el CN/SAN del certificado, los navegadores pueden bloquear o degradar el comportamiento de WebSocket según la política y las interacciones del usuario. Alinea la URL de acceso con los nombres del certificado, o despliega certificados correctos en todo el clúster.

Mapa de fallos: síntomas a puntos de ruptura

La consola es una máquina de Rube Goldberg con menos palancas de las que parece. Mapea lo que ves al lugar donde se rompió la cadena:

Síntoma: “Failed to connect to server (code: 1006)” o “WebSocket connection failed”

• Punto probable de ruptura: WebSocket bloqueado o no actualizado (upgrade).
• Mira en: configuración de reverse proxy, comportamiento del WAF, pestaña Network en devtools del navegador, pveproxy/access.log (ausencia del 101).
• Dirección de la solución: asegúrate de las cabeceras Upgrade/Connection, HTTP/1.1 y conexiones de larga duración. Si puedes, evita el reverse proxy para endpoints de consola.

Síntoma: la pestaña de consola se abre pero permanece negra/en blanco

• Punto probable de ruptura: el backend de pantalla está en blanco (sin VGA), o la pantalla de QEMU está mal configurada; a veces las configuraciones de passthrough GPU eliminan la salida VGA emulada.
• Mira en: qm config para vga/serial, el SO invitado esperando una pantalla primaria diferente.
• Dirección de la solución: añade consola serial, configura un dispositivo VGA sensato para depuración, o asegura que el invitado envíe salida a la consola correcta.

Síntoma: funciona en un nodo, falla en otro

• Punto probable de ruptura: firewall por nodo, mismatch por nodo en DNS/certificados, o el clúster anuncia una interfaz que no es alcanzable desde tu red de administración.
• Mira en: direcciones de corosync, enrutamiento, estado de pveproxy en el nodo que falla.
• Dirección de la solución: estandariza la red de gestión, unifica certificados, deja de mezclar “IP de almacenamiento” como “IP de gestión”.

Síntoma: SPICE descarga un .vv pero virt-viewer no puede conectar

• Punto probable de ruptura: el cliente no puede alcanzar el host/puerto del .vv, o confianza TLS/certificados, o dirección anunciada errónea del host.
• Mira en: el contenido del .vv (host, port), firewall, NAT hairpin y direcciones de nodo.
• Dirección de la solución: asegúrate de que el .vv apunte a una dirección alcanzable; si está detrás de NAT, arregla enrutamiento o usa un VIP alcanzable con proxy adecuado.

Síntoma: la consola funciona y luego se cae aleatoriamente tras uno o dos minutos

• Punto probable de ruptura: timeout inactivo en reverse proxy o load balancer, o problemas de MTU/fragmentación en el camino, o expiración agresiva del seguimiento de estado TCP en un firewall.
• Mira en: timeouts del proxy, configuración conntrack del firewall, pérdida de paquetes, tests de MTU.
• Dirección de la solución: aumenta timeouts, permite WebSockets de larga duración, arregla MTU, deja de “proteger” matando sesiones inactivas a los 60 segundos.

Errores comunes (síntoma → causa raíz → solución)

1) Spinner infinito en noVNC

Síntoma: la ventana de la consola se abre y el spinner nunca termina. Sin error evidente.

Causa raíz: el reverse proxy no soporta o no está configurado para la actualización (upgrade) de WebSocket en la ruta de consola.

Solución: añade las cabeceras de upgrade de WebSocket y HTTP/1.1 en el proxy, o evita el proxy para :8006. Valida comprobando un 101 en /var/log/pveproxy/access.log.

2) “401 Unauthorized” en vncwebsocket

Síntoma: devtools del navegador muestra que la petición websocket devuelve 401/403.

Causa raíz: ticket inválido/expirado, a menudo por deriva de reloj entre nodos, o sesiones persistentes (sticky) que fallan a través de un balanceador de carga.

Solución: arregla NTP en todos lados. Evita balancear la UI de PVE a menos que entiendas afinidad de sesión y alcance del ticket; usar un VIP de un solo nodo con backend consistente es más seguro.

3) La consola solo funciona desde la LAN

Síntoma: en tu mesa funciona; desde VPN o red remota falla.

Causa raíz: las direcciones de nodo anunciadas están en una interfaz no enrutable; o el firewall upstream solo permite 8006 desde una subred.

Solución: enruta correctamente a la red de mgmt o usa una interfaz de gestión alcanzable desde todas las redes de administración. Confirma con pvecm nodes y pruebas de alcanzabilidad.

4) SPICE se descarga, el cliente se conecta a la IP equivocada

Síntoma: virt-viewer intenta conectar a una dirección de VLAN de almacenamiento que no puedes alcanzar.

Causa raíz: el host piensa que su “dirección principal” es la interfaz equivocada (común con nodos multi-NIC y DNS descuidado).

Solución: corrige la resolución de hostname del nodo a la IP de gestión y mantén la gestión del clúster consistente. No dependas de “lo que devuelva DNS primero”.

5) La consola funcionaba y dejó de hacerlo tras una actualización

Síntoma: la UI aún carga; la consola ahora falla con problemas TLS o mixed-content.

Causa raíz: los navegadores endurecieron el manejo de TLS/WebSocket; tu proxy o certificados ya eran cuestionables y la actualización eliminó la última tolerancia.

Solución: arregla certificados correctamente, alinea nombres, deja de terminar TLS dos veces salvo que tengas una razón sólida, y prueba consolas con navegadores modernos como parte de la validación de la actualización.

6) Consola en blanco en VMs con passthrough GPU

Síntoma: la VM es accesible por red, pero la consola siempre está negra.

Causa raíz: la salida del invitado está en la GPU pasada; la VGA emulada no muestra nada.

Solución: añade una consola serial para acceso de emergencia y úsala para diagnósticos de arranque. No esperes que VNC muestre la salida de una GPU sin cabeza.

7) Las consolas fallan solo en un navegador

Síntoma: funciona en Firefox, falla en Chrome (o viceversa).

Causa raíz: extensión/comportamiento del WAF, caché HSTS/decisiones TLS antiguas, o reglas de contenido mixto más estrictas.

Solución: prueba en incógnito sin extensiones; compara errores en devtools. Si el navegador se queja de la confianza del certificado, arregla el certificado; no acostumbres al personal a hacer clic en advertencias eternamente.

Tres micro-historias corporativas desde el terreno

Micro-historia 1: El incidente causado por una suposición equivocada

Una empresa ejecutaba un pequeño clúster Proxmox para servicios internos. Nada sofisticado: un par de docenas de VMs, unos contenedores y una red de almacenamiento separada porque alguien oyó que “el tráfico de almacenamiento nunca debe compartir gestión”. Bien.

Durante una ventana de mantenimiento rutinaria, un nodo se reinició y volvió. La UI parecía saludable. Las VMs estaban en ejecución. Pero la consola de cualquier VM en ese nodo no se abría desde la red de administración. El equipo de operaciones supuso que el stack de pantalla de la VM se había roto tras el reinicio y comenzaron a tocar la configuración de QEMU. Estaban a unos 30 minutos de empeorarlo.

El problema real fue una suposición incrustada en el plan de red: que la UI de gestión siempre hablaría por la interfaz correcta. En la práctica, el hostname del nodo resolvía a la IP de la VLAN de almacenamiento porque DNS se había “actualizado amablemente” durante una limpieza de red anterior. Proxmox anunciaba esa dirección a la UI para conexiones de consola, así que los navegadores intentaban abrir WebSockets a una subred inalcanzable.

La solución fue aburrida: corregir DNS para los nombres de los nodos hacia las IP de gestión y mantener la red de almacenamiento fuera de la identidad de gestión. Las consolas volvieron al instante. El equipo escribió una regla: “Si no es alcanzable desde las redes de administración, no puede ser la dirección de identidad del nodo”.

Micro-historia 2: La optimización que salió mal

Otra organización puso Proxmox detrás de un reverse proxy corporativo. El objetivo declarado era estandarizar seguridad: un punto de entrada, una política TLS, un lugar para aplicar SSO. El equipo de proxy afinó timeouts agresivamente para “proteger la plataforma” de conexiones de larga duración. También activaron un perfil WAF que era excelente bloqueando tráfico sospechoso. También era excelente bloqueando WebSockets.

La UI cargaba bien. Eso fue suficiente para declarar el cambio exitoso. Luego llegó el siguiente incidente: una actualización fallida dejó una VM inarrancable y el ingeniero on-call necesitó acceso a la consola. La consola giró eternamente. Un segundo ingeniero probó SPICE. Mismo resultado: la descarga funcionó, la conexión falló. La “optimización” del proxy había eliminado efectivamente la vía de acceso fuera de banda.

La depuración fue predeciblemente política. El equipo de proxy dijo que Proxmox estaba roto. El equipo de virtualización dijo que el proxy estaba roto. Ambos tenían media razón: Proxmox necesita upgrades limpios de WebSocket y el proxy había sido configurado como si todo fueran llamadas REST sin estado.

La resolución final: evitar el proxy para :8006 desde las redes de administración, mantener SSO para la UI donde tuviera sentido, y permitir explícitamente Upgrade de WebSocket y timeouts largos en las rutas de consola. Todos aprendieron la misma lección con palabras diferentes: no todo debe “optimizarse” en uniformidad.

Micro-historia 3: La práctica aburrida pero correcta que salvó el día

Un equipo de servicios financieros tenía un proceso de cambios estricto que hacía que los ingenieros rodaran los ojos. Tenían una checklist pre-actualización: validar sincronización horaria entre nodos, verificar certificados, abrir consola en cada nodo y ejecutar un escaneo rápido de alcanzabilidad desde la subred de administración. No era glamoroso. Tampoco falló a las 2 a.m.

Durante un ciclo de actualización de Proxmox, un paso de renovación de certificados falló en un nodo por un problema de permisos. La UI aún arrancó, lo que hubiese enmascarado el defecto. Pero la checklist incluía “abrir una consola noVNC en una VM de prueba en cada nodo”, y la consola de ese nodo falló inmediatamente con un error relacionado con TLS.

Puesto que la falla fue detectada antes del horario de producción, el equipo tuvo tiempo de arreglarlo correctamente: corregir permisos en los archivos de certificado y reiniciar pveproxy. No se perdió acceso de emergencia y la actualización siguió sin dramas.

La moraleja no es solo “las checklists son buenas” en abstracto. La moraleja es que el acceso a consola forma parte de tus herramientas de recuperación. Lo pruebas con la misma seriedad que restaurar backups, porque solo lo necesitas cuando todo lo demás está en llamas.

Listas de verificación / plan paso a paso

Paso a paso: cuando una consola no se abre ahora mismo

1. Evita la complejidad: accede al nodo directamente en https://NODE:8006 (no a través de reverse proxy, ni VIP de clúster) y prueba la consola.
2. Evidencia del navegador: abre DevTools → Network, filtra “websocket”, reproduce. Anota códigos de estado (101 vs 4xx/5xx) y errores.
3. Evidencia del nodo: tail /var/log/pveproxy/access.log mientras haces clic en Console. Quieres ver vncproxy 200 y vncwebsocket 101.
4. Salud de servicios: confirma que pveproxy está en ejecución y escuchando en 8006.
5. Alcanzabilidad: desde tu red de administración, confirma TCP/8006 al nodo. Si no puedes conectar, detente y arregla la red.
6. Tickets/auth: ejecuta pvesh create ... vncproxy en el nodo para confirmar que la generación de tickets funciona.
7. Sincronización horaria: verifica NTP y sincronización entre nodos. Arregla la deriva antes de perseguir fantasmas.
8. Backend de la VM: comprueba qm config por configuración de display/serial; confirma que el proceso QEMU existe.
9. Capa proxy (si se usa): valida cabeceras Upgrade de WebSocket y timeouts.
10. MTU/pérdida de paquetes: si conecta y luego se cae, prueba MTU y revisa conntrack/timeouts del firewall.

Paso a paso: endurecimiento para que esto no vuelva a pasar

1. Estandariza direccionamiento de gestión: cada nombre de nodo resuelve a una IP de gestión alcanzable desde redes de administración. Sin excepciones “solo para almacenamiento”.
2. Política de sincronización de tiempo: NTP obligatorio en todos los nodos; alerta por deriva. Las sesiones con tickets dependen de ello.
3. Higiene de certificados: usa certificados correctos con nombres apropiados; renueva de forma segura; prueba después de la renovación.
4. Regla de reverse proxy: si debes proxyar, soporta explícitamente WebSockets y timeouts largos para rutas de consola. Si no, no proxyes consolas.
5. Acceso de emergencia: configura consolas seriales para VMs críticas, especialmente las con passthrough GPU o configuraciones headless.
6. Validación en actualizaciones: incluye pruebas de apertura de consola en cada nodo como parte del control de cambios.

Segundo chiste, porque nos lo hemos ganado: la forma más rápida de descubrir que tu reverse proxy no soporta WebSockets es necesitarlo durante un incidente.

Datos interesantes y breve historia (las partes que vale la pena conocer)

• WebSockets se estandarizaron a principios de los 2010, y mucha infraestructura HTTP “enterprise” aún los trata como un invitado no deseado en una cena formal.
• noVNC existe porque “instalar un cliente” no es una opción en muchos entornos. Los navegadores ganaron esa batalla, y los equipos de operaciones heredaron las consecuencias de proxies/cabeceras.
• SPICE fue diseñado para ser más que píxeles: audio, portapapeles, resolución dinámica y mejor UX remoto que VNC clásico cuando se usa de extremo a extremo.
• Las consolas de Proxmox dependen de tickets de corta duración por buenas razones: reducen el radio de daño de URLs robadas y limitan la reutilización accidental de sesiones.
• La deriva de reloj rompe la autenticación de formas no obvias, especialmente para sistemas que emiten tokens con tiempo. Los tickets de consola son un ejemplo práctico, no teórico.
• Los navegadores han endurecido reglas TLS y mixed-content. Las configuraciones de certificados que antes “funcionaban” son cada vez menos toleradas, especialmente con WebSockets.
• Los sistemas clusterizados suelen tener múltiples redes (mgmt, almacenamiento, replicación). Mezclar selección de identidad/dirección entre ellas es una fuente clásica de “la UI funciona, la consola no”.
• VNC es antiguo pero sorprendentemente útil. Su simplicidad facilita el proxy; su simplicidad también hace fácil que se asegure mal si lo expones directamente.

Preguntas frecuentes (FAQ)

¿Por qué carga la UI de Proxmox pero falla la consola?

Porque cargar la UI es solo HTTPS hacia el puerto 8006. La consola añade una actualización a WebSocket (noVNC) o una conexión de cliente separada (SPICE) más un ticket de corta duración. Más eslabones, más maneras de fallar.

¿Qué log debería revisar primero en el nodo?

/var/log/pveproxy/access.log. Te dice si la petición websocket llegó y si se actualizó (101). Es la fuente de verdad más rápida.

¿Qué significa HTTP 101 en el access log?

Significa que la actualización a WebSocket tuvo éxito. Si ves vncwebsocket con 101, el proxy y el navegador negociaron WebSockets. Si aún no obtienes consola, céntrate en el backend VM, MTU o renderizado del cliente.

¿Por qué los reverse proxies rompen noVNC tan a menudo?

Porque suelen configurarse para peticiones HTTP de corta duración y pueden omitir las cabeceras de actualización de WebSocket, forzar rutas solo HTTP/2, terminar TLS de formas que confunden upstream o matar conexiones inactivas.

¿Puedo “abrir el puerto VNC” directamente en vez de usar noVNC?

Puedes, pero normalmente no deberías. Amplía tu superficie de ataque y complica reglas de firewall. El proxy de consola de Proxmox existe para evitar exponer puertos VNC/SPICE ampliamente y para ligar el acceso a tickets autenticados.

¿Por qué falla solo en algunos nodos del clúster?

Configuración inconsistente por nodo: reglas de firewall distintas, certificados distintos, resolución DNS distinta o un nodo que anuncia una dirección no alcanzable desde tu red de administración.

¿Cómo se relaciona la sincronización horaria con las consolas?

Los tickets de consola tienen alcance temporal. Si el tiempo del nodo está lo suficiente desajustado, los tickets se validan como expirados o no aún válidos. El resultado es comportamiento intermitente 401/403 que parece “flakiness” del navegador.

Mi consola conecta y luego se cae tras ~60 segundos. ¿Cuál es la causa habitual?

Un timeout inactivo en el proxy/load balancer o un timeout de estado del firewall en conexiones de larga duración. En segundo lugar: desajuste de MTU causando paradas extrañas bajo carga. Arregla timeouts y MTU; no lo “arregles” pidiendo a los ingenieros que se reconecten continuamente.

SPICE no conecta pero noVNC funciona. ¿Por qué?

Ruta de cliente diferente. SPICE usa una aplicación cliente y una pila de protocolo distinta; es más sensible a la alcanzabilidad y a la confianza TLS en los endpoints listados en el .vv. noVNC aprovecha lo que el navegador puede alcanzar.

noVNC funciona directo al nodo, pero falla a través de nuestra URL corporativa. ¿Ahora qué?

Deja de depurar Proxmox y empieza a depurar el proxy. Asegura que WebSockets están permitidos, que se incluyen las cabeceras de upgrade, que los timeouts son suficientes y que ninguna regla WAF bloquea las rutas websocket.

¿Cuál es la opción de “break-glass” más limpia para VMs Linux sin cabeza?

Consola serial. Configura serial0: socket en la VM, asegura que el invitado tenga un getty/kernel console serial configurado y usa la consola serial de Proxmox cuando la VGA sea poco fiable.

Conclusión: siguientes acciones que funcionan

Cuando las consolas de Proxmox no se abren, trátalo como una cadena de conectividad/autenticación, no como un fallo de UI. Tu señal más rápida es si vncwebsocket llega a pveproxy y se actualiza a 101. A partir de ahí, el triage es directo: alcanzabilidad de red, proxy compatible con WebSocket, sincronización horaria para tickets y direccionamiento de identidad de nodos sensato.

Siguientes pasos que valen la pena:

• Añade “abrir consola en cada nodo” a tus comprobaciones de actualización y renovación de certificados.
• Estandariza DNS de nodos e interfaces de gestión para que las consolas no redirijan a redes inalcanzables.
• Toma una decisión consciente sobre reverse proxies: o los configuras correctamente para WebSockets y timeouts, o los evitas para acceso de administración.
• Habilita consolas seriales en VMs críticas para no quedarte bloqueado cuando la salida VGA no exista o esté mal dirigida.

Si haces esas cuatro cosas, las fallas de consola se convierten en el tipo raro de problema: aburrido, diagnosticable y breve.