Headscale vs Nebula (2026) : deux visions très différentes d'un mesh auto-hébergé

Les deux projets répondent à la même question (comment faire tourner un réseau mesh privé sans payer une entreprise pour détenir la carte) et ils y répondent de façon presque opposée. Choisir entre eux n'est pas vraiment une décision de performance. C'est une décision sur le logiciel client dont vous acceptez de dépendre, et sur la panne que vous préféreriez expliquer à vos collègues.

Dans les deux cas, il vous faut une machine publique : le serveur de contrôle Headscale ou le lighthouse Nebula doit se trouver sur un hôte doté d'une IPv4 publique joignable, ce qu'un petit VPS comme un Contabo Cloud VPS 4 (lien affilié) couvre pour 5,50 € par mois sur un engagement de 24 mois.

Vous hésitez entre Headscale et le service hébergé lui-même ? Notre comparatif Tailscale vs Headscale liste les fonctionnalités manquantes, le coût sur 3 ans et un verdict selon la taille de l'équipe.

La version en une phrase

Headscale remplace le serveur de coordination Tailscale par un serveur que vous gérez, en conservant les clients officiels et le plan de données WireGuard. Nebula remplace tout, avec son propre protocole, son propre binaire et une autorité de certification que vous gérez vous-même, c'est pourquoi comparer Nebula à WireGuard lui-même revient à comparer un réseau complet à un protocole de tunnel.

Les deux sont établis plutôt qu'expérimentaux, et les deux sont sous licence permissive, ce qui compte si vous misez votre infrastructure dessus : Nebula a été ouvert par Slack en novembre 2019 sous licence MIT, Headscale a démarré en juin 2020 et est sous licence BSD-3-Clause.

Notez que les deux sont des mesh. Si la question sous-jacente est plutôt de savoir s'il faut un mesh tout court, plutôt qu'un serveur unique auquel tout se connecte, c'est une autre comparaison : Headscale vs OpenVPN la pose en termes de topologie plutôt que de fonctionnalités.

Où réside vraiment la confiance

C'est la différence qui survit à toutes les comparaisons de fonctionnalités.

Dans un réseau Headscale, une machine rejoint le réseau en s'authentifiant auprès de votre serveur de contrôle. Ce serveur vous appartient, donc la décision vous appartient ; mais le client est un logiciel maintenu par Tailscale Inc., pointé vers votre serveur en remplaçant l'URL de connexion. Cet arrangement tient depuis des années, et il n'est pas contractuel.

Dans un réseau Nebula, une machine rejoint le réseau parce qu'elle détient un certificat signé par votre autorité de certification. Vous générez cette CA, et elle n'a jamais besoin de quitter la machine sur laquelle vous l'avez générée. Rien ne s'inscrit sans votre signature. Le prix à payer : le cycle de vie des certificats (émission, distribution, expiration, révocation) devient votre travail dès le premier jour, plutôt qu'une chose que vous apprenez progressivement. Ce prix a une date : nebula-cert ca utilise par défaut une validité de 8760 heures, soit un an, donc un réseau laissé sans surveillance cesse d'inscrire des machines exactement douze mois après sa mise en place, sauf si quelqu'un a renouvelé la CA.

Aucun des deux modèles n'est plus sûr dans l'absolu. L'un vous demande de faire confiance à la tolérance durable d'un éditeur de client ; l'autre vous demande d'être compétent avec une CA.

Un panneau de brassage fibre dense vu sous un angle aigu, avec des rangées de connecteurs duplex turquoise à droite et des câbles fibre bleu-vert pâle et jaunes qui s'éloignent en boucle vers la gauche — Un panneau de brassage fibre avec des rangées de connecteurs duplex turquoise, les câbles s'éloignant en boucle vers la gauche. Les deux projets sont des façons de décider, par logiciel, lequel de ces chemins un paquet a le droit d'emprunter.

