Proxmox « Connexion refusée » sur le port 8006 après mises à jour : que vérifier en premier

Playbook de diagnostic rapide (10 premières minutes)

C’est l’ordre qui minimise le temps pour atteindre la cause racine en production. Il est biaisé vers les pannes qui surviennent juste après des mises à jour : problèmes de redémarrage de services, certificats, changements de pare‑feu et dépendances de cluster.

Minute 0–2 : Confirmer que le symptôme est local et pas « le réseau »

1. Depuis votre poste : est‑ce que ssh fonctionne ? Si SSH échoue aussi, ce n’est pas un problème « 8006 » ; c’est routage, lien, IP ou hôte hors ligne.
2. Depuis l’hôte Proxmox lui‑même : testez son propre port 8006 avec curl. S’il ne peut pas s’atteindre, votre problème est presque certainement pveproxy qui n’écoute pas ou qui est bloqué localement.

Minute 2–5 : Vérifier si quelque chose écoute sur 8006

1. Utilisez ss pour voir si 8006 est lié. Si rien n’écoute, ne touchez pas encore aux pare‑feu. Réparez d’abord pveproxy.
2. Vérifiez systemctl status pveproxy. S’il est en échec, lisez l’erreur et allez directement aux logs (journalctl -u pveproxy).

Minute 5–7 : Valider les dépendances de la pile de gestion

1. Vérifiez pvedaemon et pvestatd. L’interface peut « se connecter » mais sembler cassée si ces services sont morts ; toutefois « connexion refusée » est généralement pveproxy.
2. Vérifiez l’espace disque et la pression sur les inodes. Des systèmes de fichiers racine pleins et des partitions de logs saturées tuent les démons de façon peu élégante.

Minute 7–10 : Pare‑feu, puis cluster, puis certificats

1. Pare‑feu : confirmez que pve-firewall ainsi que les règles nftables/iptables ne rejettent pas tcp/8006.
2. État du cluster : si cet hôte fait partie d’un cluster, le quorum et corosync peuvent indirectement bloquer la gestion (surtout autour du système de fichiers de configuration).
3. Certificats : une clé/certificat SSL cassé ou illisible peut empêcher pveproxy de démarrer.

Faites ceci dans l’ordre. Si vous commencez par « juste tout redémarrer », vous pouvez transformer une panne propre en bazar. Oui, je sais que redémarrer donne l’impression d’être productif. C’est aussi la version adulte de souffler sur une cartouche de Nintendo.

Ce que « Connexion refusée » signifie vraiment sur le port 8006

Les navigateurs sont dramatiques. « Connexion refusée » n’est pas « lent », pas une « erreur TLS » et pas une « authentification échouée ». C’est généralement une des trois choses :

• Aucun processus n’écoute sur cet IP:port. Le noyau répond par un RST (reset) et votre client rapporte « refusé ».
• Un pare‑feu local rejette activement la connexion (souvent aussi par RST). C’est plus rare que l’on pense, mais ça arrive — surtout avec des règles modifiées pendant des mises à jour.
• Un décalage reverse‑proxy / activation de socket (moins courant). Pour Proxmox, le démon concerné est pveproxy, qui se lie sur 8006 et gère TLS.

Si le problème était « bloqué » (DROP), vous verriez plus souvent des timeouts. Si c’était « TLS cassé », vous vous connecteriez et verriez habituellement une erreur de certificat, pas « refusé ». Traitez donc « refusé » comme un signal fort : le port n’est pas joignable au niveau accept TCP.

Il existe aussi une variante subtile : 8006 écoute, mais seulement sur la mauvaise interface (par exemple lié à 127.0.0.1). Cela peut toujours ressembler à un refus depuis l’extérieur. Nous vérifierons cela explicitement.

Faits et contexte intéressants (parce que ça a une histoire)

