La console Proxmox ne s’ouvre pas (SPICE/noVNC) : où ça casse et comment réparer

Comment la console Proxmox fonctionne réellement (et où elle échoue)

Proxmox propose deux principaux chemins de console pour les VM :

• noVNC (basé navigateur) : l’UI web ouvre une page qui établit un WebSocket vers le nœud et proxifie le flux VNC de la VM.
• SPICE (client natif ou lancé depuis le navigateur) : l’UI génère un fichier .vv et un ticket à usage unique ; un client SPICE se connecte via un proxy.

Les deux reposent sur la même vérité opérationnelle : l’UI web n’est pas le serveur de console. C’est un agent de circulation. Elle vous authentifie, demande un ticket de courte durée, puis attend que votre navigateur/client atteigne le bon nœud et le bon port, avec les attentes TLS et les autorisations pare-feu appropriées.

La chaîne noVNC (simplifiée, mais suffisante pour le dépannage)

1. Vous chargez l’UI PVE (généralement https://NODE:8006).
2. L’UI demande à l’API un ticket VNC pour VMID/CTID.
3. L’UI ouvre une page noVNC et tente une connexion WebSocket vers le nœud (toujours via le port 8006 dans la plupart des configurations).
4. pveproxy accepte le WebSocket, valide le ticket et transfère les données vers le point VNC local exposé par QEMU.
5. QEMU parle VNC. noVNC affiche les pixels. Vous tapez, il renvoie les événements clavier.

Points de rupture courants : WebSocket bloqué par un reverse proxy, désaccord TLS, mauvaise adresse de nœud dans un cluster, ticket rejeté à cause d’une dérive d’horloge, ou un pare-feu interrompant le saut interne.

La chaîne SPICE

1. L’UI demande un ticket proxy SPICE et génère un fichier .vv.
2. Votre client SPICE lit le fichier et se connecte au point proxy (souvent via pveproxy sur 8006, parfois via un port dédié selon la configuration).
3. Le proxy transmet au serveur SPICE de QEMU (configuré par VM).

SPICE échoue généralement parce que le client ne peut pas atteindre le nœud (routage/NAT), le proxy annonce mal l’adresse du nœud, ou le client bloque à cause d’un problème de confiance TLS/certificat.

Une citation opérationnelle qui vieillit bien : « You build it, you run it. » — Werner Vogels. Si vous exploitez Proxmox, vous êtes responsable de toute la chaîne console : politique navigateur, en-têtes proxy et la fastidieuse synchronisation du temps.

Une petite blague rapide, parce que vous allez en avoir besoin : la console qui échoue alors que le nœud est vert, c’est comme une voiture avec une peinture parfaite et sans volant.

Feuille de route pour diagnostic rapide

Voici le chemin « arrêtez de scroller et réparez » . L’objectif est d’identifier quel maillon de la chaîne est cassé en moins de cinq minutes.

Première étape : décider si le problème vient du navigateur/UI, du proxy du nœud, ou du backend VM

1. Testez depuis l’adresse directe du nœud (pas via VIP, pas via proxy inverse). Si la console fonctionne en direct mais pas via votre frontal, vous connaissez déjà le coupable : votre proxy/WAF/en-têtes/TLS.
2. Vérifiez DevTools → Console/Réseau dans le navigateur pour des erreurs WebSocket. Si vous voyez WebSocket connection failed ou un 401/403 sur un endpoint WebSocket, vous traitez un problème d’authentification/tickets/proxy.
3. Consultez les logs pveproxy et pvedaemon. S’ils montrent des erreurs de ticket, corrigez la synchronisation horaire ou les problèmes de realm d’auth. S’ils ne montrent rien, votre trafic n’arrive probablement pas (pare-feu/proxy/routage).

Deuxième étape : vérifier la santé du nœud là où ça compte pour les consoles

1. pveproxy est-il en cours et à l’écoute sur 8006 ?
2. L’hostname/IP du nœud est-il cohérent avec ce que le cluster annonce ? Une mauvaise « adresse annoncée » casse la redirection de console de façon surprenante.
3. Le temps est-il synchronisé ? La validation des tickets est sensible au temps. La dérive d’horloge transforme l’auth en pile ou face.

Troisième étape : valider le backend console de la VM

1. La VM est-elle configurée pour une sortie affichage et celle-ci fonctionne-t-elle ? (VNC ou SPICE activé, pas désactivé par la config.)
2. QEMU est-il réactif ? Un QEMU bloqué peut laisser la VM « running » sans jamais accepter une console.

Tâches pratiques : commandes, sorties, décisions

Ce sont des tâches réelles que vous pouvez exécuter sur un nœud Proxmox (ou un poste d’admin où indiqué). Chaque tâche inclut : une commande, à quoi ressemble une sortie saine, et quelle action entreprendre ensuite.

Tâche 1 : Vérifier que le proxy web tourne (la passerelle console)

cr0x@server:~$ systemctl status pveproxy --no-pager
● pveproxy.service - PVE API Proxy Server
     Loaded: loaded (/lib/systemd/system/pveproxy.service; enabled)
     Active: active (running) since Fri 2025-12-26 09:12:11 UTC; 2h 3min ago
   Main PID: 1322 (pveproxy)
      Tasks: 4 (limit: 38391)
     Memory: 62.4M
        CPU: 1min 12.204s

Décision : S’il n’est pas actif/en cours, redémarrez-le puis recherchez pourquoi il est tombé (souvent permissions de fichiers TLS, disque plein ou config cassée). S’il est en cours, passez à autre chose : votre problème est probablement d’atteignabilité, de tickets, de WebSockets ou du comportement du proxy inverse.

Tâche 2 : Confirmer qu’un service écoute sur le port 8006

cr0x@server:~$ ss -ltnp | awk '$4 ~ /:8006$/ {print}'
LISTEN 0      4096         0.0.0.0:8006      0.0.0.0:*    users:(("pveproxy",pid=1322,fd=6))
LISTEN 0      4096            [::]:8006         [::]:*    users:(("pveproxy",pid=1322,fd=7))

Décision : Si rien n’écoute, votre console ne fonctionnera pas. Corrigez pveproxy d’abord. S’il n’écoute que sur IPv6 et vos clients sont IPv4-only (ou vice versa), ajustez le binding ou le DNS.

Tâche 3 : Chercher des erreurs évidentes de proxy dans le journal

cr0x@server:~$ journalctl -u pveproxy -S -2h --no-pager | tail -n 30
Dec 26 10:55:41 pve1 pveproxy[1322]: proxy detected vanished client connection
Dec 26 10:58:03 pve1 pveproxy[1322]: worker 1377 finished
Dec 26 11:12:09 pve1 pveproxy[1322]: starting 1 worker(s)

Décision : « Vanished client connection » est souvent un navigateur/proxy/WAF qui ferme les WebSockets. Si vous voyez des échecs de handshake TLS ou des erreurs de permission, c’est côté nœud. Si le journal est silencieux pendant que vous cliquez sur Console, votre trafic n’atteint probablement pas le nœud (routage, pare-feu, proxy inverse).

Tâche 4 : Surveiller le log du proxy lors de la reproduction du problème

cr0x@server:~$ tail -f /var/log/pveproxy/access.log
10.10.20.55 - root@pam [26/Dec/2025:11:18:09 +0000] "GET /api2/json/nodes/pve1/qemu/101/vncproxy HTTP/1.1" 200 460
10.10.20.55 - root@pam [26/Dec/2025:11:18:09 +0000] "GET /api2/json/nodes/pve1/qemu/101/vncwebsocket?port=5901&vncticket=PVEVNC:... HTTP/1.1" 101 0

Décision : Un 200 sur vncproxy suivi d’un 101 sur vncwebsocket est sain : le WebSocket s’est correctement upgradé. Si vous voyez 401/403, concentrez-vous sur l’auth/tickets/temps. Si vous ne voyez jamais la requête websocket, regardez la configuration proxy/navigateur et le support WebSocket.

Tâche 5 : Valider la synchronisation horaire (les tickets adorent échouer avec une horloge pourrie)

cr0x@server:~$ timedatectl
               Local time: Fri 2025-12-26 11:19:55 UTC
           Universal time: Fri 2025-12-26 11:19:55 UTC
                 RTC time: Fri 2025-12-26 11:19:55
                Time zone: Etc/UTC (UTC, +0000)
System clock synchronized: yes
              NTP service: active
          RTC in local TZ: no

Décision : Si System clock synchronized est no ou si NTP est inactif, corrigez-le. Les tickets console sont de courte durée ; la dérive les casse de façon aléatoire.

Tâche 6 : Vérifier les adresses des nœuds annoncées à l’UI

cr0x@server:~$ pvecm nodes
Membership information
----------------------
    Nodeid      Votes Name
         1          1 pve1 (local)
         2          1 pve2

cr0x@server:~$ grep -R "^\s*address" /etc/pve/corosync.conf
        address: 10.10.20.11
        address: 10.10.20.12

Décision : Si ces adresses ne sont pas joignables depuis le réseau de votre navigateur (par exemple, ce sont des adresses VLAN de stockage ou un réseau de réplication privé), les consoles échoueront lorsque l’UI tentera d’atteindre la mauvaise interface. Corrigez votre stratégie d’adressage (routage ou utiliser la bonne IP de nœud pour la gestion).

Tâche 7 : Tester l’atteignabilité du port 8006 depuis le réseau client

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

Décision : Si cela échoue, arrêtez de blâmer Proxmox. C’est routage/pare-feu/groupe de sécurité. Corrigez la connectivité réseau d’abord ; noVNC ne peut pas téléporter à travers un TCP bloqué.

Tâche 8 : Vérifier l’état et les règles du pare-feu Proxmox

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

cr0x@server:~$ iptables -S | head -n 25
-P INPUT ACCEPT
-P FORWARD ACCEPT
-P OUTPUT ACCEPT
-N PVEFW-FORWARD
-N PVEFW-INPUT
-A INPUT -j PVEFW-INPUT
-A FORWARD -j PVEFW-FORWARD

Décision : Si le pare-feu est activé, vérifiez que vous autorisez 8006/tcp depuis vos réseaux d’administration. Si vous avez un pare-feu d’hôte strict plus un pare-feu en amont, assurez-vous qu’ils sont cohérents. « Défense en profondeur » est bien jusqu’à ce que les deux couches ne soient pas d’accord sur qui peut cliquer Console.

Tâche 9 : Confirmer que l’upgrade WebSocket fonctionne au niveau HTTP (côté nœud)

cr0x@server:~$ curl -k -I 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: 1783

Décision : Si même ceci échoue en local, vous avez un proxy ou une pile TLS cassée. Corrigez les services/certs du nœud. Si le local marche mais le distant non, c’est réseau ou proxy en front.

Tâche 10 : Recréer la requête VNC proxy via l’API (chemin auth et ticket)

cr0x@server:~$ pvesh create /nodes/pve1/qemu/101/vncproxy --websocket 1
port: 5901
ticket: PVEVNC:root@pam:6760E0C2::vO3o2oZ...
user: root@pam

Décision : Si cette commande génère une erreur (permission denied, verrouillage config cluster, timeout), votre problème n’est pas « le navigateur ». C’est l’API/l’auth/le backend. Si elle retourne un ticket et un port, alors le serveur peut générer une session console ; l’échec vient probablement du transport WebSocket ou de la politique côté client.

Tâche 11 : Vérifier que QEMU tourne et n’est pas bloqué

cr0x@server:~$ qm status 101
status: running

cr0x@server:~$ ps -o pid,cmd -C kvm | head -n 3
  PID CMD
 2417 /usr/bin/kvm -id 101 -name vm101 -no-shutdown ...

Décision : Si la VM est « running » mais qu’il n’y a pas de processus QEMU (rare, mais l’état de gestion peut diverger), réconciliez avec qm stop/qm start. Si QEMU est présent mais que la console échoue toujours, concentrez-vous sur le proxy/tickets/pare-feu.

Tâche 12 : Inspecter la configuration d’affichage de la VM (VNC/SPICE activé ?)

cr0x@server:~$ qm config 101 | egrep '^(vga|spice|serial|args)'
vga: std
serial0: socket

Décision : Si vous avez désactivé la sortie VGA (par exemple avec certains setups de passthrough GPU) et que vous n’avez pas de console série configurée, la « console » peut rester vide. Ajoutez un périphérique série et utilisez la console série pour les systèmes headless.

Tâche 13 : Trouver les échecs d’auth/ticket dans les logs des daemons

cr0x@server:~$ journalctl -u pvedaemon -S -2h --no-pager | egrep -i "ticket|auth|permission|vnc|spice" | tail -n 20
Dec 26 11:18:09 pve1 pvedaemon[1203]: authentication successful: user root@pam
Dec 26 11:18:09 pve1 pvedaemon[1203]: VM 101: start vnc proxy

Décision : Si vous voyez « authentication failed » ou des erreurs de ticket, vérifiez la synchronisation horaire et le realm utilisateur, et confirmez que votre navigateur ne met pas en cache d’anciennes sessions entre les nœuds.

Tâche 14 : Si vous utilisez un reverse proxy, vérifiez qu’il proxifie réellement les WebSockets

cr0x@server:~$ nginx -T 2>/dev/null | egrep -n "proxy_set_header (Upgrade|Connection)|proxy_http_version" | head -n 40
123:    proxy_http_version 1.1;
124:    proxy_set_header Upgrade $http_upgrade;
125:    proxy_set_header Connection "upgrade";

Décision : Si ces en-têtes ne sont pas présents pour le bloc location PVE, noVNC plantera souvent ou échouera avec une erreur WebSocket. Corrigez la config du proxy inverse ou évitez de l’utiliser pour les chemins console.

Tâche 15 : Chercher des problèmes MTU/chemin quand les WebSockets se connectent puis se figent

cr0x@server:~$ ping -M do -s 1472 10.10.20.55 -c 3
PING 10.10.20.55 (10.10.20.55) 1472(1500) bytes of data.
1472 bytes from 10.10.20.55: icmp_seq=1 ttl=63 time=0.518 ms
1472 bytes from 10.10.20.55: icmp_seq=2 ttl=63 time=0.511 ms
1472 bytes from 10.10.20.55: icmp_seq=3 ttl=63 time=0.527 ms

Décision : Si vous voyez « Frag needed » ou de la perte seulement sur de gros paquets, suspectez un mismatch MTU (commun avec VLANs, tunnels ou overlays). Les WebSockets peuvent « se connecter » puis se comporter comme hantés sous douleur MTU. Corrigez le MTU ; ne maquillez pas avec des timeouts.

Tâche 16 : Valider le DNS et la correspondance nom/certificat (surtout en cluster)

cr0x@server:~$ hostname -f
pve1.example.internal

cr0x@server:~$ openssl s_client -connect 127.0.0.1:8006 -servername pve1.example.internal 

cr0x@server:~$ openssl x509 -noout -subject -issuer -in /etc/pve/local/pve-ssl.pem
subject=CN = pve1.example.internal
issuer=CN = Proxmox VE

Décision : Si l’UI est accédée via un nom qui ne correspond pas au CN/SAN du certificat, les navigateurs peuvent bloquer ou dégrader le comportement WebSocket selon la politique et les clics utilisateurs. Alignez l’URL d’accès avec les noms de certificat, ou déployez des certificats corrects à l’échelle du cluster.

Carte des pannes : symptômes → points de rupture

La console est une machine de Rube Goldberg avec moins de leviers qu’il n’y paraît. Faites correspondre ce que vous observez au point de rupture :

Symptôme : « Failed to connect to server (code: 1006) » ou « WebSocket connection failed »

• Point probable : WebSocket bloqué ou non upgradé.
• Regardez : configuration du reverse proxy, comportement du WAF, onglet Réseau des devtools, pveproxy/access.log (absence du 101).
• Direction corrective : assurez Upgrade/Connection headers, HTTP/1.1, et connexions longue durée. Si possible, évitez le reverse proxy pour les endpoints console.

Symptôme : l’onglet console s’ouvre mais reste noir/vide

• Point probable : backend d’affichage vide (pas de VGA), ou affichage QEMU mal configuré ; parfois les setups de passthrough GPU retirent la sortie VGA émulée.
• Regardez : qm config pour vga/serial, le guest OS qui attend un autre affichage primaire.
• Direction corrective : ajouter une console série, définir un périphérique VGA raisonnable pour le débogage, ou s’assurer que le guest sort bien vers le bon périphérique console.

Symptôme : fonctionne sur un nœud, échoue sur un autre

• Point probable : pare-feu par nœud, mismatch DNS/cert par nœud, ou le cluster annonce une interface non joignable depuis votre réseau d’administration.
• Regardez : adresses corosync, routage, statut pveproxy sur le nœud défaillant.
• Direction corrective : standardiser le réseau de gestion, unifier les certificats, cesser de confondre « IP stockage » et « IP gestion ».

Symptôme : SPICE télécharge un .vv mais virt-viewer ne se connecte pas

• Point probable : le client ne peut pas atteindre l’hôte/port indiqué dans le .vv, ou problème de TLS/confiance de certificat, ou mauvais host annoncé.
• Regardez : le contenu du .vv (host, port), pare-feu, NAT hairpin, et adresses des nœuds.
• Direction corrective : assurez-vous que le .vv pointe vers une adresse joignable ; si derrière un NAT, corrigez le routage ou utilisez un VIP joignable avec proxy approprié.

Symptôme : la console fonctionne puis se coupe aléatoirement après une minute ou deux

• Point probable : timeout inactif sur le reverse proxy ou load balancer, ou problèmes MTU/fragmentation sur le chemin, ou suivi d’état TCP dans un pare-feu expirant agressivement.
• Regardez : timeouts du proxy, paramètres conntrack du pare-feu, perte de paquets, tests MTU.
• Direction corrective : augmenter les timeouts, permettre WebSockets long-lived, corriger le mismatch MTU, cesser de « sécuriser » en tuant les sessions inactives après 60 secondes.

Erreurs courantes (symptôme → cause → correctif)

1) Spinner sans fin dans noVNC

