L’interface Web Proxmox n’ouvre pas sur le port 8006 : redémarrez pveproxy et récupérez l’accès

Playbook de diagnostic rapide

Quand le port 8006 est mort, vous cherchez un goulot d’étranglement, pas des impressions. Le chemin le plus rapide consiste à répondre à trois questions, dans l’ordre :

1) Quelque chose écoute-t‑il sur le 8006 ?

Si rien n’écoute, c’est généralement que pveproxy s’est arrêté, est bloqué, n’a pas pu se binder, ou n’a pas pu initialiser TLS. Si quelque chose écoute mais que vous ne pouvez pas vous connecter, c’est généralement un problème de firewall/routage/VRF/interface/IP.

2) Si pveproxy est arrêté, pourquoi ?

Ne redémarrez pas aveuglément un service qui plante en boucle — obtenez la raison depuis systemctl et journalctl. Les coupables habituels sont :

• Problèmes de certificat/clé
• Disque plein (surtout sur root)
• Problèmes du système de fichiers de cluster (pmxcfs)
• Épuisement des descripteurs de fichiers ou pression mémoire
• Conflits de port ou mauvaise configuration d’adresse de bind

3) Si pveproxy est actif, pourquoi le navigateur ne se connecte‑t‑il pas ?

Vérifiez d’abord la connectivité locale (curl depuis l’hôte), puis distante (depuis un autre nœud ou une station de travail), puis le firewall et le chemin réseau. L’interface Web n’est que HTTPS sur 8006. Traitez‑la comme n’importe quel autre service HTTPS.

Une citation opérationnelle qui a bien vieilli : « L’espoir n’est pas une stratégie. » — Simon Sinek. Ce n’est pas un traité sur la fiabilité, mais ça devrait faire partie de chaque rotation d’astreinte.

Ce qu’est réellement le port 8006 (et ce qu’il n’est pas)

L’interface Web de Proxmox VE est fournie par pveproxy, un proxy HTTP(S) qui parle aux démons backend (pvedaemon, pvestatd, et compagnons) et lit l’état du cluster via pmxcfs. Si vous perdez l’UI mais que les VM continuent de tourner, c’est normal : l’hyperviseur et les invités peuvent fonctionner alors que les composants de gestion échouent.

Le port 8006 n’est pas « le serveur Proxmox ». C’est le plan de gestion. Traitez‑le comme tel. Vous pouvez le réparer sans toucher aux VM en cours si vous évitez les actions lourdes (comme redémarrer l’hôte en plein scrub de stockage ou pendant une réélection de cluster).

Petite blague #1 : L’UI Proxmox qui tombe, c’est comme la radio de votre voiture qui meurt — le moteur tourne toujours, mais soudain tout le monde dans le véhicule devient ingénieur stockage.

Faits intéressants et contexte historique (parce que le contexte évite les erreurs stupides)

• Le port 8006 est une convention Proxmox, pas une norme universelle. Proxmox l’a choisi il y a des années pour éviter les conflits avec les ports web habituels et pour que « ça, c’est Proxmox » soit immédiatement reconnaissable.
• pveproxy utilise TLS par défaut, même sur des réseaux internes. C’était un choix pragmatique de sécurité : les plans de gestion se font attaquer, même quand on se dit « c’est seulement interne ».
• Le système de fichiers de cluster de Proxmox (pmxcfs) est un filesystem user‑space (FUSE) soutenu par Corosync. Quand il se comporte mal, les outils de gestion peuvent devenir étrangement cassés alors que les invités vont bien.
• Historiquement, beaucoup de pannes d’UI sont des défaillances « indirectes » : disque plein, synchronisation temporelle cassée, ou certificats périmés. L’UI est l’endroit où vous remarquez, pas forcément où ça a commencé.
• Systemd a changé la donne opérationnelle pour des services comme pveproxy : la vraie raison d’un échec se trouve presque toujours dans le journal, pas dans une sortie d’un script d’init vague.
• La régénération des certificats est routinière dans Proxmox. La plateforme suppose que les certificats peuvent être remplacés localement ; elle est conçue pour des appliances et des labos autant que pour des entreprises.
• La disponibilité des VM peut induire en erreur. KVM et QEMU se moquent que pveproxy soit down, ce qui est excellent pour les charges de travail et mauvais pour la complaisance.
• Les outages sur 8006 sont souvent auto‑infligés : durcissements firewall, scripts de « nettoyage », ou règles d’intrusion trop agressives qui n’ont pas été testées contre le trafic de gestion.