• Le port 8006 n’a pas été choisi pour l’esthétique. Historiquement Proxmox a utilisé un port élevé non standard pour éviter des conflits avec d’autres piles web sur le même hôte.
• pveproxy est un démon Perl. Ce n’est pas tendance, mais c’est éprouvé et étroitement intégré à l’API et à la pile d’authentification de Proxmox.
• Proxmox repose sur Debian. Beaucoup d’incidents « après mises à jour » proviennent en réalité de changements au niveau Debian : noyau, libc, OpenSSL, comportement systemd.
• Le backend pare‑feu de Proxmox a évolué. La transition plus large de Debian d’iptables vers nftables a été une source récurrente de « les règles existent, mais pas là où vous pensez ».
• La config du cluster est un système de fichiers. La configuration du cluster Proxmox vit dans un système de fichiers de configuration distribué (pmxcfs), et quand il est mal en point, les workflows de gestion deviennent rapidement bizarres.
• Les valeurs par défaut TLS sont devenues plus strictes. OpenSSL et bibliothèques associées déprécient régulièrement d’anciens chiffrements/protocoles ; les démons qui ne peuvent pas charger correctement clés/certs échouent violemment.
• Systemd a rendu les services plus observables. C’est la bonne nouvelle. La mauvaise, c’est qu’il a aussi rendu les « boucles de redémarrage » très efficaces, donc un démon cassé peut échouer 50 fois avant que vous clignez des yeux.
• Les mises à jour Proxmox ne sont pas que des mises à jour de l’UI. Elles touchent régulièrement l’outillage de stockage (ZFS), le réseau (ifupdown2) et les couches de virtualisation (QEMU/KVM). Vous mettez à jour un petit datacenter, pas une application web.

Une idée paraphrasée à garder en poche, attribuée à Werner Vogels : « Tout finit par tomber en panne ; la résilience vient d’une conception opérationnelle qui part de ce principe. » (idée paraphrasée)

Tâches pratiques : commandes, sorties, décisions (12+)

Ce sont les vérifications que j’exécute vraiment quand je suis en astreinte et que quelqu’un dit « Proxmox est tombé ». Chaque tâche inclut : la commande, un extrait de sortie réaliste, ce que cela signifie et la décision suivante.

Task 1: Vérifier que l’hôte est en ligne et que vous êtes sur la bonne machine

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

Signification : Vous êtes sur l’hôte Proxmox attendu et vous connaissez le contexte OS/noyau après les mises à jour.

Décision : Si le noyau a changé, gardez à l’esprit : noms de NIC, changements de pilote et backend pare‑feu peuvent varier après un reboot.

Task 2: Confirmer si 8006 écoute, et sur quelle 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))

Signification : pveproxy écoute sur toutes les interfaces. « Connexion refusée » depuis l’extérieur est peu susceptible d’être un « service down ».

Décision : Si vous voyez 127.0.0.1:8006 seulement, traitez‑le comme un problème de bind/interface. Si vous ne voyez rien, passez à la Task 4 (état du service) et Task 5 (logs).

Task 3: Tester localement avec curl (élimine le réseau)

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

Signification : Le point d’entrée web répond localement. Si les utilisateurs distants reçoivent un refus, le problème est presque certainement le pare‑feu/le routage/VIP, pas les services Proxmox.

Décision : Passez aux vérifications de pare‑feu (Task 10/11) et aux vérifications d’interface (Task 8/9).

Task 4: Vérifier la santé de pveproxy via systemd (ne pas deviner)

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

Signification : Échec clair : fichier de certificat manquant sous /etc/pve. Cela pointe vers pmxcfs/système de fichiers de cluster non monté/indisponible, ou bien une génération de certificat interrompue.

Décision : Allez aux Tasks 6 et 7 (pmxcfs et vérifications de /etc/pve), puis régénérez les certificats une fois que /etc/pve est sain.

Task 5: Lire les logs avec du contexte (journalctl est votre ami)

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.

Signification : Il est en boucle de redémarrage. Cela peut causer des effets en cascade (spam de logs, charge CPU), mais la cause racine est toujours la première ligne d’erreur.

Décision : Corrigez la cause liée aux certificats/chemins/pmxcfs. Ne continuez pas à redémarrer en boucle. Vous ne faites que produire de la chaleur.

Task 6: Vérifier que pmxcfs tourne (parce que /etc/pve n’est pas « 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

Signification : pmxcfs est actif. Cela ne garantit pas qu’il est sain, mais ça écarte le cas évident « service down ».

Décision : S’il est en échec, réparez‑le d’abord (stockage/espace plein/quorum). S’il tourne, confirmez que /etc/pve est monté et rempli (Task 7).

Task 7: Confirmer que /etc/pve est monté (et pas un triste répertoire vide)

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)

