Hay una pregunta bastante simple que, por algún motivo, mucha gente tarda demasiado en hacer cuando el panel web de Proxmox se pone tonto.
¿Hay algo escuchando en el puerto 8006 o no?
Parece una obviedad. Justamente por eso vale tanto.
Cuando la interfaz falla es muy fácil empezar por donde no toca. El navegador. El certificado. El túnel. El proxy inverso. La VPN. El firewall. El DNS. El cluster entero, ya puestos. Todo eso puede influir, sí. Pero antes de montar una novela prefiero comprobar si el propio nodo está escuchando en el puerto del panel.
Para eso suelo tirar de este comando.
ss -ltnp | grep 8006
Es corto, seco y muy poco glamuroso. Perfecto. Me da una respuesta local en segundos. Si no sale nada, ya sé que el problema es serio y bastante terrenal. Si sí sale algo, entonces puedo dejar de acusar a Proxmox por defecto y empezar a mirar otras capas con un poco más de orden.
por qué este comando me parece tan útil#
Porque ataca una duda muy concreta sin rodeos.
No intenta resumir el nodo. No me cuenta el estado del cluster. No me habla de storage ni de quorum. Solo responde a una pregunta local.
¿Qué proceso está escuchando en el puerto 8006 ahora mismo?
En Proxmox ese puerto importa mucho porque es la puerta habitual del panel web y de la API HTTPS. Si ahí no hay nadie escuchando, da bastante igual que el DNS sea precioso o que el navegador tenga un día inspirado. No vas a entrar.
Y si ahí sí hay alguien escuchando, la investigación cambia por completo. El fallo puede seguir siendo local, pero también puede estar entre tu cliente y ese socket. Y ese matiz me ahorra bastante tiempo.
la captura real que me basta para orientarme#
Esta salida sale de un nodo real de mi lab, saneada para no arrastrar detalles internos que aquí no pintan nada.
A simple vista parece poquísima cosa. Eso me encanta.
No necesito veinte líneas para orientarme. Con una sola ya sé bastante.
Veo LISTEN. Veo *:8006. Veo que el proceso asociado es pveproxy y además aparecen varios workers. Para una primera lectura, eso ya me da media respuesta.
El nodo está escuchando en el puerto correcto.
No significa que el panel vaya perfecto desde fuera. Significa algo más modesto y mucho más útil. Localmente, el servicio web de Proxmox sí tiene un socket abierto y preparado para aceptar conexiones.
A partir de ahí ya puedo repartir mejor mis sospechas.
qué hace exactamente ss#
ss es una herramienta para inspeccionar sockets. A estas alturas la prefiero claramente sobre netstat cuando quiero una lectura rápida de puertos y procesos.
En este caso uso estas opciones.
-lpara ver sockets en escucha-tpara filtrar TCP-npara no resolver nombres y que la salida no se vuelva más torpe de la cuenta-ppara mostrar el proceso asociado
Luego remato con grep 8006 porque no me apetece mirar una lista entera de puertos cuando solo quiero saber qué pasa con el panel de Proxmox.
Es una combinación bastante austera. Y precisamente por eso funciona tan bien en un momento de diagnóstico.
cómo leo la salida sin complicarme la vida#
Voy por partes.
LISTEN#
Lo primero es obvio. Quiero ver que el socket está en escucha.
Si no veo LISTEN, o directamente no sale ninguna línea, ya tengo una pista muy fuerte. El nodo no está aceptando conexiones en el puerto que debería usar el panel.
Eso no resuelve la causa raíz, pero sí me ahorra perder tiempo en teorías de camino de red cuando el propio servicio local ni siquiera ha abierto la puerta.
*:8006#
Esta parte me importa bastante.
Ver *:8006 me dice que está escuchando en todas las interfaces. Para el panel web de Proxmox esa suele ser la pinta que quiero ver en una instalación normal.
Si en vez de eso estuviera limitado a 127.0.0.1:8006, por ejemplo, la historia sería muy distinta. El servicio existiría, sí, pero solo sería accesible de forma local y desde fuera parecería roto aunque en realidad el problema sería el bind del socket.
Ese detalle cambia totalmente la investigación.
Por eso me gusta tanto este comando. No me obliga a deducir. Me enseña directamente dónde está escuchando el proceso.
el proceso asociado#
Aquí quiero ver pveproxy.
En la captura aparecen pveproxy worker y el proceso principal pveproxy. Eso es exactamente lo que espero cuando el panel está realmente arriba en ese nodo.
No me obsesiono con los PIDs. Los tomo como contexto, no como protagonista. Lo importante es que el puerto correcto está asociado a la familia de procesos correcta.
Si el 8006 estuviera ocupado por otra cosa, tendríamos una historia bastante más fea.
la cola de escucha#
0 4096 no es la parte más sexy de la salida, pero tampoco la ignoro.
En una revisión rápida no me pongo a hacer arqueología de backlog. Solo me basta saber que el socket tiene pinta normal y no estoy ante una rareza obvia.
Cuando hay una incidencia local, el valor que más me importa aquí sigue siendo otro. La presencia o ausencia del socket.
por qué prefiero esto antes que abrir tres pestañas más#
Porque me da una verdad bastante cruda.
El navegador puede engañar. Un proxy puede meter ruido. Un túnel puede fallar. Incluso una sesión vieja puede hacerte creer que Proxmox está peor de lo que está.
ss no me cuenta un relato bonito. Me enseña si el nodo escucha o no escucha.
A veces esa simplicidad salva bastante tiempo.
He tenido casos donde desde fuera el panel parecía muerto y, sin embargo, esta salida me decía que el 8006 seguía perfectamente abierto con pveproxy detrás. En ese momento ya sé que no me toca perder veinte minutos reiniciando servicios a ciegas. Me toca mirar el camino desde el cliente, el certificado, el reverse proxy o la capa de red.
Y también he tenido el caso contrario.
Todo el mundo mirando DNS, firewall y navegador cuando el nodo ni siquiera tenía el 8006 en escucha. Ahí un ss -ltnp | grep 8006 corta la discusión en seco.
cuándo lo lanzo yo casi en automático#
cuando el panel no responde, pero el SSH sí#
Este es probablemente el caso donde más me gusta.
Si entro por SSH sin drama, pero la interfaz web parece muerta, quiero saber enseguida si el problema es la escucha local del puerto o algo que ocurre después.
Con este comando lo separo muy rápido.
después de tocar pveproxy#
Si he reiniciado pveproxy, actualizado paquetes o hecho algo alrededor del acceso web, me gusta confirmar el resultado con una comprobación local del socket.
No me basta con pensar que el servicio arrancó. Quiero ver el puerto escuchando.
cuando hay un proxy inverso, túnel o capa intermedia#
Si el acceso al panel pasa por algo más, todavía me parece más importante comprobar esto primero.
Cuando hay varias capas, la tentación de culpar a la última es muy fuerte. ss me ayuda a fijar un punto de verdad en el propio nodo.
cuando el error desde el navegador es demasiado vago#
Hay mensajes de navegador que no ayudan en nada. Un timeout, un reset, un error TLS, una carga infinita. Todo eso puede significar cosas muy distintas.
Antes de intentar traducir el drama del navegador, yo prefiero hacer una pregunta más simple al servidor.
¿Estás escuchando o no?
qué hago según lo que salga#
Aquí el comando es especialmente bueno porque la bifurcación es limpia.
si sale pveproxy escuchando en *:8006#
Mi lectura es bastante directa.
La puerta local está abierta.
Eso no me deja cantar victoria, pero sí descarta un montón de cosas. A partir de ahí suelo mirar estas piezas.
systemctl status pveproxy --no-pagerpara ver el estado del serviciocurl -k https://127.0.0.1:8006/desde el propio nodo para confirmar respuesta local HTTPS- firewall local o intermedio si la conexión falla desde fuera
- certificados o terminación TLS si hay un proxy delante
- problemas de red entre cliente y nodo
Lo importante es que ya no estoy ciego. El nodo escucha. Bien. Siguiente capa.
si no sale nada#
Aquí la cosa cambia bastante.
Si el comando no devuelve ninguna línea, para mí la sospecha principal pasa rápido a pveproxy o a cualquier problema local que impida abrir ese socket.
Entonces voy casi de cabeza a esto.
systemctl status pveproxy --no-pagerjournalctl -u pveproxy -n 100 --no-pager- comprobar si el servicio ha arrancado de verdad o ha fallado a medio camino
Eso me parece mucho más sensato que pelearme con el navegador mientras el puerto ni siquiera existe en escucha.
lo que este comando sí me dice#
Me dice si el nodo escucha en el puerto 8006.
Me dice si el bind es en todas las interfaces o no.
Me dice qué proceso está detrás de esa escucha.
Y me ayuda a separar un problema local del servicio de un problema de acceso desde fuera.
Para un solo comando me parece un rendimiento estupendo.
lo que este comando no me puede contar#
Aquí conviene no enamorarse demasiado de la simplicidad.
Que ss -ltnp | grep 8006 enseñe un LISTEN correcto no significa que el panel funcione perfecto desde tu portátil.
No me garantiza que el certificado sea válido.
No me garantiza que una ACL o firewall no esté cortando el tráfico.
No me garantiza que una capa intermedia no esté rompiendo TLS.
No me garantiza que el panel responda con agilidad.
No me garantiza siquiera que pvedaemon o pve-cluster estén finos.
Solo me da una verdad local sobre el socket. Pero esa verdad local vale muchísimo cuando estás intentando ordenar una avería.
un detalle que me parece clave, escuchar no es lo mismo que responder bien#
Esto lo remarco porque he visto el error muchas veces.
Hay gente que ve el socket en escucha y concluye que ya está todo bien. Tampoco.
Puedes tener pveproxy escuchando y aun así sufrir un servicio inestable, problemas de certificados, fallos de backend o un panel que responde fatal. Por eso este comando no sustituye a systemctl status pveproxy. Lo complementa.
A mí me gusta porque responde la primera pregunta. Luego ya vienen las demás.
Primero confirmo que hay puerta.
Después confirmo si la puerta está sana.
Y solo después me voy a culpar a la calle, que suele ser donde terminamos antes de tiempo.
cómo lo combino con otros comandos de esta serie#
Mi secuencia corta suele ser muy simple.
ss -ltnp | grep 8006systemctl status pveproxy --no-pagersystemctl status pvedaemon --no-pagersystemctl status pve-cluster --no-pager- si sigue oliendo raro, logs y pruebas HTTPS locales
Ese orden me gusta porque baja el dramatismo del troubleshooting. Empiezo por el socket, sigo por el servicio web, luego reviso la capa de acciones y después miro la parte de cluster compartido.
No siempre hace falta llegar al paso cinco. Muchas veces el propio ss ya te dice si vas por el camino correcto o no.
una opinión personal, demasiada gente olvida mirar el socket#
Yo creo que esto pasa porque no es un comando lucido.
No da para capturas impresionantes. No suena sofisticado. No parece un truco de veterano. Es solo una comprobación concreta de puerto y proceso.
Pero precisamente por eso me gusta tanto.
Cuando un sistema se pone pesado, las preguntas pequeñas suelen valer más que las teorías elegantes. ¿Escucha el 8006? ¿Sí o no? Esa respuesta te coloca mucho mejor que una discusión de diez minutos sobre si el navegador cacheó algo raro.
No digo que lo demás no importe. Digo que hay un orden sensato para mirar las cosas. Y el socket del panel está demasiado cerca del problema como para ignorarlo.
cómo encaja con otros posts relacionados#
Este comando me parece el puente perfecto entre mirar el servicio y mirar la experiencia desde fuera.
- systemctl status pveproxy en Proxmox: cómo separo un panel web caído de un cluster que en realidad sigue bien
- systemctl status pvedaemon en Proxmox: qué miro cuando tareas, consola o acciones del nodo empiezan a ir raras
- systemctl status pve-cluster en Proxmox: cómo compruebo pmxcfs antes de culpar a la web o a /etc/pve
- pvesh get /cluster/status en Proxmox: la vista cruda que miro cuando la interfaz parece demasiado tranquila
Entre todos, me dejan una secuencia que me resulta muy cómoda.
ss me dice si hay alguien escuchando.
pveproxy me dice si el servicio web está bien plantado.
pvedaemon me ayuda si la web carga, pero las acciones ya van raras.
pve-cluster entra cuando sospecho de la parte compartida.
Es un orden bastante poco romántico. También bastante eficaz.
mi conclusión#
ss -ltnp | grep 8006 es una de esas comprobaciones pequeñas que me ahorran un montón de diagnósticos flojos. No tiene épica ni pretende tenerla. Solo me enseña si el nodo de Proxmox está escuchando en el puerto del panel y qué proceso está detrás.
Y con eso ya puedo pensar mucho mejor.
Si el 8006 no existe, dejo de culpar a la red antes de tiempo.
Si el 8006 está escuchando con pveproxy, dejo de culpar al nodo por defecto y empiezo a mirar el camino con más criterio.
En un homelab con capas, túneles y demasiadas ganas de sacar conclusiones rápidas, esa disciplina me parece casi obligatoria.
referencias#
- Manual de
ssen man7.org - Documentación oficial de pveproxy
- Post relacionado: systemctl status pveproxy en Proxmox: cómo separo un panel web caído de un cluster que en realidad sigue bien
- Post relacionado: systemctl status pve-cluster en Proxmox: cómo compruebo pmxcfs antes de culpar a la web o a /etc/pve
- Post relacionado: systemctl status pvedaemon en Proxmox: qué miro cuando tareas, consola o acciones del nodo empiezan a ir raras