Symptôme : La fenêtre de console s’ouvre, le spinner ne s’arrête jamais. Pas d’erreur évidente.

Cause racine : Le reverse proxy ne supporte pas ou n’est pas configuré pour l’upgrade WebSocket sur le chemin console.

Correctif : Ajouter les en-têtes d’upgrade WebSocket et HTTP/1.1 dans le proxy, ou contourner le proxy pour le :8006. Validez en cherchant un 101 dans /var/log/pveproxy/access.log.

2) « 401 Unauthorized » sur vncwebsocket

Symptôme : Les devtools du navigateur montrent que la requête websocket retourne 401/403.

Cause racine : Ticket invalide/expiré, souvent à cause d’une dérive d’horloge entre nœuds, ou de sessions sticky mal gérées derrière un load balancer.

Correctif : Corriger le NTP partout. Éviter de load-balancer l’UI PVE à moins de maîtriser l’affinité de session et la portée des tickets ; utiliser un VIP sur un seul nœud est plus sûr.

3) La console ne fonctionne qu’à l’intérieur du LAN

Symptôme : Au bureau ça marche ; depuis le VPN ou un réseau distant ça échoue.

Cause racine : Les adresses annoncées des nœuds sont sur une interface non routée ; ou le pare-feu en amont n’autorise le 8006 que depuis un sous-réseau.

