Proxmox “Conexión rechazada” en 8006 después de actualizaciones: qué comprobar primero

Lista de diagnóstico rápido (primeros 10 minutos)

Este es el orden que minimiza el tiempo hasta la causa raíz en producción. Está sesgado hacia las fallas que ocurren justo después de actualizaciones: problemas al reiniciar servicios, certificados, cambios en el firewall y dependencias de clúster.

Minuto 0–2: Confirma que el síntoma es local, no “la red”

1. Desde tu estación de trabajo: ¿funciona ssh? Si SSH falla también, esto no es un problema de “8006”; es enrutamiento, enlace, IP o host caído.
2. Desde el propio host Proxmox: prueba su propio puerto 8006 con curl. Si no puede alcanzarse a sí mismo, el problema casi seguro es que pveproxy no está escuchando o está siendo bloqueado localmente.

Minuto 2–5: Comprueba si algo está escuchando en 8006

1. Usa ss para ver si 8006 está ligado. Si nadie escucha, no toques los firewalls aún. Arregla pveproxy primero.
2. Revisa systemctl status pveproxy. Si ha fallado, lee el error y ve directamente a los registros (journalctl -u pveproxy).

Minuto 5–7: Valida las dependencias de la pila de gestión

1. Comprueba pvedaemon y pvestatd. La UI puede “conectarse” pero comportarse de forma errática si estos están muertos; pero “conexión rechazada” suele ser pveproxy.
2. Verifica espacio en disco y presión de inodos. Sistemas de ficheros raíz llenos y particiones de logs llenas matan demonios de forma poco glamorosa.

Minuto 7–10: Firewall, luego clúster, luego certificados

1. Firewall: confirma que pve-firewall y reglas de nftables/iptables no estén rechazando tcp/8006.
2. Estado del clúster: si este host está en un clúster, el quórum y corosync pueden frenar indirectamente la gestión (especialmente alrededor del sistema de archivos de configuración).
3. Certificados: una clave/certificado SSL roto o ilegible puede impedir que pveproxy arranque.

Haz esto en orden. Si empiezas por “simplemente reiniciar todo”, puedes convertir una falla limpia en una complicada. Sí, sé que reiniciar se siente productivo. También es la versión adulta de soplar en un cartucho de Nintendo.

Qué significa realmente “Conexión rechazada” en 8006

Los navegadores son dramáticos. “Conexión rechazada” no es “lento”, no es “error TLS” y no es “autenticación fallida”. Normalmente es una de tres cosas:

• Ningún proceso está escuchando en esa IP:puerto. El kernel responde con RST (reset), y tu cliente reporta “rechazado”.
• Un firewall local está rechazando activamente la conexión (también con frecuencia RST). Es más raro de lo que la gente piensa, pero ocurre—especialmente con reglas que cambiaron durante actualizaciones.
• Desajuste de proxy inverso / activación por socket (menos común). Para Proxmox, el demonio relevante es pveproxy, que liga 8006 y gestiona TLS.

Si el problema fuera “bloqueado” (DROP), verías más a menudo tiempos de espera. Si fuera “TLS roto”, normalmente te conectarías y verías un error de certificado, no “rechazado”. Así que trata “rechazado” como una señal fuerte: el puerto no es alcanzable a nivel de aceptación TCP.

También hay una variante sutil: 8006 está escuchando, pero solo en la interfaz equivocada (por ejemplo, ligado a 127.0.0.1). Eso todavía puede parecer un rechazo desde fuera. Lo comprobaremos explícitamente.

Datos y contexto interesantes (porque esto tiene historia)

