La interfaz web de Proxmox no se abre en el puerto 8006: reinicia pveproxy y recupera el acceso

Guía de diagnóstico rápido

Cuando el puerto 8006 está muerto, buscas un cuello de botella, no impresiones. El camino más rápido es responder tres preguntas, en orden:

1) ¿Algo está escuchando en 8006?

Si nada escucha, normalmente pveproxy se detuvo, quedó bloqueado, falló al enlazar o falló en la inicialización TLS. Si algo escucha pero no puedes conectar, suele ser un problema de firewall/ruteo/VRF/interfaz/IP.

2) Si pveproxy está caído, ¿por qué?

No reinicies a ciegas un servicio que entra en bucle de fallos: obtén la razón de systemctl y journalctl. Los culpables habituales son:

• Problemas con certificados/clave
• Disco lleno (especialmente en root)
• Problemas con el sistema de archivos de clúster (pmxcfs)
• Agotamiento de descriptores de archivo o presión de memoria
• Conflictos de puerto o mala configuración de la dirección de bind

3) Si pveproxy está activo, ¿por qué no puede conectarse el navegador?

Ahora comprueba la conectividad local primero (curl desde el host), luego remota (desde otro nodo o estación de trabajo), y después el firewall y la ruta de red. La interfaz web es simplemente HTTPS en 8006. Trátala como cualquier otro servicio HTTPS.

Una cita operativa que envejeció bien: “La esperanza no es una estrategia.” — Simon Sinek. No es literatura de confiabilidad, pero debería estar en cada rotación de on-call.

Qué es realmente el puerto 8006 (y qué no es)

La interfaz web de Proxmox VE la sirve pveproxy, un proxy HTTP(S) que habla con demonios de backend (pvedaemon, pvestatd y compañeros) y lee el estado del clúster vía pmxcfs. Si pierdes la UI pero las VMs siguen funcionando, eso es normal: el hipervisor y los invitados pueden continuar mientras fallan componentes de gestión.

El puerto 8006 no es “el servidor Proxmox”. Es el plano de gestión. Trátalo como tal. Puedes repararlo sin tocar VMs en ejecución si evitas acciones contundentes (como reiniciar el host en medio de un scrub de almacenamiento o una reelección del clúster).

Broma corta #1: Que la UI de Proxmox deje de funcionar es como si se apagara la radio del coche: el motor sigue en marcha, pero de repente todos en el vehículo son ingenieros de almacenamiento.

Datos interesantes y contexto histórico (porque el contexto evita errores tontos)

• El puerto 8006 es una convención de Proxmox, no un estándar universal. Proxmox lo eligió años atrás para evitar conflictos con puertos web típicos y para que “eso es Proxmox” sea reconocible al instante.
• pveproxy usa TLS por defecto, incluso en redes internas. Fue una decisión pragmática de seguridad: los planos de gestión se atacan, incluso cuando piensas “solo es interno”.
• El sistema de archivos de clúster de Proxmox (pmxcfs) es un sistema de archivos en espacio de usuario (FUSE) respaldado por Corosync. Cuando se comporta mal, las herramientas de gestión pueden quedar extrañamente rotas mientras los invitados permanecen bien.
• Históricamente, muchas caídas de la UI son fallos “indirectos”: disco lleno, sincronización de hora rota o certificados caducados. La UI es donde lo notas, no donde empezó.
• Systemd cambió la operativa para servicios como pveproxy: la razón real del fallo casi siempre está en el journal, no en una salida vaga de un script de init.
• Regenerar certificados TLS es rutinario en Proxmox. La plataforma asume que los certificados pueden reemplazarse localmente; está diseñada tanto para appliances y laboratorios como para empresas.
• La disponibilidad de las VMs puede engañarte. KVM y QEMU no se ven afectados por que pveproxy esté caído, lo cual es genial para cargas y terrible para la complacencia.
• Las interrupciones en 8006 suelen ser autoinfligidas: endurecimiento del firewall, scripts de “limpieza” o reglas de prevención de intrusiones demasiado agresivas que no probaron el tráfico de gestión.

Tareas prácticas: comandos, salida esperada y qué decisión tomar

Estas son tareas reales que ejecutaría en un host que está “arriba” pero con la UI muerta. Cada una incluye qué significa la salida y qué haces a continuación. Ejecuta los comandos como root (o con sudo). El prompt mostrado es ilustrativo.