Correctif : Routage correct vers le réseau mgmt ou utiliser une interface de gestion joignable depuis tous les réseaux d’administration. Confirmez avec pvecm nodes et des tests de reachabilité.

4) SPICE télécharge mais le client se connecte à la mauvaise IP

Symptôme : virt-viewer tente de se connecter à une adresse VLAN de stockage inaccessible.

Cause racine : L’hôte pense que son « adresse principale » est la mauvaise interface (commun avec des nœuds multi-NIC et un DNS approximatif).

Correctif : Corriger la résolution de nom des nœuds vers l’IP mgmt et garder la gestion du cluster cohérente. Ne pas compter sur « ce que DNS retourne en premier ».

5) La console fonctionnait, a cassé après une mise à jour

Symptôme : L’UI se charge toujours ; la console échoue maintenant avec des problèmes TLS ou mixed-content.

Cause racine : Les navigateurs ont durci la gestion TLS/WebSocket ; votre proxy ou certificats étaient déjà limites et la mise à jour a retiré la dernière tolérance.

Correctif : Corriger les certificats proprement, aligner les noms, arrêter de terminer TLS deux fois sauf raison impérieuse, et tester les consoles avec des navigateurs récents lors des validations de mise à jour.

6) Console vide sur des VM avec passthrough GPU