• El puerto 8006 no se eligió por estética. Proxmox históricamente usó un puerto alto y no estándar para evitar choques con otras pilas web en el mismo host.
• pveproxy es un demonio en Perl. No es lo más moderno, pero está probado en batalla e integrado con la API y la pila de autenticación de Proxmox.
• Proxmox se apoya en Debian. Muchas incidencias “tras actualizaciones” son realmente cambios a nivel Debian: kernel, libc, OpenSSL, comportamiento de systemd, defaults de nftables.
• Proxmox migró el backend de firewall con el tiempo. El cambio más amplio de Debian de iptables a nftables ha sido fuente recurrente de “las reglas existen, pero no donde crees”.
• La configuración del clúster es un sistema de archivos. La configuración del clúster de Proxmox vive en un sistema de archivos de configuración distribuido (pmxcfs), y cuando está descontento, los flujos de trabajo de gestión se vuelven raros rápidamente.
• Los valores por defecto de TLS se han endurecido. OpenSSL y bibliotecas relacionadas deprecian ciphers/protocolos antiguos; los demonios que no pueden cargar claves/certs correctamente a menudo fallan de forma contundente.
• Systemd hizo que los servicios sean más observables. Eso es lo bueno. Lo malo es que también hizo los “bucles de reinicio” muy eficientes, así que un demonio roto puede fallar 50 veces antes de que parpadees.
• Las actualizaciones de Proxmox no son solo de interfaz. Tócan rutinariamente herramientas de almacenamiento (ZFS), redes (ifupdown2) y capas de virtualización (QEMU/KVM). Estás actualizando un pequeño centro de datos, no una app web.

Una idea para llevar en el bolsillo, parafraseada atribuyéndola a Werner Vogels: “Todo falla eventualmente; la resiliencia viene de asumirlo y diseñar operaciones en consecuencia.” (idea parafraseada)

Tareas prácticas: comandos, salidas, decisiones (12+)

Estas son las comprobaciones que realmente ejecuto cuando estoy de guardia y alguien dice: “Proxmox está caído.” Cada tarea incluye: el comando, un fragmento de salida realista, lo que significa y qué decisión tomar a continuación.

Tarea 1: Verificar que el host está arriba y que estás en la máquina correcta

cr0x@server:~$ hostnamectl
 Static hostname: pve01
       Icon name: computer-server
         Chassis: server
      Machine ID: 1c3f0c0c9b0d4c2d9d2a2e0d1a0cbeef
         Boot ID: 6b77c2a5a1a74c469c9c4a9b3d9d1234
Operating System: Debian GNU/Linux 12 (bookworm)
          Kernel: Linux 6.8.12-2-pve
    Architecture: amd64

Significa: Estás en el host Proxmox que crees y conoces el contexto de OS/kernel tras las actualizaciones.

Decisión: Si el kernel cambió, recuerda: el nombrado de NICs, cambios de drivers y backends de firewall pueden variar tras un reinicio.

Tarea 2: Confirmar si 8006 está escuchando y en qué IP

cr0x@server:~$ ss -lntp | grep -E ':8006|State'
State  Recv-Q Send-Q Local Address:Port  Peer Address:Port Process
LISTEN 0      4096         0.0.0.0:8006       0.0.0.0:*     users:(("pveproxy",pid=1432,fd=6))

Significa: pveproxy está escuchando en todas las interfaces. “Conexión rechazada” desde fuera es improbable que sea por servicio caído.

Decisión: Si ves solo 127.0.0.1:8006, trátalo como problema de bind/interfaz. Si no ves nada, ve a la Tarea 4 (estado del servicio) y Tarea 5 (registros).

Tarea 3: Probar localmente con curl (quita la red de la ecuación)

cr0x@server:~$ curl -k -sS -o /dev/null -w '%{http_code}\n' https://127.0.0.1:8006/
200

Significa: El endpoint de la UI responde localmente. Si los usuarios remotos reciben rechazo, el problema casi seguro es firewall/enrutamiento/VIP, no los servicios de Proxmox.

Decisión: Salta a las comprobaciones de firewall (Tarea 10/11) y verificaciones de interfaz (Tarea 8/9).

Tarea 4: Revisar la salud de pveproxy vía systemd (no adivines)

cr0x@server:~$ systemctl status pveproxy --no-pager
● pveproxy.service - PVE API Proxy Server
     Loaded: loaded (/lib/systemd/system/pveproxy.service; enabled; preset: enabled)
     Active: failed (Result: exit-code) since Wed 2025-12-25 10:44:02 UTC; 45s ago
    Process: 1519 ExecStart=/usr/bin/pveproxy start (code=exited, status=1/FAILURE)
   Main PID: 1519 (code=exited, status=1/FAILURE)