Signification : C’est monté via FUSE. Bien. Vérifiez maintenant si le fichier de certificat attendu existe.

Décision : Si vous ne voyez pas de ligne de montage, vous n’êtes pas sur le système de fichiers de configuration du cluster ; les services Proxmox vont mal se comporter. Enquêtez sur le démarrage de pmxcfs et le quorum/cluster (Tasks 12/13).

Task 8: Assurer que l’IP de gestion est toujours sur l’interface (les mises à jour + reboots aiment surprendre)

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

Signification : L’IP est présente. Note : avoir la même IP sur une NIC physique et un bridge peut être légitime selon la config, mais cela peut aussi être une anomalie après une réécriture d’interface.

Décision : Si l’IP de gestion attendue manque, réparez d’abord le réseau. L’UI Proxmox ne se liera pas magiquement à une IP que vous n’avez pas.

Task 9: Vérifier le routage (parce que « ça ping » n’est pas une table de routage)

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

Signification : La route par défaut existe. Si votre station de gestion est sur un autre sous‑réseau, il faut que cela soit correct pour atteindre 8006.

Décision : Route par défaut incorrecte ou route manquante : corrigez la configuration réseau. N’accusez pas les services Proxmox pour les péchés de votre routeur.

Task 10: Vérifier l’état du pare‑feu Proxmox (PVE firewall peut rejeter 8006)

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

Signification : Le pare‑feu PVE est actif. C’est normal, mais cela signifie que les règles comptent.

Décision : S’il est activé, inspectez l’ensemble des règles et confirmez que 8006 est autorisé sur l’interface de gestion. S’il est désactivé, vérifiez quand même nftables/iptables (Task 11).

Task 11: Inspecter les règles nftables pour des rejets explicites (refusé = souvent REJECT)

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

Signification : Quelqu’un (ou quelque chose) rejette explicitement 8006 avec un TCP reset. Cela produit « Connexion refusée » côté client.

Décision : Corrigez la règle (supprimez le reject ou remplacez par accept pour vos réseaux d’administration). Ne « videz temporairement tout » que si vous aimez les surprises d’exposition.

Task 12: Vérifier corosync/quorum (les hôtes en cluster peuvent agir comme hantés sans ça)

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

Signification : Le quorum est OK. S’il affichait Quorate: No, un tas de services dépendants de la config peuvent se bloquer ou refuser des écritures, et vous verrez des pannes secondaires.

Décision : Si pas en quorum, décidez : restaurer le quorum (préféré) ou isoler le nœud en sécurité. Évitez de « redémarrer simplement un autre nœud » comme stratégie.

Task 13: Vérifier espace disque et inodes (ennuyeux, fréquent, fatal)

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

Signification : Le système de fichiers racine est plein. Les services qui doivent écrire PID, logs ou état échoueront de manières qui semblent sans rapport avec le stockage.

Décision : Libérez de l’espace immédiatement puis redémarrez les services affectés. Trouvez ensuite ce qui a grossi (Task 14) et corrigez le comportement de logs/sauvegardes sous‑jacents.

Task 14: Identifier ce qui mange le système racine

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

Signification : Quelque chose sous /var/lib est volumineux. Sur Proxmox, suspects habituels : stockage ISO, images de conteneurs, sauvegardes ou journald en fuite.

Décision : Creusez plus (du -xhd1 /var/lib) et supprimez/déplacez le coupable correct. Ne supprimez pas au hasard la config du cluster. Là vivent les regrets.

Task 15: Valider que les certificats existent et sont lisibles

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

Signification : Certificat et clé existent avec des permissions plausibles.

Décision : Si manquants ou corrompus, régénérez (Task 16). Si permissions incorrectes (trop restrictives), corrigez propriété/mode pour que pveproxy puisse les lire.

Task 16: Régénérer les certificats Proxmox (quand un problème de cert empêche pveproxy de démarrer)

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

Signification : Proxmox a régénéré des certificats cluster‑aware et redémarré les démons concernés.

Décision : Revérifiez systemctl status pveproxy et confirmez l’écoute sur 8006 (Task 2). Si ça échoue encore, retournez aux logs ; ne répétez pas cela indéfiniment.

Task 17: Vérifier les conflits de port (rare, mais un coup d’œil vaut la peine)

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)

Signification : Le bon processus possède le port.