Symptôme : La VM est joignable réseau, mais la console est toujours noire.

Cause racine : La sortie du guest est sur le GPU passé en passthrough ; le VGA émulé ne montre rien.

Correctif : Ajouter une console série pour l’accès d’urgence et l’utiliser pour le diagnostic de boot. Ne pas s’attendre à ce que VNC affiche la sortie d’un GPU sans tête.

7) Les consoles échouent seulement sur un navigateur

Symptôme : Ça marche dans Firefox, échoue dans Chrome (ou inversement).

Cause racine : Extension/comportement WAF, cache HSTS/décisions TLS, ou règles mixed content plus strictes.

Correctif : Tester en navigation privée sans extensions ; comparer les erreurs des devtools. Si le navigateur se plaint de la confiance du certificat, corrigez le certificat ; n’apprenez pas au personnel à cliquer sur « continuer quand même » pour toujours.

Trois mini-récits d’entreprise issus du terrain

Mini-récit 1 : L’incident causé par une mauvaise hypothèse

Une entreprise exploitait un petit cluster Proxmox pour des services internes. Rien d’exotique : quelques dizaines de VM, des containers, et un réseau de stockage séparé parce que quelqu’un avait entendu que « le trafic stockage ne doit jamais partager la gestion ». Très bien.

Pendant une fenêtre de maintenance, un nœud a redémarré et est revenu. L’UI semblait saine. Les VM tournent. Mais la console pour n’importe quelle VM sur ce nœud ne s’ouvrait pas depuis le réseau d’administration. L’équipe ops a supposé que la pile d’affichage de la VM était cassée après le reboot et a commencé à bidouiller les réglages QEMU. Elles étaient à environ 30 minutes de tout empirer.