Dec 25 10:44:02 pve01 pveproxy[1519]: starting server
Dec 25 10:44:02 pve01 pveproxy[1519]: can't load certificate '/etc/pve/local/pve-ssl.pem': No such file or directory
Dec 25 10:44:02 pve01 systemd[1]: pveproxy.service: Main process exited, code=exited, status=1/FAILURE
Dec 25 10:44:02 pve01 systemd[1]: pveproxy.service: Failed with result 'exit-code'.

Significa: Fallo claro: falta el archivo de certificado bajo /etc/pve. Eso apunta a pmxcfs/sistema de archivos de clúster no montado/saludable, o a que la generación de certificados se interrumpió.

Decisión: Ve a las Tareas 6 y 7 (pmxcfs y comprobaciones de /etc/pve), luego regenera certificados una vez que /etc/pve esté sano.

Tarea 5: Leer registros con contexto (journalctl es tu amigo)

cr0x@server:~$ journalctl -u pveproxy -b --no-pager -n 60
Dec 25 10:44:02 pve01 pveproxy[1519]: starting server
Dec 25 10:44:02 pve01 pveproxy[1519]: can't load certificate '/etc/pve/local/pve-ssl.pem': No such file or directory
Dec 25 10:44:02 pve01 systemd[1]: pveproxy.service: Main process exited, code=exited, status=1/FAILURE
Dec 25 10:44:02 pve01 systemd[1]: pveproxy.service: Failed with result 'exit-code'.
Dec 25 10:44:12 pve01 systemd[1]: pveproxy.service: Scheduled restart job, restart counter is at 5.

Significa: Está en bucle de reinicio. Eso puede causar problemas en cascada (spam de logs, carga CPU), pero la causa raíz sigue siendo la primera línea de error.

Decisión: Arregla la causa del certificado/ruta/pmxcfs. No sigas reiniciando. Solo estás generando calor.

Tarea 6: Verificar que pmxcfs esté en ejecución (porque /etc/pve no está “normal”)

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; preset: enabled)
     Active: active (running) since Wed 2025-12-25 10:42:21 UTC; 3min ago
   Main PID: 602 (pmxcfs)
      Tasks: 7 (limit: 154322)
     Memory: 52.1M
        CPU: 1.824s

Significa: pmxcfs está activo. Eso no garantiza que esté sano, pero descarta el caso obvio de “servicio caído”.

Decisión: Si está fallado, arréglalo primero (almacenamiento/ disco lleno/ quórum). Si está en ejecución, confirma que /etc/pve esté montado y poblado (Tarea 7).

Tarea 7: Confirmar que /etc/pve está montado (y no es un triste directorio vacío)

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

Significa: Está montado vía FUSE. Bien. Ahora verifica si el archivo de certificado esperado existe.

Decisión: Si no ves una línea de montaje, no estás viendo el sistema de archivos del clúster; los servicios de Proxmox se comportarán mal. Investiga el arranque de pmxcfs y el quórum/clúster (Tarea 12/13).

Tarea 8: Asegúrate de que la IP de gestión sigue en la interfaz (a actualizaciones y reinicios les encantan las sorpresas)

cr0x@server:~$ ip -br addr
lo               UNKNOWN        127.0.0.1/8 ::1/128
eno1             UP             10.20.10.11/24
vmbr0            UP             10.20.10.11/24 fe80::2a0:98ff:fe12:3456/64

Significa: La IP está presente. Nota: tener la misma IP en una NIC física y en un bridge puede ser legítimo según la configuración, pero también puede ser un error tras una reescritura de interfaces.

Decisión: Si falta la IP de gestión esperada, arregla la red primero. La UI de Proxmox no se ligará mágicamente a una IP que no tienes.

Tarea 9: Comprobar el enrutamiento (porque “hace ping” no es la tabla de rutas)