Décision : Si autre chose écoute sur 8006, arrêtez‑le ou reconfigurez‑le. Proxmox s’attend à posséder ce port ; le combattre est un choix de vie.

Task 18: Vérifier la joignabilité depuis un autre hôte du même sous‑réseau

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

Signification : La connexion TCP fonctionne. Si votre navigateur affiche encore une erreur, il s’agit probablement d’un problème de confiance TLS/cache du navigateur, ou vous ciblez la mauvaise IP/DNS.

Décision : Validez la résolution DNS et la cible du navigateur. Vérifiez aussi si vous utilisez un VIP, un reverse proxy ou un port‑forward qui a changé lors d’une mise à jour réseau.

Une autre vérité opérationnelle : « Connexion refusée » est rarement un mystère et fréquemment un échec de checklist. C’est une bonne nouvelle. Cela signifie que vous pouvez le réparer sans poésie.

Blague #1 : Si votre plan post‑mise à jour est « on va juste revenir en arrière », félicitations — vous avez découvert le voyage dans le temps, mais seulement pour les versions de paquets.

Trois mini‑histoires d’entreprise depuis le terrain

Incident n°1 : La mauvaise hypothèse (« Ça doit être le pare‑feu »)

Une entreprise SaaS de taille moyenne exploitait un cluster Proxmox à trois nœuds pour des runners CI internes et du staging. Après des mises à jour de routine sur un nœud, l’interface web a cessé de répondre sur 8006. L’ingénieur en astreinte a d’abord pensé au réflexe habituel : « une mise à jour de sécurité a modifié le pare‑feu ». Ils ont désactivé le service pare‑feu et ont toujours obtenu « Connexion refusée ». Cela aurait dû être l’indice, mais l’adrénaline est une drogue persuasive.

L’ingénieur a ensuite vidé entièrement les règles nftables. Le nœud est devenu joignable sur 8006 pendant environ trente secondes puis est retombé. « Vous voyez ? Pare‑feu. » Sauf que non. Ce qui se passait réellement : pveproxy était en boucle de redémarrage, se liant brièvement sur 8006 entre les plantages. Le vidage des règles a changé le timing, pas la causalité.

La vraie cause racine était en plein jour : le système de fichiers racine avait atteint 100%. pveproxy ne pouvait pas écrire son état, pvedaemon est devenu mécontent et systemd a joué sa chorégraphie d’échec efficace. Le bouc émissaire pare‑feu leur a coûté environ une heure, plus un audit amusant parce que le nœud est resté avec une politique d’entrée effectivement ouverte plus longtemps que prévu.

Ce qui l’a réparé n’était pas ingénieux. Ils ont libéré de l’espace sous /var/log, ont fait tourner les journaux, redémarré les services, puis ajouté de la supervision sur l’occupation des systèmes de fichiers. La ligne finale du postmortem était franche : « Nous avons supposé la cause d’après la corrélation (update → pare‑feu). Nous n’avons pas validé l’état de la socket d’abord. »

Incident n°2 : L’optimisation qui s’est retournée contre eux (« Bloquons l’input policy en drop »)

Une grosse équipe IT d’entreprise standardisait sur un baseline harnaché. Un changement semblait propre sur le papier : mettre la politique d’entrée par défaut à drop, puis autoriser explicitement uniquement les ports nécessaires. Sensé. Contrôlé. Conforme aux audits.

Le problème était la façon dont ils l’ont appliqué sur Proxmox. Ils ont poussé un template nftables qui autorisait SSH et quelques ports de monitoring, mais ils ont supposé que l’interface web était derrière un reverse proxy corporate et n’avait pas besoin d’accès direct à 8006. Cette hypothèse était vraie pour la plupart des environnements. Elle était fausse pour l’accès break‑glass quand le reverse proxy était down — ou pendant la maintenance quand les admins faisaient du SSH depuis un jump host et s’attendaient à atteindre https://node:8006 directement.

Après une mise à jour et un reboot, Proxmox est revenu correctement, pveproxy écoutait sur 8006 et curl local retournait 200. Depuis le jump host, toutes les tentatives renvoyaient « Connexion refusée », parce que le template utilisait reject with tcp reset pour les ports non listés. C’est le détail qui a trompé les gens : une erreur « refusée » sentait « service down ».