Task 1: Confirmar accesibilidad básica del host e IP

cr0x@server:~$ ip -br a
lo               UNKNOWN        127.0.0.1/8 ::1/128
eno1             UP             10.10.20.11/24 fe80::a00:27ff:fe12:3456/64
vmbr0            UP             10.10.20.11/24 fe80::a00:27ff:fe12:3456/64

Significado: Tienes una IP, las interfaces están arriba y sabes en qué dirección debería estar la UI.

Decisión: Si no hay la IP esperada (o está en la VLAN equivocada), arregla la red primero. Si la IP está bien, continúa.

Task 2: Comprobar si algo escucha en TCP/8006

cr0x@server:~$ ss -lntp | grep ':8006'
LISTEN 0      4096         0.0.0.0:8006      0.0.0.0:*    users:(("pveproxy",pid=2143,fd=6))

Significado: pveproxy está escuchando en todas las direcciones IPv4.

Decisión: Si no obtienes salida, pveproxy no está escuchando. Ve al estado del servicio y a los logs. Si solo escucha en 127.0.0.1:8006, tienes un problema de bind.

Task 3: Verificar que HTTPS local funciona desde el host

cr0x@server:~$ curl -kI 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: 1791

Significado: El servicio web responde localmente. La falla en el navegador podría ser red/firewall/DNS/ruta, no pveproxy.

Decisión: Si curl local falla con “connection refused”, céntrate en pveproxy. Si funciona, prueba desde otra máquina y revisa el firewall.

Task 4: Revisar el estado en systemd de pveproxy

cr0x@server:~$ systemctl status pveproxy --no-pager
● pveproxy.service - PVE API Proxy Server
     Loaded: loaded (/lib/systemd/system/pveproxy.service; enabled)
     Active: failed (Result: exit-code) since Wed 2025-12-24 09:12:17 UTC; 2min 8s ago
    Process: 2012 ExecStart=/usr/bin/pveproxy start (code=exited, status=1/FAILURE)
   Main PID: 2012 (code=exited, status=1/FAILURE)

Dec 24 09:12:17 server pveproxy[2012]: can't load certificate '/etc/pve/local/pve-ssl.pem'
Dec 24 09:12:17 server systemd[1]: pveproxy.service: Main process exited, code=exited, status=1/FAILURE
Dec 24 09:12:17 server systemd[1]: pveproxy.service: Failed with result 'exit-code'.

Significado: pveproxy falla por un error al cargar el certificado TLS.

Decisión: Repara los certificados (ver sección posterior). Si el estado muestra “active (running)”, ve al firewall/red. Si aparece “activating” eternamente, revisa dependencias (pmxcfs, pvedaemon) y presión de recursos.

Task 5: Leer el journal para los detalles del último fallo

cr0x@server:~$ journalctl -u pveproxy -n 100 --no-pager
Dec 24 09:12:17 server pveproxy[2012]: starting server
Dec 24 09:12:17 server pveproxy[2012]: can't load certificate '/etc/pve/local/pve-ssl.pem'
Dec 24 09:12:17 server pveproxy[2012]: Unable to load local private key
Dec 24 09:12:17 server systemd[1]: pveproxy.service: Main process exited, code=exited, status=1/FAILURE

Significado: El registro da una causa raíz accionable, no solo “failed”.

Decisión: Arregla lo que indique el log. No reinicies en bucle y finjas progreso.

Task 6: Confirmar que pvedaemon está sano (API de backend)

cr0x@server:~$ systemctl status pvedaemon --no-pager
● pvedaemon.service - PVE API Daemon
     Loaded: loaded (/lib/systemd/system/pvedaemon.service; enabled)
     Active: active (running) since Wed 2025-12-24 06:01:10 UTC; 3h 13min ago
   Main PID: 1122 (pvedaemon)
      Tasks: 6 (limit: 154000)
     Memory: 62.4M
        CPU: 2min 19s

Significado: El backend está en ejecución.

Decisión: Si pvedaemon está caído, reinícialo y revisa su journal; pveproxy a veces falla porque su upstream está unhealthy.

Task 7: Confirmar que pmxcfs está montado y responde

cr0x@server:~$ mount | grep pmxcfs
pmxcfs on /etc/pve type fuse.pmxcfs (rw,nosuid,nodev,relatime,user_id=0,group_id=0,default_permissions,allow_other)