cr0x@server:~$ ip route
default via 10.20.10.1 dev vmbr0 proto kernel onlink
10.20.10.0/24 dev vmbr0 proto kernel scope link src 10.20.10.11

Significa: Existe ruta por defecto. Si tu estación de gestión está en otra subred, necesitas que esto esté correcto para alcanzar 8006.

Decisión: Ruta por defecto incorrecta o ruta faltante: corrige la configuración de red. No culpes a los servicios de Proxmox por los pecados de tu router.

Tarea 10: Comprobar estado del firewall de Proxmox (PVE firewall puede rechazar 8006)

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

Significa: El firewall PVE está activo. Está bien, pero implica que las reglas importan.

Decisión: Si está enabled, inspecciona el conjunto de reglas y confirma que 8006 esté permitido en la interfaz de gestión. Si está deshabilitado, aún revisa nftables/iptables (Tarea 11).

Tarea 11: Inspeccionar reglas nftables en busca de rechazos explícitos (rechazado suele equivaler a “refused”)

cr0x@server:~$ nft list ruleset | sed -n '1,120p'
table inet filter {
  chain input {
    type filter hook input priority filter; policy drop;
    iif "lo" accept
    ct state established,related accept
    tcp dport 22 accept
    tcp dport 8006 reject with tcp reset
  }
}

Significa: Alguien (o algo) está rechazando explícitamente 8006 con un TCP reset. Eso produce “Conexión rechazada” en los clientes.

Decisión: Arregla la regla (elimina el reject o reemplázalo por accept para tus redes de administración). No “vuelques temporalmente todo” a menos que disfrutes la exposición sorpresa.

Tarea 12: Revisar corosync/quórum (los hosts de clúster pueden comportarse como poseídos sin ello)

cr0x@server:~$ pvecm status
Cluster information
-------------------
Name: prod-cluster
Config Version: 42
Transport: knet
Secure auth: on

Quorum information
------------------
Date: Wed Dec 25 10:47:11 2025
Quorum provider: corosync_votequorum
Nodes: 3
Node ID: 0x00000001
Ring ID: 1.2a
Quorate: Yes

Significa: El quórum está bien. Si fuera Quorate: No, muchos servicios dependientes de la configuración pueden quedarse estancados o rechazar escrituras, y verás roturas secundarias.

Decisión: Si no hay quórum, decide: restaurar el quórum (preferido) o aislar el nodo de forma segura. Evita “simplemente reiniciar otro nodo” como estrategia.

Tarea 13: Comprobar espacio en disco e inodos (aburrido, frecuente, letal)

cr0x@server:~$ df -h /
Filesystem      Size  Used Avail Use% Mounted on
/dev/mapper/pve-root   94G   94G     0 100% /

Significa: El sistema de ficheros raíz está lleno. Los servicios que necesitan escribir PID, logs o estado fallarán de formas que parecen no relacionadas con el almacenamiento.

Decisión: Libera espacio inmediatamente y luego reinicia los servicios afectados. También encuentra qué creció (Tarea 14) y arregla el comportamiento subyacente de logs/backups.

Tarea 14: Identificar qué está consumiendo el sistema de ficheros raíz

cr0x@server:~$ du -xhd1 /var | sort -h
1.1G	/var/cache
2.4G	/var/log
38G	/var/lib

Significa: Algo bajo /var/lib es grande. En Proxmox, candidatos incluyen almacenamiento de ISOs, imágenes de contenedores, backups o journald descontrolado.

Decisión: Profundiza (du -xhd1 /var/lib) y elimina/mueve el culpable correcto. No borres aleatoriamente configuraciones de clúster. Por ahí está el arrepentimiento.

Tarea 15: Validar que los certificados existen y son legibles

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

Significa: Certificado y clave existen con permisos plausibles.

Decisión: Si faltan o están corruptos, regenera (Tarea 16). Si los permisos son incorrectos (demasiado restrictivos), arregla la propiedad/mode para que pveproxy pueda leerlos.

Tarea 16: Regenerar certificados de Proxmox (cuando problemas de certificados impiden arrancar pveproxy)