Le vrai problème était une hypothèse intégrée au plan réseau : que l’UI de gestion parlerait toujours à la bonne interface. En pratique, l’hostname du nœud résolvait vers l’IP du VLAN de stockage parce que le DNS avait été « utilement » mis à jour lors d’un nettoyage réseau antérieur. Proxmox annonçait cette adresse à l’UI pour les connexions console, donc les navigateurs tentaient d’ouvrir des WebSockets vers un sous-réseau injoignable.

La correction fut ennuyeuse : corriger le DNS pour les noms de nœuds vers les IP de gestion et garder le réseau de stockage hors de l’identité de gestion. Les consoles sont revenues instantanément. L’équipe a écrit une règle : « Si ce n’est pas joignable depuis les réseaux d’admin, ça ne devient pas adresse d’identité de nœud. »

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

Une autre organisation a placé Proxmox derrière un proxy inverse corporate. L’objectif affiché : standardisation de la sécurité : un point d’entrée, une politique TLS, un lieu pour appliquer le SSO. L’équipe proxy a réglé les timeouts agressivement pour « protéger la plateforme » des connexions longues. Ils ont aussi activé un profil WAF excellent pour bloquer le trafic suspect. Il était aussi excellent pour bloquer les WebSockets.

L’UI se chargeait correctement. C’était suffisant pour déclarer le changement réussi. Puis l’incident suivant est arrivé : une mauvaise mise à jour invité a laissé une VM non bootable, et l’ingénieur d’astreinte avait besoin d’un accès console. La console a tourné en boucle. Un deuxième ingénieur a essayé SPICE. Même histoire : le téléchargement fonctionnait, la connexion échouait. L’optimisation proxy avait effectivement supprimé le chemin d’accès hors-bande.