Tâches pratiques : commandes, sortie attendue et décision à prendre

Ce sont de vraies tâches que j’exécuterais sur un hôte « up » mais dont l’UI est morte. Chacune inclut ce que la sortie signifie et ce que vous faites ensuite. Exécutez les commandes en root (ou avec sudo). L’invite montrée est illustrative.

Task 1: Confirm basic host reachability and 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

Signification : Vous avez une IP, les interfaces sont up, et vous savez quelle adresse doit répondre pour l’UI.

Décision : S’il n’y a pas l’IP attendue (ou si le VLAN est incorrect), corrigez le réseau d’abord. Si l’IP est correcte, poursuivez.

Task 2: Check whether anything is listening on 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))

Signification : pveproxy écoute sur toutes les adresses IPv4.

Décision : Si aucune sortie, pveproxy n’écoute pas. Passez au statut du service et aux logs. S’il n’écoute que sur 127.0.0.1:8006, vous avez un problème de bind.

Task 3: Verify local HTTPS works from the 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

Signification : Le service Web répond localement. L’échec dans le navigateur peut être un problème réseau/firewall/DNS/route, pas pveproxy.

Décision : Si le curl local échoue avec « connection refused », concentrez‑vous sur pveproxy. S’il réussit, testez depuis une autre machine et vérifiez le firewall.

Task 4: Check systemd status for 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'.

Signification : pveproxy échoue à cause d’un chargement de certificat TLS.

Décision : Allez corriger les certificats (section plus bas). Si le statut indique « active (running) », passez au firewall/réseau. S’il indique « activating » indéfiniment, vérifiez les dépendances (pmxcfs, pvedaemon) et la pression sur les ressources.

Task 5: Read the journal for the last failure details

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

Signification : Le journal fournit une cause exploitable, pas seulement « failed ».

Décision : Réparez ce que le log indique. Ne redémarrez pas en boucle en faisant semblant d’avancer.

Task 6: Confirm pvedaemon is healthy (backend API)

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

Signification : Le backend tourne.

Décision : Si pvedaemon est down, redémarrez‑le et vérifiez son journal aussi ; pveproxy échoue parfois parce que son upstream est malsain.

Task 7: Confirm pmxcfs is mounted and responsive

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)

Signification : Le système de fichiers de cluster est monté sur /etc/pve.

Décision : S’il manque, beaucoup de fonctions de gestion Proxmox se cassent. Il faudra restaurer pve-cluster et la santé de corosync.

Task 8: Check disk space (root full is a silent killer)

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

Signification : Le filesystem root est plein. Les services échouent de manière étrange : écritures de logs impossibles, écriture de certificats impossible, sockets qui échouent.

Décision : Libérez de l’espace immédiatement (logs, anciens kernels avec prudence, cache). Puis redémarrez les services. Ne faites pas juste « reboot ». Rebooter sur un root plein n’est pas une guérison ; c’est du déni avec de l’uptime.

Task 9: Check whether the port is blocked by local firewall rules

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

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

Signification : Le firewall Proxmox est activé et a un réseau local défini.

Décision : Si le firewall est activé, inspectez les règles et confirmez que 8006 est autorisé depuis votre sous‑réseau de gestion.

Task 10: Inspect iptables/nftables for 8006 drops

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