cr0x@server:~$ pvecm updatecerts --force
Generating new certificates...
Restarting pveproxy...
Restarting pvedaemon...
done

Significa: Proxmox ha regenerado certificados conscientes del clúster y reiniciado los demonios relevantes.

Decisión: Revisa de nuevo systemctl status pveproxy y verifica que esté escuchando en 8006 (Tarea 2). Si sigue fallando, vuelve a los registros; no repitas esto sin fin.

Tarea 17: Buscar conflictos de puerto (raro, pero vale una mirada)

cr0x@server:~$ lsof -nP -iTCP:8006 -sTCP:LISTEN
COMMAND   PID USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
pveproxy 1432 root    6u  IPv6  31245      0t0  TCP *:8006 (LISTEN)

Significa: El proceso correcto posee el puerto.

Decisión: Si otra cosa está escuchando en 8006, deténla o reconfigúrala. Proxmox espera poseer ese puerto; pelear por él es una elección de vida.

Tarea 18: Verificar accesibilidad remota desde otro host en la misma subred

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

Significa: La conexión TCP funciona. Si tu navegador aún da error, probablemente sea confianza TLS/caché del navegador, o estás apuntando a la IP/DNS equivocada.

Decisión: Valida resolución DNS y destino en el navegador. También comprueba si usas un VIP, proxy inverso o reenvío de puerto que cambió durante actualizaciones de red.

Una verdad operativa más: “Conexión rechazada” rara vez es un misterio y con frecuencia es fallo de lista de verificación. Eso es buena noticia. Significa que puedes arreglarlo sin poesía.

Broma #1: Si tu plan post-actualización es “simplemente revertir”, felicidades—has descubierto el viaje en el tiempo, pero solo para versiones de paquetes.

Tres mini-historias corporativas desde el terreno

Incidente #1: La suposición equivocada (“Debe ser el firewall”)

Una empresa SaaS mediana ejecutaba un clúster Proxmox de tres nodos para runners de CI internos y staging. Tras actualizaciones rutinarias en un nodo, la UI web dejó de responder en 8006. La primera reacción del ingeniero de guardia fue lo habitual: “la actualización de seguridad tocó el firewall.” Deshabilitaron el servicio del firewall y seguían obteniendo “Conexión rechazada.” Eso debió haber sido la pista, pero la adrenalina es una droga persuasiva.

El ingeniero luego volcó las reglas de nftables por completo. El nodo fue accesible en 8006 durante unos treinta segundos y luego volvió a oscurecerse. “¿Ves? Firewall.” Excepto que no era eso. Lo que realmente sucedió fue: pveproxy estaba en bucle de reinicio, enlazando brevemente 8006 entre caídas. Vaciar las reglas cambió el timing, no la causalidad.

La causa raíz estaba a la vista: el sistema de archivos raíz alcanzó 100%. pveproxy no podía escribir su estado, pvedaemon se puso inestable y systemd ejecutó su eficiente coreografía de fallo. El chivo expiatorio del firewall les costó cerca de una hora, además de una agradable nota de auditoría porque el nodo quedó con una política de entrada efectivamente abierta más tiempo del debido.

Lo que lo arregló no fue ingenio. Liberaron espacio bajo /var/log, rotaron journals, reiniciaron servicios y añadieron monitorización del llenado del filesystem. La línea final del postmortem fue directa: “Asumimos causa por correlación (actualización → firewall). No validamos el estado del socket primero.”

Incidente #2: La optimización que salió mal (“Cerramos la política input a drop”)

Un gran equipo de TI corporativo estandarizó una imagen de host endurecida. Un cambio parecía ordenado en papel: establecer la política por defecto de input a drop, luego permitir explícitamente solo puertos necesarios. Sensato. Controlado. Favorable a auditoría.

El problema fue cómo lo implementaron en Proxmox. Empujaron una plantilla de nftables que permitía SSH y un puñado de puertos de monitorización, pero asumieron que la UI web estaba detrás de un proxy inverso corporativo y no necesitaba acceso directo a 8006. Esa suposición era cierta para la mayoría de entornos. Fue falsa para el acceso break-glass cuando el proxy inverso estaba caído—o durante mantenimiento cuando los administradores hacían SSH desde un jump host y esperaban alcanzar https://node:8006 directamente.