La correction n’a pas été « tout ouvrir ». Ils ont ajouté une règle accept étroite pour 8006 depuis le sous‑réseau du jump host et ont gardé la politique drop par défaut. Plus important, ils ont documenté que les ports du plan de gestion font partie du chemin break‑glass, pas d’une commodité optionnelle. L’optimisation (sécuriser le baseline) était juste ; le déploiement sans exceptions opérationnelles était l’erreur.

Incident n°3 : La pratique ennuyeuse qui a sauvé la mise (pré‑checks et reboots en étape)

Une équipe de services financiers utilisait Proxmox pour de la VDI et une pile de services internes. Ils étaient conservateurs jusqu’au comique : chaque fenêtre de mise à jour commençait par un script de pré‑vérification, sauvegardé dans un ticket, relu par une seconde personne. Ça ressemblait à de la bureaucratie jusqu’à ce que ce ne le soit pas.

Une nuit, les mises à jour incluaient des changements nécessitant un reboot. Avant le reboot, la pré‑vérif capturait : espace libre, pression mémoire, quorum du cluster et si le nœud hébergeait des VM critiques. Elle capturait aussi « qui écoute sur 8006 maintenant » et le hash du jeu de règles pare‑feu. Ennuyeux. Répétitif. Exactement le but.

Après le reboot, 8006 refusait les connexions. L’ingénieur en astreinte n’a pas paniqué car ils avaient une base de référence : avant reboot, nftables avait un allow pour 8006 ; après reboot, l’allow manquait. Cela a fortement réduit l’espace de recherche. Le problème a été tracé à un run de gestion de configuration qui avait appliqué le mauvais rôle à ce nœud durant la fenêtre de maintenance.

Ils ont reverti le rôle, restauré la règle allow et tout est revenu vite. Le postmortem n’a pas eu de héros, juste la ligne que tout le monde déteste et dont tout le monde a besoin : « Nos pré‑checks ont transformé un mystère en un diff. » La seule partie excitante a été à quel point la récupération était sans intérêt.

Blague #2 : L’UI Proxmox ne « casse pas aléatoirement après les mises à jour ». Elle casse selon le calendrier — vous n’aviez juste pas lu le calendrier.

Erreurs courantes : symptôme → cause racine → correction

Cette section est l’endroit où le temps meurt si vous ne reconnaissez pas les motifs. Voici les récidivistes, ajustés spécifiquement pour « Connexion refusée » sur 8006 juste après des mises à jour.

1) « Connexion refusée » immédiatement après un reboot

• Symptôme : Le navigateur dit refusé ; ping fonctionne ; SSH fonctionne.
• Cause racine : pveproxy n’a pas démarré (certificat manquant/corrompu, pmxcfs non monté, ou erreur de syntaxe de config).
• Correction : systemctl status pveproxy → journalctl -u pveproxy. Validez le montage de /etc/pve ; régénérez les certificats avec pvecm updatecerts --force seulement après que /etc/pve soit sain.

2) curl local fonctionne, refusé depuis l’extérieur

• Symptôme : curl -k https://127.0.0.1:8006 retourne 200 ; le navigateur distant est refusé.
• Cause racine : nftables/iptables rejette 8006, ou le service est lié seulement à loopback, ou l’IP a été déplacée sur une autre interface/VLAN.
• Correction : Vérifiez ss -lntp pour l’adresse de bind ; vérifiez les règles de pare‑feu (nft list ruleset) ; confirmez IP et routes (ip -br addr, ip route).

3) « Ça marchait avant la mise à jour », et maintenant un seul nœud est cassé

• Symptôme : Le cluster a plusieurs nœuds ; seul le nœud mis à jour refuse sur 8006.
• Cause racine : Le /etc/pve de ce nœud est obsolète/non monté, un lien corosync défaillant, ou le nœud a booté avec une config réseau différente (changement de nom de bridge, VLAN manquant).
• Correction : Vérifiez pvecm status, systemctl status pve-cluster, mount | grep /etc/pve, et la config réseau sous /etc/network/interfaces (avec précaution).

4) « Connexion refusée » seulement depuis certains réseaux