Signification : Il y a un drop explicite sur 8006.

Décision : Supprimez ou surchargez correctement cette règle (idéalement via la configuration du firewall Proxmox, pas par chirurgie CLI aléatoire). Si vous n’aviez pas l’intention de bloquer, trouvez qui l’a fait.

Task 11: Test remote connectivity from another host (network path check)

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

Signification : Le handshake TCP fonctionne. Si le navigateur échoue encore, vous regardez un problème TLS/alerte de certificat, un proxy, ou un souci côté client.

Décision : Si ça échoue, isolez où : local marche mais distant pas → firewall ou routage. Local échoue aussi → pveproxy down ou problème de bind.

Task 12: Check for port conflicts

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))

Signification : Quelque chose d’autre (nginx ici) occupe 8006. pveproxy ne peut pas binder et échouera.

Décision : Arrêtez ou reconfigurez le service en conflit. Proxmox possède 8006 dans une installation par défaut. Ne le combattez pas à moins d’aimer la douleur.

Task 13: Validate TLS files exist and are readable

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

Signification : Les fichiers existent avec des permissions raisonnables (lisibles par le groupe www-data que pveproxy utilise).

Décision : Si les permissions sont mauvaises (world‑writable, manquantes, mauvais groupe), corrigez ou régénérez les certificats.

Task 14: Check time sync (cert validity and TLS handshakes can break)

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

Signification : Le temps n’est pas synchronisé ; NTP est inactif.

Décision : Réparez la synchronisation temporelle. Un mauvais temps peut rendre les certificats « pas encore valides » ou « expirés » et causer des erreurs client confuses.

Redémarrage de pveproxy (et des services dont il dépend)

Si pveproxy est down, le redémarrer est la bonne action. S’il plante à répétition, le redémarrer sans corriger la cause est du théâtre. Nous le ferons sérieusement : vérifier les dépendances, redémarrer dans le bon ordre, et confirmer que le listener revient.

The minimal safe restart

C’est l’action « j’ai besoin de l’UI maintenant » quand vous savez déjà que c’est un plantage transitoire, pas une défaillance profonde.

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

Signification : Le service a redémarré et est actif.

Décision : Vérifiez immédiatement qu’il écoute et sert du HTTPS, pas seulement qu’il est « active » dans 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))

The “management plane reboot” restart (order matters)

Si vous suspectez un problème plus profond dans la pile de gestion — bizarreries pmxcfs, sockets obsolètes, upgrades partiels — redémarrez les services concernés dans un ordre sain. Je préfère cette séquence sur un nœud unique :

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.

Signification : Rien n’est actuellement en échec selon systemd.

Décision : Si quelque chose reste en échec, arrêtez et lisez le journal pour cette unité. Ne continuez pas à empiler des redémarrages comme si vous vouliez décrocher une friandise coincée dans un distributeur.

When to restart corosync (and when not to)

Sur un cluster, redémarrer corosync peut déclencher une réélection et une instabilité de gestion brève. Si votre problème est isolé à l’UI d’un seul nœud, ne commencez pas par corosync. Confirmez d’abord la santé du montage /etc/pve. Si pmxcfs est cassé parce que corosync est bloqué, alors oui, vous devrez traiter corosync — mais c’est une étape délibérée.

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

Décision : Si corosync est down et que c’est un nœud de cluster, attendez des symptômes plus larges (pas de quorum, pas de mises à jour /etc/pve). Traitez‑le comme un incident de cluster, pas seulement « l’UI est down ».

Causes profondes : TLS, firewall, pmxcfs, pression de ressources et problèmes de bind

Quand 8006 est mort, la défaillance est presque toujours dans un de ces compartiments. La correction dépend du compartiment. La mauvaise nouvelle : ils peuvent se ressembler depuis un navigateur. La bonne nouvelle : Linux vous donne des preuves.

TLS/certificate failures: pveproxy can’t start or clients reject it

Signes courants :