Comment chacun trouve ses pairs

Nebula utilise des lighthouses : des nœuds dotés d'une adresse stable et joignable dont le rôle est de savoir où se trouve chacun et de mettre les pairs en relation. Ce sont des nœuds Nebula ordinaires avec un seul paramètre activé (am_lighthouse: true), ils transportent très peu de trafic, et on en fait généralement tourner deux sur des instances VPS bon marché. Nebula écoute par défaut sur le port UDP 4242, et la configuration d'exemple précise qu'un lighthouse doit avoir un port fixe, tandis que les nœuds itinérants ont intérêt à utiliser le port 0, qui demande au système d'exploitation un port dynamique.

Headscale assure lui-même le rôle de coordination, en distribuant les clés et la carte du réseau, avec des relais DERP pour le trafic qui ne parvient pas à établir un chemin direct. Vous pouvez faire tourner votre propre DERP plutôt que d'utiliser les relais publics.

Les architectures se ressemblent. Ce qui diffère, c'est la forme opérationnelle : le lighthouse de Nebula est un nœud du mesh, le plan de contrôle de Headscale est un service adossé à une base de données.

Règles de pare-feu, et où elles s'appliquent

Nebula place un pare-feu d'hôte dans la configuration même du nœud. Chaque hôte déclare les connexions entrantes qu'il accepte, exprimées en groupes de certificats plutôt qu'en adresses IP. L'application est locale, ce qui signifie qu'un plan de contrôle compromis ne peut pas ouvrir un hôte en silence.

Headscale exprime le contrôle d'accès sous forme d'ACL compatibles Tailscale, définies de façon centralisée puis poussées. Un seul fichier décrit tout le réseau, ce qui est bien plus facile à auditer et à comprendre, mais fait aussi peser davantage sur l'exactitude de ce fichier.

Une politique centralisée est plus lisible ; une politique distribuée est plus difficile à contourner depuis un seul point.

Une façon pratique de choisir

Si ceci est vrai pour votre parc	Penchez vers
Portables et téléphones utilisés par des personnes qui ne devraient pas gérer de certificats	Headscale
Serveurs, conteneurs et appliances que vous configurez déjà de façon déclarative	Nebula
Vous voulez MagicDNS, des exit nodes et un parcours de connexion familier	Headscale
Vous voulez zéro dépendance à la feuille de route client d'un éditeur	Nebula
Votre instinct vous dit qu'un plan de contrôle compromis ne doit pas pouvoir ouvrir des hôtes	Nebula
Votre instinct vous dit qu'un seul fichier de politique auditable vaut mieux que plusieurs	Headscale

Les deux finissent sur le même type de serveur : Headscale a besoin d'un petit VPS toujours allumé avec une IP publique et un domaine, et Nebula en a besoin d'un pour son lighthouse. Si le tableau vous oriente vers Headscale, notre générateur de config Headscale gratuit écrit le config.yaml, le fichier Docker Compose et le bloc de reverse proxy pour ce VPS, et un Contabo Cloud VPS 4 est affiché à partir de 5,50 €/mois sur contabo.com (vérifié le 17 oct. 2026). Si vous préférez un hébergeur américain avec une garantie de remboursement de 30 jours, Ultahost VPS Basic coûte 5,52 $ par mois sur un engagement de 24 mois (1 Go de RAM, IPv4 dédiée, relevé le 21 octobre 2026), de quoi faire tourner un serveur Headscale pour une petite équipe.

Ce que nous n'affirmerions pas

Les comparaisons de débit entre les deux circulent largement et mesurent surtout la machine sur laquelle elles ont été réalisées. WireGuard tourne couramment dans le noyau Linux alors que le transport de Nebula tourne en espace utilisateur, ce qui tend à favoriser WireGuard sur un serveur Linux ; mais sur des liens saturés, sur d'autres systèmes d'exploitation ou sur des CPU modestes, cet avantage se perd souvent dans le bruit. Si le débit est réellement votre critère décisif, le seul chiffre qui vaille est celui que vous mesurez sur votre propre chemin, avec votre propre matériel, sur la route que votre trafic emprunte réellement.