• Symptôme : Ça marche depuis le jump host, refusé depuis votre portable, ou l’inverse.
• Cause racine : Les règles d’accès de gestion sont spécifiques à certains sous‑réseaux ; peut‑être qu’un baseline corporate a introduit un rejet explicite pour 8006 sauf depuis des plages approuvées.
• Correction : Confirmez avec les compteurs nft et l’ordre des règles ; ajoutez un allow explicite pour 8006 depuis les sources d’administration requises.

5) 8006 « refusé » et d’autres services random vacillent

• Symptôme : Pas seulement l’UI — métriques, backups ou démarrages de conteneurs échouent aussi.
• Cause racine : Disque plein, épuisement d’inodes, ou système de fichiers monté en lecture seule après erreurs.
• Correction : df -h, df -i, dmesg -T | tail ; remédiez au stockage, puis redémarrez les services.

6) Vous n’arrêtez pas de redémarrer les services et ça continue d’échouer

• Symptôme : systemctl restart pveproxy « marche » mais l’UI reste refusée ; ou cela échoue immédiatement.
• Cause racine : Le redémarrage ne résout pas les fichiers manquants sous‑jacents, les problèmes de permissions ou le port bloqué. Il ne fait que bouger le timestamp.
• Correction : Arrêtez et lisez les logs. Corrigez la première ligne d’erreur. Puis redémarrez.

Checklists / plan pas à pas (récupération sûre)

Voici le plan à suivre quand vous voulez remettre l’UI et que vous ne voulez pas créer de dégâts collatéraux. Il est écrit pour être sûr sur des hôtes standalone et des nœuds de cluster.

Phase 1 : Confirmer la portée (2–5 minutes)

1. Vérifier la joignabilité de l’hôte : SSH ; confirmer le bon hôte (hostnamectl).
2. Vérifier la joignabilité UI locale : curl -k https://127.0.0.1:8006/.
3. Vérifier l’écoute : ss -lntp | grep :8006.

Si 8006 n’écoute pas : passez à la Phase 2.
Si ça écoute localement mais que le distant échoue : passez à la Phase 4 (réseau/pare‑feu).

Phase 2 : Réparer le service (5–15 minutes)

1. État et logs : systemctl status pveproxy, puis journalctl -u pveproxy -b.
2. Dépendances : systemctl status pvedaemon pve-cluster.
3. Vérifier /etc/pve : mount | grep ' /etc/pve ' et ls -l /etc/pve/local/.
4. Sanité disque : df -h /, df -i /. Réparez si plein avant toute autre action.

Phase 3 : Certificats et système de fichiers de config (au besoin)

1. Si les fichiers de cert sont manquants ou cassés : assurez‑vous que /etc/pve est correctement monté et peuplé.
2. Puis régénérez les certificats : pvecm updatecerts --force.
3. Revérifiez l’écoute : ss -lntp | grep :8006 et curl local.

Phase 4 : Pare‑feu et chemin réseau (quand le local marche mais pas le distant)

1. Confirmer l’adresse de bind : si c’est seulement 127.0.0.1:8006, corrigez la config qui contraint le bind (rare ; pas le comportement par défaut).
2. Vérifier le pare‑feu Proxmox : pve-firewall status. S’il est activé, confirmez que les règles autorisent 8006 depuis vos sous‑réseaux d’admin.
3. Vérifier nftables : nft list ruleset et cherchez tcp dport 8006 dans des règles reject/drop.
4. Valider IP et routage : ip -br addr, ip route.
5. Tester depuis un autre hôte : nc -vz <ip> 8006.

Phase 5 : Sanité spécifique au cluster (uniquement si en cluster)

1. Vérifier le quorum : pvecm status.
2. Vérifier corosync : systemctl status corosync et logs si besoin.
3. Éviter les « fixes » risqués : ne retirez pas des nœuds du cluster juste pour faire revenir l’UI. Restaurez d’abord la connectivité réseau entre nœuds.

Quand arrêter et escalader

• Si vous voyez des erreurs de système de fichiers dans dmesg ou des remontages en lecture seule.
• Si le quorum du cluster est perdu et que vous n’êtes pas sûr de quels nœuds sont « réels ».
• Si l’hôte est aussi tête de stockage (ZFS/NFS/iSCSI) et qu’une mauvaise action pourrait faire tomber d’autres services.

FAQ

1) Pourquoi « Connexion refusée » signifie généralement pveproxy, pas le démon API ?