Significado: El sistema de archivos de clúster está montado en /etc/pve.

Decisión: Si falta, muchas herramientas de gestión de Proxmox fallarán. Necesitarás restaurar pve-cluster y la salud de corosync.

Task 8: Comprobar espacio en disco (root lleno es un asesino silencioso)

cr0x@server:~$ df -h /
Filesystem      Size  Used Avail Use% Mounted on
/dev/sda2        30G   30G     0 100% /

Significado: El filesystem root está lleno. Los servicios fallan de formas extrañas: no se pueden escribir logs, fallan escrituras de certificados, fallan sockets.

Decisión: Libera espacio inmediatamente (logs, kernels antiguos con precaución, cache). Luego reinicia servicios. No “simplemente reinicies”. Un reinicio con root lleno no cura; es negación con uptime.

Task 9: Comprobar si el puerto está bloqueado por reglas de firewall locales

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

cr0x@server:~$ pve-firewall localnet
Local network: 10.10.20.0/24

Significado: El firewall de Proxmox está habilitado y tiene definida una red local.

Decisión: Si el firewall está habilitado, inspecciona reglas y confirma que 8006 esté permitido desde tu subred de gestión.

Task 10: Inspeccionar iptables/nftables por drops en 8006

cr0x@server:~$ nft list ruleset | grep -n '8006' | head
128: tcp dport 8006 drop

Significado: Hay un drop explícito en 8006.

Decisión: Elimina u overridea esa regla correctamente (idealmente via la configuración del firewall de Proxmox, no con cirugía aleatoria en cli). Si no pretendías bloquearlo, busca quién lo hizo.

Task 11: Probar conectividad remota desde otro host (comprobación de ruta de red)

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

Significado: El handshake TCP funciona. Si el navegador sigue fallando, mira TLS/advertencias de certificado, un proxy o problemas del cliente.

Decisión: Si falla, aísla dónde: host local funciona pero remoto no → firewall o ruteo. Local falla también → pveproxy caído o problema de bind.

Task 12: Comprobar conflictos de puerto

cr0x@server:~$ ss -lntp | awk '$4 ~ /:8006$/ {print}'
LISTEN 0 128 0.0.0.0:8006 0.0.0.0:* users:(("nginx",pid=1888,fd=12))

Significado: Algo más (nginx aquí) ocupa 8006. pveproxy no puede bindear y fallará.

Decisión: Para o reconfigura el servicio en conflicto. Proxmox posee 8006 en una instalación por defecto. No lo discutas si no disfrutas el dolor.

Task 13: Validar que los archivos TLS existan y sean legibles

cr0x@server:~$ ls -l /etc/pve/local/pve-ssl.pem /etc/pve/local/pve-ssl.key
-rw-r----- 1 root www-data 3456 Dec 24 09:10 /etc/pve/local/pve-ssl.pem
-rw-r----- 1 root www-data 1704 Dec 24 09:10 /etc/pve/local/pve-ssl.key

Significado: Los archivos existen con permisos razonables (legibles por el grupo www-data que usa pveproxy).

Decisión: Si los permisos están mal (escritura global, faltan, grupo equivocado), arréglalos o regenera certificados.

Task 14: Comprobar sincronización horaria (la validez de certificados y handshakes TLS puede romperse)

cr0x@server:~$ timedatectl
               Local time: Wed 2025-12-24 09:15:33 UTC
           Universal time: Wed 2025-12-24 09:15:33 UTC
                 RTC time: Wed 2025-12-24 09:15:32
                Time zone: Etc/UTC (UTC, +0000)
System clock synchronized: no
              NTP service: inactive
          RTC in local TZ: no

Significado: La hora no está sincronizada; NTP está inactivo.

Decisión: Arregla la sincronización horaria. La hora incorrecta puede hacer que los certificados aparezcan “aún no válidos” o “caducados” y provocar errores confusos en clientes.

Reiniciar pveproxy (y los servicios de los que depende)

Si pveproxy está caído, reiniciarlo es correcto. Si falla repetidamente, reiniciarlo sin arreglar la causa es teatro. Lo haremos a la manera adulta: verifica dependencias, reinicia en el orden correcto y confirma que el listener vuelva.

El reinicio mínimo seguro

Esta es la acción “necesito la UI ahora” cuando ya sabes que es un crash transitorio, no un fallo grave.

