Hetzner a ouvert en bêta hcnet, sa nouvelle pile réseau pour Hetzner Cloud fondée sur eBPF, qui fait déjà tourner tous ses répartiteurs de charge et que les clients peuvent activer serveur par serveur. Un benchmark publié le 10 novembre 2026 par Cloudfleet, une plateforme de Kubernetes géré, montre des gains nets sur la capacité du pare-feu et les tunnels WireGuard, mais aussi une baisse de 39 % à 55 % du trafic TCP comportant de nombreux flux vers une seule machine virtuelle.
Les points clés de hcnet, le nouveau réseau de Hetzner, en 30 secondes
- hcnet est une pile réseau propre à Hetzner fondée sur eBPF, en bêta et optionnelle pour les serveurs cloud.
- La limite de connexions du pare-feu passe de 80 000 partagées à 120 000 par IPv4 et autant par IPv6.
- Cloudfleet mesure un WireGuard de 18 % à 39 % plus rapide.
- Le TCP à huit flux vers une VM chute jusqu’à 55 % à cause d’une limite de la carte virtuelle.
Hetzner décrit hcnet dans sa documentation comme sa propre pile réseau fondée sur eBPF, la technologie du noyau Linux qui permet d’exécuter de petits programmes vérifiés sur le chemin des paquets, et la présente comme la base de futures fonctions réseau. La migration a commencé par les répartiteurs de charge le 9 juillet 2026, et depuis le 21 août tous fonctionnent sur hcnet. Pour les serveurs cloud, elle est optionnelle : on l’active depuis la console, dans l’onglet Networking de chaque serveur, avec l’option « Try new network stack », et l’on peut revenir en arrière avec « Restore standard network stack ». La documentation ne précise pas dans quels emplacements ni sur quels types de serveurs elle est disponible, ni quand elle cessera d’être en bêta.
Ce qui change dans le pare-feu et le réseau
Le changement le plus visible concerne Hetzner Cloud Firewall. Avec hcnet, chaque pare-feu est compilé en un programme eBPF indépendant placé devant la carte réseau virtuelle de chaque serveur. La limite de connexions avec suivi d’état passe de 80 000, partagées entre IPv4 et IPv6, à 120 000 pour chaque famille, sans surcoût. Le comportement change aussi lorsque la table est pleine : au lieu d’abandonner les nouveaux paquets, hcnet les évalue uniquement avec les règles du pare-feu, de sorte que le trafic explicitement autorisé continue de passer. Hetzner prévient que le trafic qui dépend du suivi de connexions peut malgré tout être affecté.
Il y a d’autres ajustements plus discrets. Un seul serveur DHCP propre remplace les deux qui existaient pour les réseaux public et privé, le serveur de métadonnées répond aussi en IPv6 sur fe80::a9fe:a9fe via toutes les interfaces, les erreurs ICMP sont plus précises et le multicast IPv6 est pris en charge partiellement. Les paquets arrivent à la machine virtuelle tels qu’ils circulent sur le câble, sans réassemblage, si bien que le nombre de paquets reçus peut augmenter même à bande passante égale. Parmi les limites connues, Hetzner cite que lors du changement de pile certaines routes DHCP peuvent tarder à se mettre à jour ou rester obsolètes jusqu’à l’expiration du bail ou au redémarrage du serveur.
Ce que mesure le benchmark de Cloudfleet
Cloudfleet a testé quatre serveurs CCX23 (quatre vCPU dédiés AMD EPYC Milan et 16 GB de RAM) à Falkenstein, sous Ubuntu 24.04 et noyau 6.8, en comparant les deux piles par paires de serveurs puis en les intervertissant. Elle a mesuré l’IPv4 public, l’IPv6 public et le réseau privé avec iperf3, netperf et ping, en trois passes de 10 secondes avec la médiane comme résultat, et a fait une vérification à part avec deux CPX42 partagés de huit vCPU.
Les gains se concentrent sur la capacité de connexions : 1,4 fois plus en IPv4 et jusqu’à 2,7 fois en additionnant IPv4 et IPv6. La récupération après saturation de la table passe de 44 à 64 secondes à 0 à 3 secondes, soit environ 20 fois plus vite. Le débit d’un tunnel WireGuard à quatre flux augmente de 18 % à 39 %, et la latence p99 des requêtes TCP en IPv4 public baisse de 13 % à 21 %. La latence médiane change à peine, et un flux TCP unique ne montre pas non plus de différences constantes.
La régression concerne le trafic massif avec plusieurs flux vers une même VM : avec huit flux TCP, le débit chute de 39 % à 50 % sur CCX23 et d’environ 55 % sur CPX42. Selon Cloudfleet, la cause tient à ce que la carte virtuelle virtio n’a qu’une seule file de réception, si bien qu’un seul vCPU finit par faire goulet d’étranglement, et la solution passerait par des cartes virtio à plusieurs files, ce que l’entreprise espère voir Hetzner ajouter. C’est son interprétation ; Hetzner ne l’a pas commentée dans sa documentation.
Les résultats ont des limites que Cloudfleet reconnaît : un seul emplacement, pas d’instances Arm, des écarts inférieurs à 10 % noyés dans le bruit et certaines données écartées parce qu’elles variaient trop d’une paire de serveurs à l’autre. De plus, s’agissant d’une bêta, le comportement peut changer. Il faut aussi garder à l’esprit que Cloudfleet propose du Kubernetes géré sur des fournisseurs comme Hetzner, si bien que son intérêt se situe dans les scénarios de nœuds à nombreuses connexions, où hcnet s’en sort le mieux.
Pour qui veut l’essayer, la recommandation des deux sources est de le faire pendant une fenêtre de maintenance : activer ou désactiver hcnet coupe brièvement la connectivité et, si un pare-feu est assigné, peut fermer les connexions existantes. Le nouveau réseau arrive dans une année où Hetzner a aussi augmenté ses prix et simplifié son catalogue de serveurs, et l’extension de la limite de connexions n’entraîne aucun coût supplémentaire.
Questions fréquentes
Qu’est-ce que hcnet de Hetzner ?
La nouvelle pile réseau de Hetzner Cloud fondée sur eBPF. Elle fait tourner tous les répartiteurs de charge depuis août 2026 et est en bêta optionnelle pour les serveurs.
Comment activer hcnet ?
Dans la console Hetzner, onglet Networking du serveur, option « Try new network stack ». Cela provoque une brève coupure de connectivité.
Combien de connexions le pare-feu accepte-t-il avec hcnet ?
120 000 pour l’IPv4 et 120 000 pour l’IPv6, contre 80 000 partagées avec la pile standard.
Les performances se dégradent-elles ?
Selon Cloudfleet, le TCP à huit flux vers une seule VM chute de 39 % à 55 %, parce que la carte virtuelle n’a qu’une seule file de réception.
Sources :