• systemctl status pveproxy affiche des erreurs de chargement de certificat
• Le navigateur renvoie une erreur de handshake TLS (pas juste un avertissement)
• curl -k échoue avec des problèmes de handshake

La régénération du certificat auto‑signé est généralement sûre et rapide. Sur un noeud unique, faites :

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

Signification : Proxmox a régénéré les certificats et redémarré les services clés.

Décision : Si votre environnement utilise des certificats personnalisés, ne les écrasez pas avec --force sans vérification. Sinon vous « corrigerez l’UI » et casserez les chaînes de confiance pour l’automatisation et la supervision.

Pour vérifier rapidement les dates et le sujet du certificat :

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

Décision : Si les dates sont incorrectes, réparez la synchronisation temporelle. Si le fichier ne se parse pas, régénérez ou restaurez.

Firewall blocks: pveproxy is fine, but nobody can reach it

C’est là que les équipes gaspillent des heures parce que « le service est up ». Oui, localement. Le réseau peut toujours vous pourrir la journée.

Vérifiez d’abord depuis l’hôte Proxmox qu’il écoute. Puis vérifiez s’il est atteignable depuis le réseau client. S’il est bloqué, regardez les règles du firewall Proxmox et le nftables/iptables sous‑jacent.

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

Signification : Les règles du firewall se compilent correctement. Ça ne signifie pas qu’elles sont correctes ; ça signifie qu’elles sont syntaxiquement valides.

Décision : Si la compilation échoue, corrigez la config. Si elle réussit mais vous bloque, ajustez les règles pour votre sous‑réseau de gestion et autorisez explicitement TCP/8006.

Vérification rapide des drops pendant que vous tentez une connexion :

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 ...

Décision : Si vous voyez des drops kernel vers 8006 depuis votre IP source, arrêtez de blâmer pveproxy. Corrigez le chemin firewall.

pmxcfs and cluster weirdness: /etc/pve is the hidden dependency

Si /etc/pve n’est pas monté, la gestion Proxmox devient une maison hantée. pveproxy peut démarrer mais ne pas lire la config attendue ; ou il peut ne pas trouver les certificats sous /etc/pve/local.

Vérifiez l’état du filesystem de cluster :

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

Décision : Si pve-cluster échoue, vérifiez son journal. Sur un nœud unique sans corosync, il peut encore fonctionner en mode local, mais corruption ou disque plein peuvent le casser.

Resource pressure: memory, file descriptors, CPU steal

Les services de gestion sont petits, mais pas magiques. Si l’hôte swappe, est bloqué en IO wait, ou manque de descripteurs, pveproxy peut démarrer puis mourir, ou ne jamais accepter correctement les connexions.

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

Décision : Si le swap est fortement utilisé et la mémoire disponible minime, vous êtes dans un crash au ralenti. Réduisez la charge, stoppez les processus hors de contrôle, envisagez de migrer des VM, puis redémarrez les services de gestion.

cr0x@server:~$ ulimit -n
1024

Signification : La limite d’ouverture de fichiers du shell courant est basse. Les services peuvent avoir leurs propres limites, mais si le système est globalement contraint, vous verrez des échecs étranges.

Décision : Si vous suspectez une exhaustion de FD, vérifiez les comptes dans /proc et les limites système ; ne montez pas les limites au hasard sans comprendre pourquoi elles ont été atteintes (c’est souvent une fuite ou un client abusif).

Bind address problems: pveproxy listens only on localhost or the wrong interface

Parfois pveproxy est up, mais il est bindé d’une manière qui le rend inaccessible à distance. Vous le verrez dans la sortie 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))

Signification : Il n’écoute que sur le loopback. Les clients distants ne se connecteront jamais.

Décision : Cherchez une config proxy personnalisée ou des variables d’environnement qui forcent le bind. Dans beaucoup de cas, c’est quelqu’un qui a « temporairement » lié les services à localhost pour des tests et a oublié. Les changements temporaires ont un plan de retraite convaincant : ils ne partent jamais.