cr0x@server:~$ systemctl restart pveproxy
cr0x@server:~$ systemctl is-active pveproxy
active

Significado: El servicio se reinició y está activo.

Decisión: Verifica inmediatamente que esté escuchando y sirviendo HTTPS, no solo “active” en systemd.

cr0x@server:~$ ss -lntp | grep ':8006'
LISTEN 0      4096         0.0.0.0:8006      0.0.0.0:*    users:(("pveproxy",pid=2299,fd=6))

El reinicio del “plano de gestión” (el orden importa)

Si sospechas un problema más profundo en la pila de gestión—rarezas de pmxcfs, sockets obsoletos, actualizaciones parciales—reinicia los servicios relevantes en un orden sensato. Prefiero esta secuencia en un nodo único:

1. pve-cluster (pmxcfs)
2. pvedaemon
3. pvestatd
4. pveproxy

cr0x@server:~$ systemctl restart pve-cluster
cr0x@server:~$ systemctl restart pvedaemon
cr0x@server:~$ systemctl restart pvestatd
cr0x@server:~$ systemctl restart pveproxy
cr0x@server:~$ systemctl --no-pager --failed
  UNIT          LOAD   ACTIVE SUB    DESCRIPTION
0 loaded units listed.

Significado: Según systemd, nada está actualmente en fallo.

Decisión: Si algo queda fallando, párate y lee el journal de esa unidad. No sigas apilando reinicios como si intentaras sacar un snack atascado de una máquina expendedora.

Cuándo reiniciar corosync (y cuándo no)

En un clúster, reiniciar corosync puede provocar reelección y breve inestabilidad de gestión. Si tu problema está aislado a un nodo, no empieces por corosync. Confirma primero la salud del montaje de /etc/pve. Si pmxcfs está roto porque corosync está bloqueado, entonces sí, quizá debas abordar corosync—pero eso es un paso deliberado.

cr0x@server:~$ systemctl status corosync --no-pager
● corosync.service - Corosync Cluster Engine
     Loaded: loaded (/lib/systemd/system/corosync.service; enabled)
     Active: active (running) since Wed 2025-12-24 06:01:05 UTC; 3h 18min ago

Decisión: Si corosync está caído y este es un nodo de clúster, espera síntomas más amplios (sin quorum, sin actualizaciones en /etc/pve). Trátalo como un incidente de clúster, no solo “la UI está caída”.

Causas profundas: TLS, firewall, pmxcfs, presión de recursos y problemas de bind

Cuando 8006 está muerto, el fallo casi siempre cae en uno de estos cubos. La solución depende del cubo. Lo malo: pueden parecer similares desde un navegador. Lo bueno: Linux te da recibos.

Fallos TLS/certificados: pveproxy no puede arrancar o los clientes lo rechazan

Signos comunes:

• systemctl status pveproxy muestra errores de carga de certificado
• El navegador arroja un error de handshake TLS (no solo una advertencia)
• curl -k falla con problemas de handshake

Regenerar el certificado auto-firmado suele ser seguro y rápido. En un nodo único, haz esto:

cr0x@server:~$ pvecm updatecerts --force
Setting up certificates
done.
Restarting pveproxy and pvedaemon
done.

Significado: Proxmox regeneró certificados y reinició servicios clave.

Decisión: Si tu entorno usa certificados personalizados, no los sobreescribas con --force sin comprobar. Si lo haces, “arreglarás la UI” y romperás cadenas de confianza para automatización y monitorización.

Para comprobar las fechas y el subject del certificado:

cr0x@server:~$ openssl x509 -in /etc/pve/local/pve-ssl.pem -noout -subject -dates
subject=CN = server
notBefore=Dec 24 09:10:00 2025 GMT
notAfter=Dec 23 09:10:00 2035 GMT

Decisión: Si las fechas son incorrectas, arregla la sincronización horaria. Si el archivo no se puede parsear, regenera o restaura el certificado.

Bloqueos de firewall: pveproxy está bien, pero nadie puede alcanzarlo

Aquí es donde los equipos pierden horas porque “el servicio está arriba”. Sí, localmente. La red aún puede arruinarte el día.

Primero, verifica desde el host Proxmox que esté escuchando. Luego comprueba si es alcanzable desde la red cliente. Si está bloqueado, mira reglas del firewall de Proxmox y el nftables/iptables subyacente.