Le débogage a été prévisible et politique. L’équipe proxy disait que Proxmox était cassé. L’équipe virtualisation disait que le proxy était cassé. Les deux avaient partiellement raison : Proxmox a besoin de clean WebSocket upgrades, et le proxy avait été configuré comme si tout était un appel REST sans état.

La résolution : contourner le proxy pour le :8006 depuis les réseaux d’admin, conserver le SSO pour l’UI où cela avait du sens, et autoriser explicitement l’upgrade WebSocket et des timeouts longs sur les routes console. Tout le monde a appris la même leçon différemment : tout ne doit pas être « optimisé » vers l’uniformité.

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

Une équipe de services financiers appliquait un processus de changement strict qui faisait lever les yeux au ciel des ingénieurs. Ils avaient une checklist pré-upgrade : valider la synchro horaire entre nœuds, vérifier les certificats, ouvrir la console sur chaque nœud, et lancer un scan de reachabilité depuis le subnet admin. Ce n’était pas glamour. Ça n’a pas craqué à 2 h du matin.

Pendant un cycle de mise à jour Proxmox, une étape de renouvellement de certificat a échoué sur un nœud à cause d’un problème de permissions. L’UI était toujours disponible, ce qui aurait masqué le défaut. Mais la checklist incluait « ouvrir une console noVNC sur une VM de test par nœud », et la console de ce nœud a échoué immédiatement avec une erreur liée à TLS.

Comme l’échec a été détecté avant les heures de production, l’équipe a eu le temps de corriger proprement : corriger les permissions sur les fichiers de certificat et redémarrer pveproxy. Aucun accès d’urgence n’a été perdu et la mise à jour s’est déroulée sans drame.

La morale n’est pas « les checklists sont bonnes » de façon abstraite. La morale est que l’accès console fait partie de vos outils de casse-glace. Testez-le avec la même rigueur que la restauration des backups, car vous n’en aurez besoin que quand tout le reste brûle.