Parce que le port 8006 est le point d’entrée TLS servi par pveproxy. Si ce démon n’écoute pas (ou si un pare‑feu rejette), la connexion TCP ne s’établira pas. Les problèmes de pvedaemon apparaissent plutôt comme des erreurs UI après la connexion, pas comme un refus.

2) Quelle est la vérification la plus rapide ?

ss -lntp | grep :8006. Si rien n’écoute, arrêtez de penser aux routeurs et commencez à lire les logs de pveproxy.

3) curl local fonctionne mais le navigateur de mon portable est refusé. Et maintenant ?

Supposez un pare‑feu ou un chemin réseau. Vérifiez nftables pour un reject with tcp reset sur 8006, validez que l’IP est sur la bonne interface et testez depuis un hôte du même sous‑réseau avec nc -vz.

4) Puis‑je juste redémarrer pveproxy et en finir ?

Vous pouvez essayer une fois. Si ça échoue, redémarrer à répétition n’est que du théâtre. Lisez journalctl -u pveproxy et corrigez la première ligne d’erreur.

5) Un montage /etc/pve manquant casse‑t‑il vraiment l’UI ?

Oui. Proxmox stocke la configuration clé et le matériel de certificats sous /etc/pve, soutenu par pmxcfs. S’il n’est pas monté ou sain, les services dépendants peuvent échouer ou démarrer avec des fichiers manquants.

6) À quelle fréquence l’espace disque plein est‑il la vraie cause ?

Assez souvent pour que cela figure parmi vos cinq premières vérifications. Un root à 100% casse les démons, la génération de certificats, la journalisation et parfois les scripts postinst de paquets. Ce n’est pas glamour, mais c’est courant.

7) J’ai mis à jour des paquets mais je n’ai pas redémarré. Est‑ce que ça peut quand même causer un refus sur 8006 ?

Oui. Les scripts post‑install des paquets peuvent redémarrer des services immédiatement. Si une dépendance a changé (OpenSSL, modules Perl, état du système de fichiers de config) le redémarrage peut échouer même sans reboot.

8) Si le quorum est perdu, est‑ce que 8006 refusera les connexions ?

Pas toujours. La perte de quorum cause plus souvent des actions de gestion à échouer ou des configs en lecture seule. Mais elle peut indirectement casser les chemins de certificats et le comportement de pmxcfs, ce qui peut empêcher pveproxy de démarrer.

9) Dois‑je ouvrir 8006 sur Internet pour « faire marcher » ?

Non. Réparez la vraie cause. Si vous avez besoin d’accès distant, placez‑le derrière un VPN, un bastion ou une allowlist strictement restreinte. Exposer le plan de gestion, c’est comment vous passez vos week‑ends à apprendre la réponse aux incidents.

10) Et si 8006 écoute mais que je ne peux toujours pas charger l’UI ?

Ce n’est plus « connexion refusée ». Vérifiez les erreurs du navigateur, les alertes TLS et si vous ciblez la bonne IP/DNS. Vérifiez aussi que pvedaemon tourne et que l’hôte n’est pas sous une pression de ressources extrême.

Étapes suivantes que vous devriez réellement faire

Restaurez le service d’abord, puis rendez plus difficile la répétition de cet incident.

1. Verrouillez les vérifications rapides : ss -lntp, systemctl status pveproxy, journalctl -u pveproxy, df -h, nft list ruleset. Mettez‑les dans votre runbook exactement dans cet ordre.
2. Ajoutez de la supervision qui détecte les vraies causes : occupation du système racine, usage d’inodes, santé de pmxcfs, et si 8006 écoute depuis un point de vue externe.
3. Arrêtez de traiter les mises à jour comme « juste des patchs » : planifiez‑les, testez‑les en phase, et capturez un diff before/after de l’état réseau et pare‑feu. La pratique ennuyeuse est celle qui marche à 3h du matin.
4. Pour les clusters : traitez le quorum et la connectivité corosync comme partie du plan de gestion. Si le cluster est instable, l’UI est un symptôme, pas la maladie.

Si vous ne faites rien d’autre : la prochaine fois que vous verrez « Connexion refusée », vérifiez si quelqu’un écoute sur 8006 avant de toucher au pare‑feu. Cette habitude unique vous fera gagner des heures et vous évitera de « réparer » agressivement la mauvaise chose.