cr0x@server:~$ pve-firewall compile
Compiling firewall ruleset...
done

Significado: Las reglas del firewall se compilaron correctamente. Eso no significa que sean correctas; significa que son sintácticamente válidas.

Decisión: Si la compilación falla, arregla la configuración. Si tiene éxito pero te bloquea, ajusta reglas para tu subred de gestión y permite TCP/8006 explícitamente.

Chequeo rápido de drops mientras intentas conectar:

cr0x@server:~$ journalctl -k -n 50 --no-pager | grep -i drop
Dec 24 09:18:04 server kernel: IN=vmbr0 OUT= MAC=... SRC=10.10.30.50 DST=10.10.20.11 LEN=60 ... DPT=8006 ...

Decisión: Si ves drops del kernel hacia 8006 desde tu IP origen, deja de culpar a pveproxy. Arregla la ruta del firewall.

pmxcfs y rarezas de clúster: /etc/pve es la dependencia oculta

Si /etc/pve no está montado, la gestión de Proxmox se convierte en una casa encantada. pveproxy puede iniciarse pero no leer la configuración esperada; o puede fallar al no encontrar certificados bajo /etc/pve/local.

Comprueba el estado del sistema de archivos del clúster:

cr0x@server:~$ systemctl status pve-cluster --no-pager
● pve-cluster.service - The Proxmox VE cluster filesystem
     Loaded: loaded (/lib/systemd/system/pve-cluster.service; enabled)
     Active: active (running) since Wed 2025-12-24 06:01:03 UTC; 3h 19min ago

Decisión: Si pve-cluster falla, revisa su journal. En un nodo único sin corosync, aún puede funcionar en modo local, pero la corrupción o disco lleno pueden romperlo.

Presión de recursos: memoria, descriptores, CPU steal

Los servicios de gestión son pequeños, pero no mágicos. Si el host está intercambiando, atascado en IO wait o sin descriptores, pveproxy puede iniciarse y luego morir, o no aceptar conexiones correctamente.

cr0x@server:~$ free -h
               total        used        free      shared  buff/cache   available
Mem:            62Gi        60Gi       450Mi       1.2Gi       1.6Gi       620Mi
Swap:           16Gi        15Gi       1.0Gi

Decisión: Si swap está muy usado y la memoria disponible es mínima, estás en un crash en cámara lenta. Reduce carga, detén procesos descontrolados, considera migrar VMs y luego reinicia servicios de gestión.

cr0x@server:~$ ulimit -n
1024

Significado: El límite de archivos abiertos de la shell actual es bajo. Los servicios pueden tener sus propios límites, pero si el sistema está generalmente constreñido, verás fallos extraños.

Decisión: Si sospechas agotamiento de FD, revisa recuentos en /proc y límites del sistema; no aumentes límites sin entender por qué se alcanzaron (a menudo es una fuga o un cliente abusivo).

Problemas de bind: pveproxy escucha solo en localhost o en la interfaz equivocada

A veces pveproxy está arriba, pero ligado de forma que lo hace inaccesible remotamente. Lo verás en la salida de ss.

cr0x@server:~$ ss -lntp | grep ':8006'
LISTEN 0      4096       127.0.0.1:8006      0.0.0.0:*    users:(("pveproxy",pid=2401,fd=6))

Significado: Está escuchando solo en loopback. Clientes remotos nunca conectarán.

Decisión: Busca configuración proxy personalizada o variables de entorno que alteren el bind. En muchos casos viene de alguien que “temporalmente” vinculó servicios a localhost durante pruebas y se olvidó. Los cambios temporales tienen un plan de jubilación: nunca se jubilan.

DNS y problemas del lado del navegador: tu portátil te miente

Si la IP directa funciona pero el nombre de host no, tienes problemas de DNS o split-horizon. Si tu navegador cacheó HSTS o fijó un certificado, puedes obtener errores cliente incluso después de arreglar el servidor. Confirma con curl desde un host neutral y probando por IP.

cr0x@server:~$ getent hosts server
10.10.20.11     server

Decisión: Si el hostname resuelve a la IP equivocada, arregla DNS/hosts y deja de adivinar.

Tres micro-historias del mundo corporativo (anonimizadas, plausibles y dolorosamente familiares)

Micro-historia 1: La caída causada por una suposición equivocada