Listes de contrôle / plan pas à pas

Pas à pas : quand une console ne s’ouvre pas maintenant

1. Éliminez la complexité : accédez au nœud directement sur https://NODE:8006 (pas via proxy inverse, ni via un VIP de cluster) et testez la console.
2. Preuve navigateur : ouvrez DevTools → Réseau, filtrez « websocket », reproduisez. Notez les codes d’état (101 vs 4xx/5xx) et les erreurs.
3. Preuve nœud : tail /var/log/pveproxy/access.log en cliquant Console. Vous voulez voir vncproxy 200 et vncwebsocket 101.
4. Santé des services : confirmez que pveproxy tourne et écoute sur 8006.
5. Atteignabilité : depuis votre réseau d’administration, confirmez TCP/8006 vers le nœud. Si vous ne pouvez pas vous connecter, arrêtez et corrigez le réseau.
6. Tickets/auth : exécutez pvesh create ... vncproxy sur le nœud pour confirmer que la génération de ticket fonctionne.
7. Synchronisation temporelle : vérifiez NTP et la synchronisation entre nœuds. Corrigez la dérive avant de chasser des fantômes.
8. Backend VM : vérifiez qm config pour les paramètres d’affichage/série ; confirmez l’existence du processus QEMU.
9. Couche proxy (si utilisée) : validez les en-têtes d’upgrade WebSocket et les timeouts.
10. MTU/perte de paquets : si la connexion se crée puis tombe, testez le MTU et vérifiez les timeouts conntrack du pare-feu.

Pas à pas : durcir pour éviter que cela se reproduise

1. Standardisez l’adressage de gestion : chaque nom de nœud doit résoudre sur une IP de gestion joignable depuis les réseaux admin. Pas d’exceptions « juste pour le stockage ».
2. Politique de synchronisation horaire : NTP requis sur tous les nœuds ; alerter en cas de dérive. Les sessions ticketées en dépendent.
3. Hygiène des certificats : utiliser des certificats corrects avec les bons noms ; renouveler en sécurité ; tester après renouvellement.
4. Règle pour reverse proxy : si vous devez proxifier, supportez explicitement les WebSockets et des timeouts longs pour les routes console. Sinon, ne proxifiez pas les consoles.
5. Accès break-glass : configurer des consoles série pour les VM critiques, surtout celles avec passthrough GPU ou configurations headless.
6. Validation de mise à jour : inclure l’ouverture de console sur chaque nœud dans le contrôle de changement.

Deuxième blague, parce qu’on l’a bien méritée : le moyen le plus rapide de découvrir que votre reverse proxy ne supporte pas WebSockets, c’est d’en avoir besoin pendant une panne.

Faits intéressants et courte histoire (les points à connaître)

• Les WebSockets ont été standardisés au début des années 2010, et beaucoup d’infrastructures HTTP « enterprise » les traitent encore comme un invité indésirable à un dîner poli.
• noVNC existe parce que « installer un client » est inacceptable dans beaucoup d’environnements. Les navigateurs ont gagné cette bataille, et les équipes ops ont hérité des conséquences proxy/en-têtes.
• SPICE a été conçu pour être plus que des pixels : audio, presse-papiers, résolution dynamique et meilleure UX distante que le VNC classique quand tout est de bout en bout.
• Les consoles Proxmox reposent sur des tickets de courte durée pour de bonnes raisons : ils réduisent la portée d’une URL volée et limitent la réutilisation accidentelle de sessions.
• La dérive d’horloge casse l’auth de façon non évidente, surtout pour les systèmes qui émettent des tokens limités dans le temps. Les tickets console en sont un exemple pratique.
• Les navigateurs ont durci TLS et les règles mixed-content. Les anciens setups « ça marche sur ma machine » sont de moins en moins tolérés, surtout pour les WebSockets.
• Les systèmes en cluster ont souvent plusieurs réseaux (mgmt, stockage, réplication). Mélanger la sélection d’identité/adresse entre eux est une source classique de « l’UI marche, la console ne marche pas ».
• Le VNC est ancien mais utile. Sa simplicité facilite le proxypass ; sa simplicité signifie aussi qu’il est facile à mal sécuriser si on l’expose directement.

FAQ

Pourquoi l’UI Proxmox se charge mais la console échoue ?

Parce que charger l’UI, c’est juste HTTPS vers le port 8006. La console ajoute un upgrade WebSocket (noVNC) ou une connexion client séparée (SPICE) plus un ticket de courte durée. Plus de maillons, plus de façons de casser.