★ Datacenter Nuremberg GDPR · ✓ IPv4 dédiée incluse · port 200 Mbit/s

Héberge ton VPN sur ton propre VPS → ContaboAccès root complet · IPv4 publique · choisis ta région→

Questions fréquentes

Quelle est la différence fondamentale entre Headscale et Nebula ?

Headscale est une réimplémentation open source du serveur de contrôle Tailscale : il coordonne un mesh dont le plan de données est WireGuard, et les machines utilisent les clients Tailscale officiels pointés vers votre serveur. Nebula est un réseau overlay complet à part entière, créé par Slack, avec son propre protocole, son propre binaire client et sa propre autorité de certification que vous générez et conservez. Headscale remplace le serveur d'une entreprise ; Nebula remplace toute la pile.

Lequel est le plus simple à mettre en place ?

Headscale, pour la plupart des gens, car les clients sont les applications Tailscale officielles, soignées, et inscrire une machine se résume à une commande de connexion. Nebula vous demande de gérer une autorité de certification dès la première minute : vous générez une clé de CA, signez un certificat par hôte et distribuez des fichiers de configuration. C'est plus de travail au départ, mais c'est aussi explicite : rien ne rejoint votre réseau sans un certificat que vous avez signé.

Comment chacun gère-t-il les nœuds derrière un NAT ?

Les deux percent le NAT et les deux ont besoin d'un auxiliaire quand cela échoue. Nebula appelle ses auxiliaires des lighthouses : des nœuds toujours joignables qui savent qui se trouve où et facilitent les mises en relation. Headscale joue le rôle du serveur de coordination de Tailscale et se rabat sur des relais DERP pour le trafic qui ne peut pas passer en direct (vous pouvez héberger les vôtres). Le concept est le même ; le vocabulaire et la charge d'exploitation diffèrent.

Nebula est-il plus rapide que Headscale basé sur WireGuard ?

Il n'existe pas de réponse unique honnête, et quiconque cite un chiffre décrit son propre matériel. Nebula implémente son propre transport chiffré en espace utilisateur avec le framework Noise, alors que WireGuard tourne généralement dans le noyau sous Linux, ce qui tend à favoriser WireGuard sur un serveur Linux. Sur d'autres plateformes, et sur des liens où le goulot d'étranglement est le réseau plutôt que le CPU, l'écart disparaît souvent. Mesurez votre propre chemin avant de faire du débit le critère décisif.

Que devient chaque réseau si le serveur de contrôle tombe ?

C'est la question à se poser, et les deux se dégradent plutôt qu'ils ne s'effondrent. Les tunnels Nebula existants continuent de fonctionner sans lighthouse ; ce qui casse, c'est la découverte des pairs avec lesquels vous n'avez pas communiqué récemment. Avec Headscale à l'arrêt, les tunnels WireGuard établis persistent aussi, mais la rotation des clés, les nouvelles inscriptions et les mises à jour d'ACL s'arrêtent. Dans les deux cas, le mesh continue de transporter le trafic mais perd sa capacité à évoluer : prévoyez donc des sauvegardes de l'état du plan de contrôle, pas une haute disponibilité de son uptime.

Lequel choisir pour une petite équipe ?

Si les machines sont des ordinateurs portables et des téléphones appartenant à des personnes qui ne devraient pas avoir à penser aux certificats, Headscale l'emporte sur l'expérience client : les applications officielles, MagicDNS et un parcours de connexion que les gens connaissent déjà. Si le parc est composé de serveurs, de conteneurs ou d'appliances que vous configurez de toute façon, le modèle de certificats de Nebula convient mieux et supprime toute dépendance à la feuille de route client d'un éditeur.