Tenían un pequeño clúster Proxmox que soportaba herramientas internas: runners de CI, un par de bases de datos y un servidor NFS “temporal” que sobrevivió a tres reorganizaciones. Una mañana, la UI no funcionaba en un nodo. El on-call supuso que era un tropiezo rutinario de pveproxy y reinició pveproxy y pvedaemon.

No cambió nada. Entonces escalaron a “problema de red”, porque podían hacer ping al host pero no cargar la UI. Pasaron una hora mirando puertos de switch, persiguiendo VLAN fantasmas. Mientras tanto, las VMs seguían funcionando, lo que hizo a todos asumir que no era urgente.

La suposición equivocada fue sutil: “Si puedo hacer ping, la UI debería funcionar.” Ping te dice casi nada sobre la alcanzabilidad TCP, drops de firewall o si el servicio escucha en la interfaz correcta. No habían comprobado ss -lntp o curl -kI localmente. Tampoco miraron nftables.

La causa real: un cambio de endurecimiento de seguridad desplegado por automatización añadió una regla nftables para dropear 8006 desde “redes no administrativas”. La definición de red administrativa estaba mal por una subred. Las pruebas locales funcionaban. Lo remoto no.

La solución tomó cinco minutos una vez que dejaron de adivinar: verificar el listener, confirmar que curl local funciona, confirmar que TCP remoto falla, detectar el drop de nft, corregir la regla/localnet, recompilar. Hicieron un postmortem que no culpó al firewall. Culpó a la suposición.

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

Un equipo decidió que querían “acceso de gestión más limpio”. Pusieron un reverse proxy delante de Proxmox para unificar acceso bajo un dominio interno y obtener certificados mejores. Objetivos razonables.

Luego vino la optimización: activaron timeouts agresivos y límites de conexión en el proxy porque “la UI es solo un panel, no es crítica”. Funcionó hasta que un nodo se puso cargado y las llamadas API tardaron más. El reverse proxy empezó a cortar conexiones a mitad, lo que hizo que los navegadores actuasen como si la UI estuviera rota.

En paralelo, endurecieron suites de cifrado. Algunos scripts de automatización antiguos (clientes curl en agentes de build legacy) empezaron a fallar al autenticarse. La gente “arregló” el problema evitando el proxy y yendo directamente a :8006 en la IP del nodo, creando un patrón de acceso split-brain que nadie documentó.

Un día actualizaron la configuración del proxy y alguien cambió también el certificado de Proxmox. La UI fue accesible a veces, desde algunos clientes, dependiendo de la ruta usada. El equipo perdió un día discutiendo si Proxmox era inestable.

Proxmox no era inestable. Su optimización cambió el modo de fallo de “nodo lento” a “acceso de gestión inconsistente”. Eso es peor. Revirtieron los límites de conexión, ajustaron timeouts acorde a la realidad y estandarizaron en un único camino de acceso con health checks que realmente consultan / en 8006 y validan una respuesta 200.

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

Otra organización ejecutaba Proxmox de forma conservadora: VLAN de gestión separada, IPs documentadas y el hábito de probar la alcanzabilidad de la UI desde una caja de monitorización cada minuto. Nada espectacular. Solo “responde HTTPS en 8006”.

También tenían un runbook poco glamuroso que empezaba por: comprobar listener, estado systemd, journal, disco, firewall. Parecía algo escrito por un SRE cansado un martes. Exactamente quien quieres escribiendo runbooks.

Una tarde, el monitor alertó: “Proxmox UI caída en node3”. El on-call se conectó por SSH (vía una ruta de acceso distinta) y ejecutó el runbook. df -h / mostró root al 100%. Journald seguía registrando, pero los servicios no podían escribir estado y las actualizaciones TLS fallaban.

Liberaron espacio recortando logs antiguos y eliminando un par de ISOs sin uso en el lugar equivocado. Luego reiniciaron pveproxy y confirmaron que curl -kI devolvía 200. La UI volvió en 15 minutos, sin reboot y sin interrumpir VMs.

La “práctica” que los salvó no fue una herramienta elegante. Fueron dos cosas: monitorizar el plano de gestión por separado de la salud de las VMs y tener un runbook que no empieza con plegarias.

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

Estos son patrones que verás repetidamente. Los síntomas se solapan. Las soluciones no.

1) El navegador muestra “connection refused” inmediatamente