DNS and browser-side issues: your laptop is lying to you

Si l’IP directe fonctionne mais que le nom d’hôte ne fonctionne pas, vous avez un problème DNS ou split‑horizon. Si votre navigateur met en cache HSTS ou a épinglé un certificat, vous pouvez avoir des erreurs côté client même après réparation côté serveur. Vérifiez avec curl depuis un hôte neutre et testez via IP.

cr0x@server:~$ getent hosts server
10.10.20.11     server

Décision : Si le nom d’hôte résout vers la mauvaise IP, corrigez les entrées DNS/hosts et arrêtez de deviner.

Trois mini-récits du monde de l’entreprise (anonymisés, plausibles et douloureusement familiers)

Mini-récit 1 : La panne causée par une mauvaise hypothèse

Ils avaient un petit cluster Proxmox supportant des outils internes : runners CI, quelques bases de données, et un NFS « temporaire » qui avait survécu à trois réorganisations. Un matin, l’UI était down sur un nœud. L’astreinte a supposé que c’était un hic habituel de pveproxy et a redémarré pveproxy et pvedaemon.

Rien n’a changé. Ils ont donc escaladé en « problème réseau », parce qu’ils pouvaient pinguer l’hôte mais ne pouvaient pas charger l’UI. Ils ont passé une heure à regarder des ports de switch, à poursuivre des fantômes VLAN. Pendant ce temps, les VM tournaient, ce qui a rendu tout le monde suffisamment confortable pour considérer l’incident comme non urgent.

La mauvaise hypothèse était subtile : « Si je peux le pinguer, l’UI devrait marcher. » Ping ne vous dit presque rien sur la reachabilité TCP, les drops firewall, ou si le service écoute sur la bonne interface. Ils n’avaient pas vérifié ss -lntp ou curl -kI localement. Ils n’avaient pas non plus regardé nftables.

La cause réelle : un changement de durcissement de sécurité déployé via l’automatisation a ajouté une règle nftables pour dropper l’inbound 8006 depuis les « réseaux non‑admin ». La définition du réseau admin était erronée d’un subnet. Les tests locaux marchaient. Le distant non.

La correction a pris cinq minutes une fois qu’ils ont cessé de deviner : vérifier le listener, confirmer que le curl local marche, confirmer l’échec TCP distant, repérer le drop nft, corriger le localnet/règle, recompiler. Ils ont rédigé un postmortem qui n’a pas blâmé le firewall. Il a blâmé l’hypothèse.

Mini-récit 2 : L’optimisation qui a mal tourné

Une autre équipe a décidé de vouloir un accès de gestion « plus propre ». Ils ont placé un reverse proxy devant Proxmox pour unifier l’accès sous un domaine interne unique et obtenir de plus beaux certificats. Objectifs raisonnables.

Puis est venue l’optimisation : ils ont activé des timeouts agressifs et des limites de connexions sur le reverse proxy parce que « l’UI n’est qu’un tableau de bord, ce n’est pas critique ». Ça fonctionnait jusqu’à ce qu’un nœud devienne chargé et que les appels API prennent plus de temps. Le proxy a commencé à couper les connexions en plein vol, ce qui faisait que les navigateurs se comportaient comme si l’UI Proxmox était cassée.

En parallèle, ils ont restreint les suites de chiffrement. Certains scripts d’automatisation anciens (clients curl embarqués dans des agents de build legacy) ont commencé à échouer à s’authentifier. Les gens « ont corrigé » en contournant le proxy et allant directement sur :8006 sur l’IP du nœud, créant un schéma d’accès split‑brain non documenté.

Un jour la config du proxy a été mise à jour, et quelqu’un a aussi changé le certificat Proxmox. L’UI était accessible parfois, depuis certains clients, selon le chemin utilisé. L’équipe a perdu une journée à se disputer pour savoir si Proxmox était instable.