Tras una actualización y reinicio, Proxmox volvió bien, pveproxy escuchó en 8006 y el curl local devolvió 200. Desde el jump host, cada intento recibió “Conexión rechazada”, porque la plantilla usaba reject with tcp reset para puertos no listados. Ese detalle fue el que engañó a la gente: un error “rechazado” huele a “servicio caído”.

La solución no fue “abrir todo”. Añadieron una regla allow estrecha para 8006 desde la subred del jump host y mantuvieron la política drop por defecto. Más importante, documentaron que los puertos del plano de gestión son parte del camino break-glass, no una comodidad opcional. La optimización (base más estricta) era correcta; el despliegue sin excepciones operacionales fue el error.

Incidente #3: La práctica aburrida que salvó el día (pre-checks y reinicios escalonados)

Un equipo de servicios financieros ejecutaba Proxmox para VDI y un montón de servicios internos. Eran conservadores hasta el punto de la comedia: cada ventana de actualización empezaba con un script de pre-check, guardado en un ticket y revisado por una segunda persona. Parecía burocracia hasta que no lo fue.

Una noche, las actualizaciones incluyeron cambios que requerían reinicio. Antes de reiniciar, el pre-check capturó: espacio libre, presión de memoria, quórum del clúster y si el nodo hospedaba VMs críticas. También capturó “qué está escuchando en 8006 ahora” y el hash del ruleset del firewall actual. Aburrido. Repetitivo. Exactamente el punto.

Tras el reinicio, 8006 estaba rechazando conexiones. El ingeniero de guardia no empezó a aletear porque tenía una línea base: antes del reinicio, nftables tenía un allow para 8006; después del reinicio, el allow faltaba. Eso redujo drásticamente el espacio de búsqueda. El problema se rastreó a una ejecución de gestión de configuración que aplicó el rol equivocado a ese nodo durante la ventana de mantenimiento.

Revirtieron el rol, restauraron la regla allow y volvieron online rápidamente. El postmortem no tuvo heroicidades, solo una línea que todos odian y necesitan: “Nuestros pre-checks convirtieron un misterio en un diff.” La única parte emocionante fue lo poco emocionante que fue la recuperación.

Broma #2: La UI de Proxmox no “se rompió al azar tras actualizaciones.” Se rompió según el calendario—simplemente no leíste la agenda.

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

Esta sección es donde el tiempo muere si no reconoces patrones. Aquí están los reincidentes, afinados específicamente para “Conexión rechazada” en 8006 justo después de actualizaciones.

1) “Conexión rechazada” inmediatamente después del reinicio

• Síntoma: El navegador dice rechazado; ping funciona; SSH funciona.
• Causa raíz: pveproxy falló al arrancar (certificado faltante/corrupto, pmxcfs no montado o problema de sintaxis en la configuración).
• Solución: systemctl status pveproxy → journalctl -u pveproxy. Valida montaje de /etc/pve; regenera certificados con pvecm updatecerts --force solo después de que /etc/pve esté sano.

2) curl local funciona, remoto rechazado

• Síntoma: curl -k https://127.0.0.1:8006 devuelve 200; navegador remoto rechazado.
• Causa raíz: nftables/iptables rechaza 8006, o servicio ligado solo a loopback, o la IP se movió a otra interfaz/VLAN.
• Solución: Comprueba ss -lntp para dirección de bind; revisa reglas de firewall (nft list ruleset); verifica IP y rutas (ip -br addr, ip route).

3) “Funcionaba antes de la actualización” y ahora solo un nodo está roto

• Síntoma: El clúster tiene múltiples nodos; solo el nodo actualizado rechaza en 8006.
• Causa raíz: /etc/pve del nodo está obsoleto/no montado, problema en enlace corosync, o el nodo arrancó con una configuración de red diferente (cambio de nombres de bridge, VLAN faltante).
• Solución: Revisa pvecm status, systemctl status pve-cluster, mount | grep /etc/pve y la configuración de red en /etc/network/interfaces (con cuidado).