• Síntoma: Fallo instantáneo; sin advertencia TLS; sin timeout.
• Causa raíz: Nada escucha en 8006, o el puerto está bloqueado con un REJECT.
• Solución: Ejecuta ss -lntp | grep :8006. Si está vacío, reinicia pveproxy y revisa el journal. Si está escuchando, comprueba reglas de firewall y la ruta remota.

2) El navegador se queda “girando” y acaba en timeout

• Síntoma: Espera larga; finalmente timeout.
• Causa raíz: DROP de firewall en la ruta, problema de ruteo, VLAN equivocada o asimetría; a veces host sobrecargado y la cola de accept no se atiende.
• Solución: Prueba TCP con nc -vz desde un cliente, revisa logs/drops de nftables, valida rutas. Si la carga del host es extrema, reduce carga y reintenta.

3) La UI carga pero la autenticación falla o las tareas quedan colgadas

• Síntoma: La página de login funciona, pero las operaciones fallan o ves errores tipo “501”/“proxy error”.
• Causa raíz: Problemas en demonios backend (pvedaemon), latencia en pmxcfs, problemas de quórum del clúster.
• Solución: Revisa systemctl status pvedaemon pve-cluster, inspecciona journals, valida salud del clúster. Reinicia servicios de gestión en orden.

4) Después de una “limpieza”, pveproxy no arranca (errores de certificado)

• Síntoma: El journal muestra /etc/pve/local/pve-ssl.pem o la clave ausente o ilegible.
• Causa raíz: Alguien borró archivos bajo /etc/pve, cambiaron permisos o pmxcfs no está montado.
• Solución: Asegura que /etc/pve esté montado; regenera certificados con pvecm updatecerts --force (tras confirmar que está bien reemplazarlos).

5) La UI falló justo después de activar el firewall de Proxmox

• Síntoma: curl local funciona, remoto falla; los cambios coinciden con la activación del firewall.
• Causa raíz: Falta regla allow para TCP/8006 desde la subred admin, o localnet mal configurada.
• Solución: Corrige localnet, añade allow explícito para 8006, recompila y recarga el firewall.

6) La UI falló justo después de instalar nginx/apache “para otra cosa”

• Síntoma: pveproxy falla al bindear; logs mencionan dirección ya en uso.
• Causa raíz: Otro servicio tomó el puerto 8006 o hubo un bind wildcard en la IP de gestión.
• Solución: Identifica el listener con ss -lntp, mueve el otro servicio y reinicia pveproxy.

7) La UI muestra fallos de handshake TLS tras cambiar la hora del sistema

• Síntoma: Errores cliente como “certificate not yet valid” o fallos TLS abruptos.
• Causa raíz: Deriva horaria o NTP desactivado; la validez del certificado ya no coincide con la realidad.
• Solución: Arregla NTP/sincronización horaria y regenera certificados si es necesario; reinicia pveproxy.

Broma corta #2: Reiniciar servicios al azar sin leer logs es como reiniciar la tostadora para arreglar el Wi‑Fi: ocasionalmente satisfactorio, raramente efectivo.

Listas de verificación / plan paso a paso

Checklist A: “Necesito la UI en 10 minutos”

1. Haz SSH al nodo (preferiblemente por la red de gestión).
2. Comprueba el listener: ss -lntp | grep :8006.
3. Si no escucha: systemctl status pveproxy y journalctl -u pveproxy -n 100.
4. Arregla lo obvio (disco lleno, certificado faltante, conflicto de puerto).
5. Reinicia en orden: systemctl restart pve-cluster pvedaemon pvestatd pveproxy.
6. Verifica localmente: curl -kI https://127.0.0.1:8006/.
7. Verifica remotamente: nc -vz <node-ip> 8006 desde una máquina cliente.

Checklist B: “Encontrar la causa raíz para que no vuelva a ocurrir”

1. Extrae la última hora de arranque y la línea de tiempos de reinicios.
2. Inspecciona journald para errores de pveproxy y pve-cluster alrededor de la ventana del incidente.
3. Revisa tendencias de uso de disco; identifica qué llenó root (logs, backups, ISOs en sitio equivocado).
4. Valida la configuración y el historial de deriva horaria.
5. Audita cambios de firewall: configs de Proxmox y diffs del ruleset nftables.
6. Confirma la estrategia de gestión de certificados: auto-firmados vs CA gestionada y prácticas de rotación.
7. Añade monitorización que compruebe HTTPS 8006 desde el mismo segmento de red que usan los humanos.