Proxmox n’était pas instable. Leur optimisation a changé le mode d’échec de « le nœud est lent » à « l’accès de gestion est incohérent ». C’est pire. Ils ont rollbacké les limites de connexion, ajusté les timeouts pour coller à la réalité, et standardisé un seul chemin d’accès avec des health checks qui touchent vraiment / sur 8006 et valident une réponse 200.

Mini-récit 3 : La pratique ennuyeuse mais correcte qui a sauvé la mise

Une autre organisation faisait tourner Proxmox de façon plutôt conservative : VLAN de gestion séparé, IP documentées, et l’habitude de tester la reachabilité de l’UI depuis une box de monitoring chaque minute. Rien de fantaisiste. Juste « est‑ce que HTTPS sur 8006 répond ».

Ils avaient aussi un runbook ennuyeux qui commençait par : vérifier le listener, vérifier le status systemd, vérifier le journal, vérifier le disque, vérifier le firewall. Ça ressemblait à quelque chose qu’un SRE fatigué aurait écrit un mardi. Ce qui est exactement la bonne personne pour écrire des runbooks.

Un après‑midi, le monitoring a alerté : « Proxmox UI down sur node3 ». L’astreinte s’est connectée en SSH (qui était sur un chemin d’accès différent) et a suivi le runbook. df -h / montrait root à 100 %. Journald loggait toujours, mais les services ne pouvaient plus écrire d’état et les mises à jour TLS échouaient.

Ils ont libéré de l’espace en tronquant d’anciens logs et en supprimant quelques ISO inutilisés placés au mauvais endroit. Puis ils ont redémarré pveproxy et confirmé que curl -kI retournait 200. L’UI est revenue en 15 minutes, sans reboot et sans interruption des VM.

La « pratique » qui les a sauvés n’était pas un outil sophistiqué. C’était deux choses : monitorer le plan de gestion séparément de la santé des VM, et avoir un runbook qui ne commence pas par de la prière.

Erreurs fréquentes (symptôme → cause racine → correction)

Voici des schémas que vous verrez régulièrement. Les symptômes se recoupent. Les corrections, non.

1) Le navigateur affiche « connection refused » immédiatement

• Symptôme : Échec instantané ; pas d’avertissement TLS ; pas de timeout.
• Cause racine : Rien n’écoute sur 8006, ou le port est bloqué par un REJECT.
• Correction : Lancez ss -lntp | grep :8006. Si vide, redémarrez pveproxy et vérifiez le journal. S’il écoute, inspectez les règles firewall et le chemin distant.

2) Le navigateur finit par timeout (tourne indéfiniment)

• Symptôme : Longue attente ; finalement timeout.
• Cause racine : DROP firewall sur le chemin, problème de routage, mauvais VLAN, ou asymétrie ; parfois l’hôte est surchargé et la file d’accept ne sert pas.
• Correction : Testez le TCP avec nc -vz depuis un client, vérifiez les logs/drops nftables, validez les routes. Si la charge hôte est extrême, réduisez la charge et réessayez.

3) L’UI se charge mais l’authentification échoue ou les tâches bloquent

• Symptôme : La page de login apparaît, mais les opérations échouent ou vous voyez des erreurs style « 501 »/« proxy error ».
• Cause racine : Problèmes des démons backend (pvedaemon), latence de pmxcfs, problèmes de quorum de cluster.
• Correction : Vérifiez systemctl status pvedaemon pve-cluster, inspectez les journaux, validez la santé du cluster. Redémarrez les services de gestion dans l’ordre.

4) Après un « nettoyage », pveproxy ne démarre plus (erreurs de certificat)

• Symptôme : Le journal affiche /etc/pve/local/pve-ssl.pem ou la clé manquante/inaccessible.
• Cause racine : Quelqu’un a supprimé des fichiers sous /etc/pve, ou les permissions ont changé, ou pmxcfs n’est pas monté.
• Correction : Assurez‑vous que /etc/pve est monté ; régénérez les certificats avec pvecm updatecerts --force (après avoir confirmé que vous acceptez de remplacer).