4) “Conexión rechazada” solo desde algunas redes

• Síntoma: Funciona desde el jump host, rechazado desde tu portátil, o viceversa.
• Causa raíz: Las reglas de acceso de gestión son específicas por subred; tal vez una baseline corporativa introdujo un reject explícito para 8006 excepto desde rangos aprobados.
• Solución: Confirma con contadores y orden de reglas de nft; añade allow explícito para 8006 desde las fuentes de administración requeridas.

5) 8006 “rechazado” y otros servicios aleatorios intermitentes

• Síntoma: No solo la UI—métricas, backups o arranques de contenedores también fallan.
• Causa raíz: Disco lleno, agotamiento de inodos o sistema de archivos montado en solo-lectura tras errores.
• Solución: df -h, df -i, dmesg -T | tail; remedia almacenamiento y luego reinicia servicios.

6) Sigues reiniciando servicios y sigue fallando

• Síntoma: systemctl restart pveproxy “funciona” pero la UI sigue rechazada; o falla inmediatamente.
• Causa raíz: Reiniciar no arregla los archivos faltantes, problemas de permisos o puerto bloqueado. Solo mueve la marca temporal.
• Solución: Para y lee los registros. Arregla el primer error. Solo entonces reinicia.

Listas de verificación / plan paso a paso (recuperación segura)

Este es el plan que sigues cuando quieres la UI de vuelta y no quieres crear daño colateral. Está escrito para ser seguro en hosts standalone y nodos de clúster.

Fase 1: Confirmar alcance (2–5 minutos)

1. Verificar alcanzabilidad del host: entra por SSH; confirma host correcto (hostnamectl).
2. Comprobar alcanzabilidad UI local: curl -k https://127.0.0.1:8006/.
3. Comprobar listener: ss -lntp | grep :8006.

Si 8006 no está escuchando: ve a la Fase 2.
Si sí escucha localmente pero falla remoto: salta a la Fase 4 (red/firewall).

Fase 2: Arreglar el servicio (5–15 minutos)

1. Estado y logs: systemctl status pveproxy, luego journalctl -u pveproxy -b.
2. Dependencias: systemctl status pvedaemon pve-cluster.
3. Comprobar /etc/pve: mount | grep ' /etc/pve ' y ls -l /etc/pve/local/.
4. Sanidad de disco: df -h /, df -i /. Arregla si está lleno antes de cualquier otra cosa.

Fase 3: Certificados y sistema de archivos de configuración (según necesidad)

1. Si los archivos de cert faltan o están rotos: asegura que /etc/pve esté montado y poblado.
2. Luego regenera certificados: pvecm updatecerts --force.
3. Revisa el listener: ss -lntp | grep :8006 y curl local.

Fase 4: Firewall y camino de red (cuando local funciona pero remoto no)

1. Confirmar dirección de bind: si está solo en 127.0.0.1:8006, arregla la configuración que constriñe el bind (raro; normalmente no es default).
2. Comprobar firewall de Proxmox: pve-firewall status. Si está activo, confirma reglas que permitan 8006 desde tus subredes de administración.
3. Revisar nftables: nft list ruleset y busca tcp dport 8006 con reject/drop.
4. Validar IP y enrutamiento: ip -br addr, ip route.
5. Probar desde otro host: nc -vz <ip> 8006.

Fase 5: Sanidad específica de clúster (solo si está en clúster)

1. Comprobar quórum: pvecm status.
2. Comprobar corosync: systemctl status corosync y logs según necesites.
3. Evitar “arreglos” arriesgados: no retires nodos del clúster solo para que la UI vuelva. Restaura conectividad de red entre nodos primero.

Cuándo detenerse y escalar

• Si ves errores de sistema de ficheros en dmesg o remontajes en solo-lectura.
• Si el quórum del clúster se perdió y no estás seguro de qué nodos son “reales”.
• Si el host también es cabeza de almacenamiento (ZFS/NFS/iSCSI) y una mala maniobra podría tumbar otros servicios.