Checklist C: “Consideraciones de clúster (no causes un outage mayor)”

1. Antes de tocar corosync, evalúa si está aislado a un nodo o es cluster-wide.
2. Comprueba el estado de quorum desde un nodo sano si es posible.
3. Si /etc/pve está roto en un nodo, trátalo como un problema de estado de clúster, no solo UI.
4. Evita reiniciar múltiples nodos “por seguridad”. Así descubres qué significa quorum a las 2 a.m.

Preguntas frecuentes

1) ¿Qué servicio sirve realmente la interfaz web de Proxmox?

pveproxy. Escucha en TCP/8006 y proxydea solicitudes API a demonios backend como pvedaemon.

2) Si reinicio pveproxy, ¿interrumpirá a las VMs en ejecución?

No. Reiniciar servicios de gestión no detiene a los huéspedes QEMU/KVM. Puede interrumpir tareas de gestión (sesiones de consola, llamadas API) brevemente.

3) La UI está caída, pero SSH funciona. ¿Qué implica eso?

Implica que el host está vivo y accesible, y puedes depurar localmente. No implica que el firewall permita 8006, ni que pveproxy esté escuchando.

4) ¿Cómo sé si es un problema de firewall o de servicio?

Comprueba localmente primero: curl -kI https://127.0.0.1:8006/. Si lo local funciona pero lo remoto falla, sospecha firewall/ruta. Si lo local falla, sospecha pveproxy o sus dependencias.

5) ¿Puedo mover la UI a otro puerto?

Puedes, pero probablemente no deberías. Proxmox asume 8006 en muchas prácticas operativas y herramientas. Si debes poner un frontend, hazlo con un reverse proxy bien probado y mantén 8006 accesible en la red de gestión.

6) ¿Por qué a pveproxy le importa /etc/pve?

Porque Proxmox almacena la configuración de clúster y material de certificados locales bajo /etc/pve (vía pmxcfs). Si pmxcfs está roto, pveproxy no puede leer de forma fiable lo que necesita.

7) Regeneré certificados y ahora la automatización falla. ¿Qué pasó?

Tu automatización probablemente fijó el fingerprint del certificado antiguo o confió en una cadena específica. Regenerarlo lo cambia. Decide una estrategia de certificados: o confiar consistentemente en la CA auto-firmada de Proxmox o desplegar certificados gestionados y documentarlo.

8) El servicio está “active (running)” pero aún no puedo conectar. ¿Cómo?

Porque “active” no implica “alcanzable”. Puede estar ligado solo a localhost, bloqueado por firewall o accesible solo por IPv6 mientras usas IPv4 (o viceversa). Verifica con ss -lntp y pruebas de red.

9) ¿Debería reiniciar el host para arreglar la UI?

Reiniciar es el último recurso. Puede ayudar si el sistema está muy atascado, pero también puede amplificar un incidente de clúster, interrumpir operaciones de almacenamiento y ocultar la causa real. Obtén logs primero.

10) ¿Y si 8006 está abierto pero la UI es extremadamente lenta?

Eso suele ser carga, IO wait, latencia de pmxcfs o contención de demonios backend. Revisa memoria y swap, latencia de disco y journalctl por timeouts. Lento no es lo mismo que caído, pero frecuentemente comparten la misma causa raíz: un host bajo estrés.

Conclusión: pasos siguientes para evitar este desastre

Cuando la UI de Proxmox en 8006 se apaga, la victoria más rápida es una triage disciplinada: verifica el listener, valida HTTPS local, lee el journal y luego decide si arreglas pveproxy, sus dependencias o la ruta de red. Reiniciar pveproxy suele ser correcto. Reiniciarlo a ciegas es cómo conviertes un incidente pequeño en uno confuso.

Haz lo siguiente:

• Añade monitorización que compruebe https://<mgmt-ip>:8006/ desde el mismo segmento de red que usan las personas.
• Mantén margen en el filesystem root. Un root “casi lleno” es una interrupción retardada con papeleo.
• Decide una política de gestión de certificados (auto-firmados vs gestionados) y cúmplela.
• Trata cambios de firewall como código de producción: revisa, prueba y despliega con plan de reversión.
• Mantén un runbook corto: ss → systemctl → journalctl → df → comprobaciones de firewall. Repetible vence a lo heroico.