Quel log vérifier en premier sur le nœud ?

/var/log/pveproxy/access.log. Il indique si la requête websocket est arrivée et si elle a été upgradée (101). C’est la source de vérité la plus rapide.

Que signifie HTTP 101 dans l’access log ?

Cela signifie que l’upgrade WebSocket a réussi. Si vous voyez vncwebsocket avec 101, le proxy et le navigateur ont négocié WebSockets. Si vous n’obtenez toujours pas de console, concentrez-vous sur le backend VM, le MTU, ou le rendu client.

Pourquoi les reverse proxies cassent-ils si souvent noVNC ?

Parce qu’ils sont souvent configurés pour des requêtes HTTP courtes et peuvent omettre les en-têtes d’upgrade WebSocket, forcer HTTP/2-only, terminer TLS d’une manière qui confond l’amont, ou tuer les connexions inactives.

Puis-je « simplement ouvrir le port VNC » directement au lieu d’utiliser noVNC ?

Vous pouvez, mais généralement vous ne devriez pas. Cela augmente la surface d’attaque et complique les règles de pare-feu. Le proxy de console de Proxmox existe pour éviter d’exposer directement les ports VNC/SPICE et pour lier l’accès à des tickets authentifiés.

Pourquoi ça échoue seulement pour certains nœuds du cluster ?

Configuration par nœud incohérente : règles pare-feu différentes, certificats différents, résolution DNS différente, ou un nœud qui annonce une adresse non joignable depuis votre réseau admin.

Comment la synchronisation temporelle est-elle liée aux consoles ?

Les tickets console sont limités dans le temps. Si l’horloge d’un nœud est suffisamment mauvaise, les tickets sont considérés comme expirés ou pas encore valides. Le résultat est un comportement intermittent 401/403 qui ressemble à de la flakiness navigateur.

Ma console se connecte puis coupe après ~60 secondes. Quelle est la cause habituelle ?

Un timeout inactif d’un proxy/load balancer ou un timeout d’état d’un pare-feu sur les connexions longue durée. En deuxième position : mismatch MTU causant des blocages étranges sous charge. Corrigez les timeouts et le MTU ; ne « corrigez » pas en demandant aux ingénieurs de se reconnecter sans cesse.

SPICE ne se connecte pas mais noVNC marche. Pourquoi ?

Chemins clients différents. SPICE utilise une application cliente et une pile protocolaire différente ; il est plus sensible à l’atteignabilité et à la confiance du certificat sur les endpoints listés dans le .vv. noVNC s’appuie sur ce que le navigateur peut atteindre.

noVNC fonctionne en direct vers le nœud, mais échoue via notre URL corporate. Que faire ?

Arrêtez de déboguer Proxmox et commencez à déboguer le proxy. Assurez-vous que les WebSockets sont autorisés, que les en-têtes d’upgrade sont définis, que les timeouts sont suffisants, et qu’aucune règle WAF ne bloque les chemins websocket.

Quelle est l’option break-glass la plus propre pour les VM Linux headless ?

La console série. Configurez serial0: socket sur la VM, assurez-vous que le guest a un getty/console kernel série configuré, et utilisez la console série de Proxmox quand le VGA est peu fiable.

Conclusion : actions suivantes efficaces

Quand les consoles Proxmox ne s’ouvrent pas, traitez-le comme une chaîne connectivité/auth, pas comme un bug UI. Votre signal le plus rapide est de savoir si vncwebsocket atteint pveproxy et passe en 101. À partir de là, le triage est simple : reachabilité réseau, proxy compatible WebSocket, synchronisation temporelle pour les tickets, et des adresses d’identité de nœuds sensées.

Prochaines étapes qui rapportent :

• Ajouter « ouvrir la console sur chaque nœud » aux vérifications de mise à jour et de renouvellement de certificats.
• Standardiser DNS et interfaces de gestion pour que les consoles ne redirigent pas vers des réseaux injoignables.
• Prendre une décision consciente sur les reverse proxies : soit les configurer correctement pour WebSockets et timeouts, soit les contourner pour l’accès admin.
• Activer les consoles série sur les VM critiques pour ne pas être bloqué quand la sortie VGA manque ou est mal dirigée.

Si vous mettez en place ces quatre points, les pannes de console deviennent le type de problème rare : ennuyeux, diagnostiquable et court.