Preguntas frecuentes

1) ¿Por qué “Conexión rechazada” suele significar pveproxy, no el demonio API?

Porque 8006 es el endpoint TLS servido por pveproxy. Si ese demonio no está escuchando (o un firewall rechaza), la conexión TCP no se establecerá. Los problemas de pvedaemon tienden a aparecer como errores de UI después de conectar, no como un rechazo.

2) ¿Cuál es la comprobación más rápida?

ss -lntp | grep :8006. Si nadie escucha, deja de pensar en routers y empieza a leer los logs de pveproxy.

3) curl local funciona pero el navegador de mi portátil es rechazado. ¿Ahora qué?

Asume firewall o camino de red. Revisa nftables en busca de reject with tcp reset en 8006, valida que la IP esté en la interfaz correcta y prueba desde un host en la misma subred usando nc -vz.

4) ¿Puedo simplemente reiniciar pveproxy y listo?

Puedes intentarlo una vez. Si falla, los reinicios repetidos son teatro. Lee journalctl -u pveproxy y arregla la primera línea de error.

5) ¿Un montaje faltante de /etc/pve realmente rompe la UI?

Sí. Proxmox almacena configuración clave y material de certificados bajo /etc/pve, respaldado por pmxcfs. Si no está montado o está malsano, servicios que dependen de él pueden fallar o arrancar con archivos faltantes.

6) ¿Con qué frecuencia el disco lleno es la causa real?

Con suficiente frecuencia como para que deba estar en tus primeras cinco comprobaciones. El root al 100% rompe demonios, generación de certificados, logging y a veces scripts postinst de paquetes. No es glamoroso, pero es común.

7) Actualicé paquetes pero no reinicié. ¿Aún puede causar que 8006 rechace?

Sí. Los scripts post-install de paquetes pueden reiniciar servicios inmediatamente. Si cambió una dependencia (OpenSSL, módulos perl, estado del sistema de ficheros de configuración) el reinicio puede fallar incluso sin reboot.

8) Si se pierde el quórum, ¿8006 rechazará conexiones?

No siempre. La pérdida de quórum más comúnmente hace que acciones de gestión fallen o que la configuración se vuelva de solo lectura. Pero puede romper indirectamente rutas de certificados y comportamiento de pmxcfs, lo que impide que pveproxy arranque.

9) ¿Debería abrir 8006 a Internet para “hacer que funcione”?

No. Arregla el problema real. Si necesitas acceso remoto, ponlo detrás de VPN, bastión o una lista de allow estricta. Exponer planos de gestión es cómo terminas pasando fines de semana aprendiendo respuesta a incidentes.

10) ¿Y si 8006 está escuchando pero aún no puedo cargar la UI?

Eso ya no es “conexión rechazada.” Revisa errores del navegador, alertas TLS y si estás apuntando a la IP/DNS correcta. También verifica que pvedaemon esté en ejecución y que el host no esté bajo presión extrema de recursos.

Próximos pasos que realmente deberías hacer

Restaura el servicio primero, luego haz que sea más difícil que esto vuelva a ocurrir.

1. Fija las comprobaciones rápidas: ss -lntp, systemctl status pveproxy, journalctl -u pveproxy, df -h, nft list ruleset. Ponlas en tu runbook exactamente en ese orden.
2. Añade monitorización que detecte a los verdaderos asesinos: uso de filesystem root, uso de inodos, salud de pmxcfs y si 8006 está escuchando desde un punto de vista externo.
3. Deja de tratar las actualizaciones como “solo parches”: prográmalas, estúdiolas por etapas y captura un diff antes/después del estado de firewall y red. La práctica aburrida es la que funciona a las 3 a.m.
4. Para clústeres: trata el quórum y la conectividad de corosync como parte del plano de gestión. Si el clúster está inestable, la UI es un síntoma, no la enfermedad.

Si no haces nada más: la próxima vez que veas “Conexión rechazada”, comprueba si algo está escuchando en 8006 antes de tocar un firewall. Ese hábito único ahorra horas y evita “arreglar” agresivamente lo equivocado.