Hay una comprobación que hago muchísimo cuando el panel web de Proxmox se pone raro y todavía no sé si estoy delante de una avería seria o de una pérdida de tiempo con mucho teatro.
La hago desde el propio nodo.
| |
A veces la versión corta que tengo en la cabeza es simplemente esta.
| |
Luego le añado -s, -o /dev/null y -D - porque lo que quiero ver de verdad son las cabeceras y el código de respuesta, no el HTML entero del login. Pero la idea es la misma. Le estoy preguntando al propio nodo si su panel responde por HTTPS desde dentro.
Me gusta porque corta mucho ruido.
Si el nodo responde localmente con un 200 OK, ya sé que el problema no es tan simple como “Proxmox está caído”. Puede seguir habiendo problemas, claro. Puede haber un firewall en medio, un túnel que hace cosas raras, un certificado que molesta, un proxy inverso roto o un cliente que está viendo fantasmas. Pero ya no estoy ciego. Tengo una verdad local bastante útil.
Y cuando estás diagnosticando acceso web, las verdades locales valen oro.
por qué esta prueba me gusta tanto#
Porque responde a una pregunta muy concreta.
No me resume el cluster. No me habla de pvedaemon. No me dice nada sobre Corosync ni storage ni HA. Solo me confirma si el propio endpoint HTTPS del panel responde cuando lo atacas desde dentro del nodo.
Eso me parece una pregunta buenísima porque la mitad de las discusiones absurdas empiezan justo donde no toca. Vemos un timeout desde el navegador y ya arrancamos con DNS, firewall, certificado, Cloudflare, VPN, proxy, ACL, browser cache y el resto del circo. Todo eso puede influir, sí. Pero antes de montar la novela, prefiero preguntarle al propio nodo si se sirve a sí mismo.
Si no puede hacerlo, el problema está bastante cerca del suelo.
Si sí puede hacerlo, la investigación cambia por completo.
la captura real que me basta para orientarme#
Esta salida sale de un nodo real de mi lab, saneada para no enseñar nada interno que no aporte valor fuera de casa.
No es una captura espectacular. Mejor.
Veo HTTP/1.1 200 OK.
Veo Server: pve-api-daemon/3.0.
Veo que responde como HTML en UTF-8 y que el tamaño del documento es razonable para una página de acceso.
Con eso, para una primera lectura, ya tengo bastante.
El nodo está levantando el panel localmente. El socket no solo existe, también responde de forma coherente por HTTPS. Eso me deja una conclusión muy simple. Si desde mi portátil no carga, probablemente tengo que mirar el camino hasta el nodo o una capa intermedia, no quedarme girando alrededor del propio Proxmox como si fuese el único sospechoso.
qué confirma de verdad una respuesta 200 OK#
Aquí conviene no liarse.
Un 200 OK local no significa que todo esté perfecto. Significa algo más concreto y mucho más útil.
pveproxyestá escuchando y respondiendo- la pila HTTPS local no está completamente rota
- el propio nodo puede servirse el panel a sí mismo
- la URL base
/devuelve una respuesta válida
Eso ya me permite separar dos mundos.
El primero es el mundo del fallo local del servicio. Si curl local falla, me quedo dentro del nodo. Voy a systemctl status pveproxy, a journalctl -u pveproxy, a mirar el 8006 y a revisar dependencias.
El segundo es el mundo del fallo de acceso. Si curl local responde bien, entonces dejo de tratar al nodo como culpable único y me voy a red, cliente, reverse proxy, túnel, TLS externo o políticas intermedias.
Esa bifurcación me parece mucho más valiosa que muchas comprobaciones más bonitas de enseñar.
por qué uso -k aquí y por qué fuera del nodo no me gusta tanto#
Lo de -k merece una explicación corta porque a veces se usa como martillo para todo.
Aquí lo uso a propósito porque estoy haciendo una prueba local de disponibilidad y respuesta, no una auditoría del certificado. Quiero saber si el panel responde por HTTPS desde el propio nodo aunque el certificado no cuadre con 127.0.0.1.
Eso es completamente normal.
En muchos nodos el certificado está pensado para el hostname o para una IP concreta de gestión, no para loopback. Si hago la prueba contra 127.0.0.1 sin -k, puedo terminar discutiendo con la validación TLS cuando la pregunta real era otra.
Por eso aquí me parece bien usarlo.
Pero solo aquí, con intención clara.
Fuera del nodo prefiero no normalizar el -k porque tapa problemas reales. Si desde tu cliente necesitas ignorar el certificado para que algo funcione, ya no estás haciendo una simple prueba local. Estás escondiendo una avería o una mala configuración que conviene mirar de frente.
cómo leo las cabeceras sin complicarme la vida#
No necesito exprimir cada línea. Voy a unas pocas cosas.
HTTP/1.1 200 OK#
Esta es la línea grande.
Si no veo un 200, me paro.
Un 000 porque no conectó, un timeout, un reset o cualquier cosa de ese estilo ya me cambian totalmente la película. Y si sale un 5xx, peor todavía. Ahí la puerta existe pero algo del servicio está respondiendo mal.
Con un 200 OK, la lectura inicial es mucho más amable.
Server: pve-api-daemon/3.0#
Esta línea me gusta mucho porque me confirma quién está respondiendo. No es una web cualquiera. No es un servicio raro ocupando el puerto. Estoy hablando con la pieza que espero ver detrás del panel.
Eso refuerza la idea de que la capa base del acceso web está viva.
contenido HTML en UTF-8#
No es la línea más sexy, pero sí me orienta. Estoy recibiendo HTML, justo lo esperable si estoy pidiendo la raíz del panel web.
Si aquí viera algo extraño, empezaría a sospechar de redirecciones raras, middlewares o respuestas que no tocan.
Content-Length#
No me obsesiono con el número exacto. Solo quiero ver que tiene una pinta razonable.
Si el contenido tiene unos pocos bytes, me pongo en guardia. Si tiene un tamaño creíble para la página inicial, me tranquiliza bastante.
En esta prueba el tamaño cuadra. No tengo la sensación de estar recibiendo un error feo disfrazado de respuesta válida.
cuándo lanzo yo esta prueba casi en automático#
cuando el panel no carga desde fuera, pero el SSH sí#
Este es el caso clásico.
Puedo entrar por SSH. El nodo responde. Pero el panel desde mi equipo se queda pensando, falla con TLS o directamente no carga. Antes de tocar nada más, hago el curl local.
Me ahorra muchas conclusiones precipitadas.
cuando ss -ltnp | grep 8006 me enseña escucha, pero todavía no me fío#
Esto me pasa bastante.
El puerto 8006 está en LISTEN y detrás aparece pveproxy. Bien. Pero escuchar no es lo mismo que responder bien. Ahí es donde esta prueba me da el siguiente paso natural.
Primero confirmo puerta abierta.
Luego confirmo respuesta útil.
después de reiniciar o recargar pveproxy#
Si he tocado paquetes, certificados o la propia configuración del servicio web, quiero una comprobación muy tonta y muy rápida. Esta lo es.
No necesito abrir el navegador para saber si hay vida.
cuando hay un proxy inverso o un túnel delante#
Cuantas más capas pongas entre tú y el nodo, más valor tiene una prueba hecha dentro del propio nodo. Me da un punto de verdad limpio, sin adornos y sin interferencias.
lo que este comando sí me dice#
Me dice que el panel responde localmente por HTTPS.
Me dice qué código devuelve.
Me dice qué servicio firma la respuesta.
Me dice si la raíz del panel devuelve algo coherente.
Y me ayuda a separar un problema del servicio local de un problema de acceso desde fuera.
Para una sola línea de curl, me parece muchísimo.
lo que este comando no me dice#
También conviene bajarle un poco el drama positivo.
Que el nodo devuelva 200 OK localmente no significa que el panel funcione perfecto desde tu portátil.
No me garantiza que la red entre cliente y nodo esté bien.
No me garantiza que un firewall o ACL no esté bloqueando tráfico.
No me garantiza que un reverse proxy no esté rompiendo cabeceras, TLS o cookies.
No me garantiza que el navegador no esté tropezando con un certificado, con HSTS o con una sesión corrupta.
No me garantiza que pvedaemon esté fino si luego las acciones del nodo van raras.
No me garantiza que el cluster esté sano.
Solo me dice algo muy concreto. La respuesta local HTTPS del panel existe y parece razonable.
Y la verdad es que eso ya es muchísimo cuando el síntoma original era “no me carga la web”.
una opinión poco popular, el navegador mete demasiado ruido#
No tengo nada contra el navegador. Lo uso como todo el mundo. Pero en diagnóstico lo considero una fuente de ruido bastante peligrosa.
Te mezcla interfaz, caché, certificados, extensiones, sesión, política de seguridad y el estado real del servidor en una sola experiencia confusa. Y encima te lo presenta todo con mensajes bastante pobres.
Por eso me gusta tanto bajar un escalón y hablar con el nodo con algo tan seco como curl.
La conversación mejora enseguida.
No estoy interpretando una pantalla. Estoy leyendo una respuesta HTTP local.
No será glamuroso, pero es una base mucho más honesta para empezar.
cómo lo combino con otros comandos de esta serie#
Mi secuencia corta cuando el panel de Proxmox va raro suele ser esta.
ss -ltnp | grep 8006curl -k -s -o /dev/null -D - https://127.0.0.1:8006/systemctl status pveproxy --no-pagerjournalctl -u pveproxy -n 50 --no-pager- si hace falta,
systemctl status pvedaemon --no-pager
Ese orden me gusta porque cada paso responde una pregunta distinta.
ss me dice si el puerto existe.
curl me dice si el endpoint responde.
pveproxy me dice cómo está el servicio.
journalctl me enseña si hay reinicios, errores o comportamientos raros.
pvedaemon entra cuando la web carga, pero luego las acciones o la consola van mal.
No digo que sea la única secuencia buena. Digo que a mí me evita bastante mareo.
cómo encaja con otros posts relacionados#
Si estás siguiendo esta serie de comprobaciones rápidas en Proxmox, este comando encaja justo entre el socket y los logs.
- ss -ltnp | grep 8006 en Proxmox: cómo confirmo quién escucha el panel web antes de culpar a la red o al navegador
- 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
Entre todos me dejan una rutina muy fácil de recordar.
Primero pregunto si hay puerto.
Luego pregunto si ese puerto responde.
Después miro servicio y logs.
Y solo entonces me voy a capas más profundas o más lejanas.
Me parece una forma bastante sana de no convertir una tontería local en una investigación de tres cafés.
mi conclusión#
curl -k https://127.0.0.1:8006/ me parece una de las pruebas más rentables cuando el panel web de Proxmox entra en terreno sospechoso. No sustituye a otros comandos y no pretende hacerlo. Pero sí me da una respuesta local muy valiosa en segundos.
Si devuelve un 200 OK, sé que el nodo es capaz de servirse el panel a sí mismo. Eso no resuelve todo, pero recorta muchísimo el mapa del problema.
Si falla, también me alegro, dentro de lo razonable. Porque entonces dejo de perseguir teorías bonitas y me centro en el servicio local, que es justo donde toca mirar.
En homelab, donde es facilísimo perder tiempo en la capa equivocada, esa disciplina vale bastante más que muchos dashboards preciosos.
referencias#
- Documentación oficial de
pveproxy - Documentación oficial de
curl - Post relacionado: ss -ltnp | grep 8006 en Proxmox: cómo confirmo quién escucha el panel web antes de culpar a la red o al navegador
- 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 pvedaemon en Proxmox: qué miro cuando tareas, consola o acciones del nodo empiezan a ir raras