5) L’UI a cassé juste après l’activation du firewall Proxmox

• Symptôme : Le curl local marche, le distant échoue ; les changements coïncident avec l’activation du firewall.
• Cause racine : Règle allow manquante pour TCP/8006 depuis le subnet admin, ou localnet mal configuré.
• Correction : Corrigez localnet, ajoutez un allow explicite pour 8006, recompilez et rechargez le firewall.

6) L’UI a cassé juste après l’installation de nginx/apache « pour autre chose »

• Symptôme : pveproxy ne peut pas binder ; les logs mentionnent address already in use.
• Cause racine : Un autre service a saisi le port 8006 ou a fait un bind wildcard sur l’IP de gestion.
• Correction : Identifiez le listener avec ss -lntp, déplacez l’autre service, redémarrez pveproxy.

7) L’UI affiche des échecs de handshake TLS après un changement d’heure système

• Symptôme : Erreurs client du type « certificate not yet valid » ou pannes TLS abruptes.
• Cause racine : Dérive temporelle ou NTP désactivé ; la validité des certificats ne correspond plus à la réalité.
• Correction : Réparez NTP/synchronisation temporelle, puis régénérez les certificats si nécessaire, redémarrez pveproxy.

Petite blague #2 : Redémarrer des services au hasard sans lire les logs, c’est comme rebooter votre grille‑pain pour réparer le Wi‑Fi — parfois satisfaisant, rarement efficace.

Checklists / plan étape par étape

Checklist A : « J’ai besoin de l’UI en 10 minutes »

1. SSH sur le nœud (préférablement via le réseau de gestion).
2. Vérifiez le listener : ss -lntp | grep :8006.
3. Si ça n’écoute pas : systemctl status pveproxy et journalctl -u pveproxy -n 100.
4. Corrigez l’évident (disque plein, certificat manquant, conflit de port).
5. Redémarrez dans l’ordre : systemctl restart pve-cluster pvedaemon pvestatd pveproxy.
6. Vérifiez localement : curl -kI https://127.0.0.1:8006/.
7. Vérifiez à distance : nc -vz <node-ip> 8006 depuis une machine cliente.

Checklist B : « Trouver la cause racine pour que ça ne se reproduise pas »

1. Récupérez le dernier temps de boot et la timeline des redémarrages.
2. Inspectez journald pour pveproxy et pve-cluster autour de la fenêtre d’incident.
3. Vérifiez les tendances d’utilisation disque ; identifiez ce qui a rempli root (logs, backups, ISOs au mauvais endroit).
4. Validez la configuration de time sync et l’historique de dérive.
5. Auditez les changements firewall : configs Proxmox et diffs du ruleset nftables.
6. Confirmez la stratégie de gestion des certificats : auto‑signés vs CA managée, pratiques de rotation.
7. Ajoutez du monitoring qui vérifie HTTPS 8006 depuis le même segment réseau que les humains utilisent.

Checklist C : « Considérations cluster (ne pas créer une panne plus large) »

1. Avant de toucher corosync, évaluez si c’est isolé à un nœud ou cluster‑wide.
2. Vérifiez le statut de quorum depuis un nœud sain si possible.
3. Si /etc/pve est corrompu sur un nœud, traitez‑le comme un problème d’état de cluster, pas seulement d’UI.
4. Évitez de rebooter plusieurs nœuds « pour être sûr ». C’est ainsi que vous découvrez ce que signifie le quorum à 2 h du matin.

FAQ

1) Quel service sert réellement l’interface Web Proxmox ?

pveproxy. Il écoute sur TCP/8006 et proxy les requêtes API vers des démons backend comme pvedaemon.

2) Si je redémarre pveproxy, est‑ce que ça interrompra les VM en cours ?

Non. Redémarrer les services de gestion n’arrête pas les invités QEMU/KVM. Cela peut interrompre brièvement les tâches de gestion (sessions console, appels API).

3) L’UI est down, mais SSH marche. Qu’est‑ce que ça implique ?

Cela implique que l’hôte est vivant et joignable, et que vous pouvez dépanner localement. Ça n’implique pas que le firewall autorise 8006, ni que pveproxy écoute.

4) Comment savoir si c’est un problème de firewall ou de service ?

Vérifiez d’abord localement : curl -kI https://127.0.0.1:8006/. Si le local marche mais le distant échoue, suspectez le firewall/routage. Si le local échoue, suspectez pveproxy ou ses dépendances.

5) Puis‑je déplacer l’UI sur un autre port ?

Vous pouvez, mais vous ne devriez probablement pas. Proxmox suppose 8006 dans de nombreuses pratiques opérationnelles et outils. Si vous devez le frontaler, faites‑le avec un reverse proxy bien testé et gardez 8006 accessible sur le réseau de gestion.

6) Pourquoi pveproxy se préoccupe‑t‑il de /etc/pve ?

Parce que Proxmox stocke la configuration cluster‑wide et le matériel de certificats locaux sous /etc/pve (via pmxcfs). Si pmxcfs est cassé, pveproxy ne peut pas lire de façon fiable ce dont il a besoin.

7) J’ai régénéré les certificats et maintenant l’automatisation échoue. Que s’est‑il passé ?

Votre automatisation a probablement épinglé l’ancien fingerprint de certificat ou faisait confiance à une chaîne spécifique. La régénération change cela. Décidez d’une stratégie de certificats : soit faire confiance de façon cohérente à la CA auto‑signée Proxmox, soit déployer une approche de certificats gérée et documentée.

8) Le service est « active (running) » mais je ne peux toujours pas me connecter. Pourquoi ?

Parce que « active » ne veut pas dire « reachable ». Il peut être bindé uniquement sur localhost, bloqué par le firewall, ou accessible seulement via IPv6 alors que vous utilisez IPv4 (ou inversement). Vérifiez avec ss -lntp et des tests réseau.

9) Dois‑je rebooter l’hôte pour réparer l’UI ?

Le reboot est le dernier recours. Il peut aider si le système est sérieusement bloqué, mais il peut aussi amplifier un incident de cluster, interrompre des opérations de stockage, et masquer la vraie cause. Récupérez les logs d’abord.

10) Et si le port 8006 est ouvert mais que l’UI est extrêmement lente ?

Cela vient typiquement de charge, IO wait, latence pmxcfs, ou contention des démons backend. Vérifiez mémoire et swap, latence disque, et journalctl pour des timeouts. Lent n’est pas la même chose que down, mais c’est souvent la même cause racine : un hôte sous contrainte.

Conclusion : prochaines étapes pour éviter ce bazar

Quand l’UI Proxmox sur 8006 s’éteint, le meilleur gain rapide est une triage discipliné : vérifiez le listener, validez le HTTPS local, lisez le journal, puis décidez si vous réparez pveproxy, ses dépendances, ou le chemin réseau. Redémarrer pveproxy est souvent correct. Le redémarrer aveuglément, c’est transformer un petit incident en un casse‑tête.

Faites ces choses ensuite :

• Ajoutez du monitoring qui vérifie https://<mgmt-ip>:8006/ depuis le même segment réseau que les humains utilisent.
• Conservez une marge sur le filesystem root. Un « presque plein » root est une panne retardée avec de la paperasse.
• Décidez d’une gestion des certificats (auto‑signés vs gérés) et tenez‑vous y.
• Traitez les changements firewall comme du code de production : review, tests, et plan de retour arrière.
• Gardez un runbook court : ss → systemctl → journalctl → df → vérifs firewall. La répétabilité bat l’héroïsme.