WireGuard vs Tailscale vs Headscale vs NetBird: die Entscheidung für Ihr self-hosted Mesh-VPN

Die Antwort zuerst: Es geht nicht um "WireGuard vs Tailscale"

WireGuard ist ein Protokoll, die Komponente, die Ihre Pakete tatsächlich verschlüsselt und transportiert. Tailscale, Headscale und NetBird sind Control Planes, die auf diesem Protokoll aufbauen: Sie übernehmen Key-Distribution, Peer-Discovery, NAT-Traversal und Zugriffsrichtlinien, damit Sie nicht von Hand Konfigurationsdateien bearbeiten müssen. Die beliebte Suchanfrage "WireGuard vs Tailscale" vergleicht also ein Protokoll mit einem Produkt. Die eigentliche Entscheidung ist, wer Ihre Control Plane betreibt. Hier die Kurzfassung:

• Tailscale: Sie wollen ein Mesh-VPN, das einfach funktioniert, betrieben von jemand anderem, mit der besten Client-Erfahrung und ohne Control-Plane-Betrieb. Der Preis dafür ist ein geschlossener, gehosteter Koordinationsserver und Pricing pro Nutzer.
• Headscale: Sie wollen genau die Client-Erfahrung von Tailscale, aber mit selbst gehostetem Koordinationsserver. Open Source, von der Community betrieben, beschränkt auf ein einzelnes Tailnet.
• NetBird: Sie wollen einen vollständig offenen, vollständig self-hostbaren Stack (Client und Control Plane), mit eingebauter Identity/SSO und gruppenbasierten Zugriffsrichtlinien, und Sie sind bereit, mehr bewegliche Teile zu betreiben.
• Rohes WireGuard: Ihre Topologie ist klein und statisch, Sie wollen maximale Kontrolle und den schlankstmöglichen Datenpfad, und Sie verwalten Keys und Konfiguration lieber selbst.

Der Rest dieses Artikels besteht aus der Landkarte, der Entscheidungstabelle, der Performance-Realität (mit echtem Mechanismus statt vagem Gerede) und einem Urteil aus Betreiberperspektive.

Die Landkarte: Protokoll, Control Plane, Relay

Fast jeder Vergleich in den Suchergebnissen überspringt genau das eine Diagramm, das dieses ganze Themenfeld verständlich macht. Hier ist es als Schichtenmodell; jedes Produkt trifft auf jeder Schicht andere Entscheidungen:

Aus diesem Modell ergeben sich sofort zwei Konsequenzen:

• Weil jede Option dieselbe WireGuard-Data-Plane nutzt, sind Verschlüsselung und der rohe Paketpfad im Kern identisch. Unterschiede im Durchsatz entstehen dadurch, wie WireGuard implementiert ist (Kernel vs Userspace) und ob der Traffic direkt oder über ein Relay läuft, nicht durch das Protokoll.
• "Self-hosted" bedeutet je nach Produkt etwas anderes. Bei Headscale hosten Sie den Koordinationsserver selbst, nutzen aber weiterhin Tailscales offizielle Clients. Bei NetBird können Sie alles self-hosten. Bei Tailscale hosten Sie nichts selbst (auch wenn Sie durchaus ein eigenes DERP-Relay betreiben können). Diese Unterscheidung ist die gesamte Entscheidung, und die Tabelle unten übersetzt sie in Kriterien.

Die Entscheidungstabelle

Das sind die Dimensionen, anhand derer Menschen tatsächlich entscheiden. Die Preise stammen von den Seiten der Anbieter, Stand Juli 2026, und ändern sich häufig; prüfen Sie sie erneut, bevor Sie sich festlegen.

Ein paar Zellen verdienen eine genauere Erklärung, denn genau dort werden Menschen überrascht.

Offene Clients bedeuten keine offene Control Plane. Tailscales Clients sind Open Source; sein Koordinationsserver nicht. Genau da setzt Headscale an; es ist eine Open-Source-Neuimplementierung dieses Servers, die Sie selbst betreiben, kombiniert mit Tailscales offiziellen Clients. NetBird ist durchgängig Open Source (die Management-, Signal- und Relay-Komponenten unter AGPLv3, der Rest unter BSD-3-Clause).

Die WireGuard-Implementierung unterscheidet sich, und das ist messbar. Tailscales Client nutzt ein Userspace-WireGuard (wireguard-go); NetBird nutzt das Kernel-WireGuard-Modul unter Linux, wenn es verfügbar ist, und fällt nur dann auf Userspace zurück, wenn das nicht der Fall ist. Diese eine Tatsache ist die Wurzel der meisten Durchsatzunterschiede zwischen beiden, im Folgenden erklärt.

Performance: woher die Unterschiede tatsächlich kommen

Jeder wiederholt: "sie nutzen alle WireGuard, also ist der Durchsatz identisch." Das stimmt für das Protokoll und stimmt nicht in der Praxis, aus zwei konkreten Gründen: Kernel vs Userspace und direkt vs über Relay.

Kernel vs Userspace WireGuard

Das Kernel-WireGuard-Modul verarbeitet Pakete innerhalb des Kernels. Eine Userspace-Implementierung wie wireguard-go muss jedes Paket über die User/Kernel-Grenze hinweg bewegen, und dieser Syscall-Overhead pro Paket (nicht die Verschlüsselung selbst) ist der Preis dafür. Er skaliert mit der Paket-Rate und macht sich daher vor allem bei Workloads mit hohem Durchsatz und kleinen Paketen bemerkbar.

Wie groß ist dieser Abstand? Nehmen Sie die Zahlen von den Leuten, die die Userspace-Implementierung geschrieben haben. Tailscales eigener Engineering-Blog berichtet von einer In-Kernel-WireGuard-Baseline von 2.66 Gbit/s gegenüber wireguard-go mit 2.42 Gbit/s im selben Test, und nach dem Hinzufügen von Segmentation-Offload- und Batching-Optimierungen erreichte ihr Userspace-Pfad 5.36 Gbit/s und schlug damit sogar die unoptimierte Kernel-Baseline. Sie zeigten außerdem, dass allein das Anheben der MTU von 1500 auf 9001 wireguard-go von 2.42 auf 7.88 Gbit/s brachte. Lesen Sie das mit der richtigen Einordnung: bei einer Standard-MTU und unoptimiertem Setup zahlt Userspace einen echten Aufpreis; mit Jumbo Frames und modernen Offloads kann der Userspace-Pfad sehr schnell sein. Die in der Community verbreitete Faustregel von etwa ~10–15% Aufpreis für Userspace bei Standardkonfigurationen stimmt in der Tendenz, ist aber konfigurationsabhängig.

Die praktischen Schlussfolgerungen:

• Müssen Sie eine schnelle Verbindung mit einem einzelnen Flow auslasten und wollen den schlankstmöglichen Pfad, hat rohes Kernel-WireGuard (oder NetBirds Kernel-Modus unter Linux) bei einer Standardkonfiguration die Nase vorn.
• Die MTU ist wichtiger als die Produktwahl. Eine falsch konfigurierte Overlay-MTU (WireGuards Interface-Standardwert liegt bei rund 1420, um Platz für die Kapselung zu lassen) kostet Sie mehr Durchsatz als Kernel-vs-Userspace. Bringen Sie zuerst die MTU in Ordnung.
• Für die überwiegende Mehrheit des realen Traffics (viele kleine Flows, deutlich unter einem Gigabit) ist der Unterschied nicht wahrnehmbar, und Sie sollten anhand von Betrieb und Funktionsumfang entscheiden, nicht anhand von Benchmarks.

Unabhängige Benchmarks bestätigen diese Schlussfolgerungen. Eine Studie der Universität Amsterdam über eine 1-Gbit/s-Verbindung ergab, dass Kernel-WireGuard und Userspace-wireguard-go die Leitung beide auslasteten (~900 Mbit/s), wireguard-go dafür aber 230% eines CPU-Kerns verbrannte, gegenüber deutlich unter einem Kern für das Kernel-Modul. Der Userspace-Preis wird in CPU bezahlt, und er wird erst dann zur Durchsatzgrenze, wenn die CPU zum Flaschenhals wird (schnellere Leitungen, kleinere Pakete). Auf echter 10-GbE-Hardware maß Protectli rohes Kernel-WireGuard mit 4.15–5.01 Gbit/s (iperf3, vier Streams) über seine Appliances der mittleren Preisklasse; auf einem bescheidenen Desktop-PC aus dem Jahr 2016 über Gigabit maß TechOverflow Tailscale mit 354/194 Mbit/s, etwa die Hälfte dessen, was dieselbe Leitung ohne Tailscale leistete, genau der Fall einer schwachen CPU, in dem der Userspace-Pfad die Grenze setzt.

Der einzige direkte Vergleich, der eine Erwähnung wert ist, stammt von NetBird selbst, und er ist erfrischend ehrlich: Beim Testen von NetBird 0.68.3 gegen Tailscale 1.96.4 auf Cloud-Hosts erreichten beide ~1.26–1.30 Gbit/s über eine Rechenzentrumsverbindung innerhalb desselben Landes, und der Autor (schreibend auf NetBirds eigenem Blog) kam zu dem Schluss, dass beide "im Grunde gleich" seien, "kein konsistenter, wiederholbarer Vorteil." Das ist die ehrliche Bilanz: Auf leistungsfähiger Hardware halten sie alle das gleiche Tempo; der Unterschied zwischen Kernel und Userspace tritt nur zutage, wenn die CPU zum Flaschenhals wird, und die MTU ist meist wichtiger als das gewählte Produkt.

Direkt vs über Relay, und NAT-Traversal

Können zwei Peers eine direkte Verbindung aufbauen, läuft WireGuard Peer-to-Peer und Sie bekommen die Zahlen von oben. Geht das nicht (CGNAT auf beiden Seiten, strikte Firewalls, blockiertes UDP), fällt der Traffic auf ein Relay zurück, und ein Relay ist ein geteilter, geografisch platzierter zusätzlicher Hop, der Latenz hinzufügt und den Durchsatz begrenzen kann.

• Tailscale und Headscale nutzen DERP (Designated Encrypted Relay for Packets). DERP leitet bereits verschlüsselte WireGuard-Pakete weiter, kann Ihren Traffic also nicht entschlüsseln; es ist ein Fallback, kein Man-in-the-Middle. Sie können einen DERP-Node self-hosten, um zu bestimmen, wohin relayter Traffic geht.
• NetBird nutzt ICE (STUN, um öffentliche Mappings zu ermitteln, TURN zum Relayen) und ist dabei, von Coturn auf ein eigenes WebSocket-basiertes Relay umzusteigen.

Wie oft passiert dieser Fallback tatsächlich, und was kostet er? Tailscale ist der Einzige, der harte Zahlen veröffentlicht, und die sind beruhigend: Das Unternehmen berichtet von "direkter NAT-Traversal deutlich über 90%" unter typischen Bedingungen, mehr als neun von zehn Verbindungen kommen also direkt zustande statt über ein Relay, auch wenn das nicht für die schwierigen Fälle aufgeschlüsselt wird (CGNAT auf beiden Seiten, symmetrisches NAT), wo die Erfolgsquote sinkt. Läuft eine Verbindung doch über ein Relay, hängt die Latenzstrafe davon ab, wie weit entfernt dieses Relay sitzt: In einer Tailscale-Fallstudie zu einer Strecke von Indien in die USA maß eine Route über einen weit entfernten DERP-Node 452 ms gegenüber 298 ms für eine näher gelegene, fast direkte Route, also rund 150 ms vermeidbaren Umweg. NetBird veröffentlicht keine vergleichbare Erfolgsquote, weshalb bei NetBird (und bei Ihrem eigenen Netzwerk, unabhängig vom Tool) das Verhältnis direkt-vs-Relay und die Latenzstrafe des Relays Dinge sind, die Sie messen sollten statt anzunehmen.

Die vier Optionen, ehrlich betrachtet

Rohes WireGuard

Stärkstes Argument: die schlankste, schnellste, am besten prüfbare Option: eine winzige In-Kernel-Codebasis ohne Control Plane, der man vertrauen oder die man betreiben müsste. Für eine Handvoll statischer Peers (ein paar Server, eine Site-to-Site-Verbindung) gibt es nichts Besseres in puncto Einfachheit und Performance. Wir nutzen es genau so in unserem Guide zu einem Site-to-Site-VPN mit WireGuard auf VyOS.

Größte Schwäche: Es gibt keine Control Plane, und das ist in Ordnung, bis es das nicht mehr ist. Ab etwa zehn Peers wird das manuelle Verwalten von Keys, IP-Zuweisung und dem AllowedIPs-Mesh zu echter Arbeit, und es gibt keine eingebaute NAT-Traversal; Peers hinter CGNAT brauchen ein Relay, das Sie selbst bauen müssen. Sobald Sie SSO, ACLs oder automatische Peer-Discovery wollen, bauen Sie das nach, was die anderen drei bereits sind.

Tailscale

Stärkstes Argument: die beste Erfahrung in dieser Kategorie. Die Clients sind auf jeder Plattform exzellent, NAT-Traversal "funktioniert einfach" über DERP, SSO und ACLs sind erstklassig, und es gibt keine Control Plane zu betreiben. Wenn Ihr Ziel ein funktionierendes Mesh noch heute Nachmittag ist und Sie keine Infrastruktur betreiben wollen, ist das der kürzeste Weg.

Größte Schwäche: Der Koordinationsserver ist Closed Source und wird von Tailscale gehostet, und die Preisgestaltung erfolgt pro Nutzer: ein kostenloser Personal-Tier (6 Nutzer, unbegrenzte Geräte, Stand Juli 2026), danach Standard für $8/user/month und Premium für $18/user/month. Für ein Infrastrukturteam ist das in Ordnung; für eine große oder kostensensitive Fleet sind das Per-Seat-Modell und die geschlossene Control Plane die zwei Dinge, die Menschen zu Headscale oder NetBird treiben.

Headscale

Stärkstes Argument: Tailscales Client-Erfahrung mit einer Control Plane, die Ihnen gehört. Sie betreiben einen einzigen Open-Source-Server (derzeit v0.29.x, Stand Juli 2026) und richten die offiziellen Tailscale-Clients darauf aus, sodass Sie die ausgereiften Apps behalten, während Koordination, Keys und ACLs auf Ihrer eigenen Hardware liegen, ganz ohne Rechnung pro Seat. ACL-Unterstützung (die Policy-v2-Engine) und ein eingebettetes DERP-Relay sind vorhanden.

Größte Schwäche: Es ist ein Community-Projekt, beschränkt auf ein einzelnes Tailnet, bewusst nicht das mandantenfähige Enterprise-Console-Produkt, das Tailscale verkauft. Es gibt keine offizielle Admin-GUI (UIs stammen von Drittanbietern), und das Projekt erklärt ausdrücklich, dass der Betrieb hinter Reverse Proxys oder in Containern nicht unterstützt wird, auch wenn Leute das trotzdem tun. Es passt hervorragend für ein Team oder eine Organisation; es versucht nicht, eine Managed-Plattform zu sein.

NetBird

Stärkstes Argument: die offenste und funktional vollständigste self-hosted Option. Client und Control Plane sind beide Open Source und vollständig self-hostbar, es liefert Identity/SSO mit (ein eingebetteter IdP im Standard-Self-Host-Stack, plus OIDC zu Keycloak/Authentik/Entra/Okta), gruppenbasierte Zugriffsrichtlinien, und es nutzt Kernel-WireGuard unter Linux für den schnellsten Datenpfad. Neuere Releases haben sogar einen eingebauten Reverse Proxy hinzugefügt, um interne Dienste ohne offene Ports zugänglich zu machen (Beta). Ist "alles self-hosten, mit eingebauter Identity" das Ziel, ist NetBird die vollständigste Antwort.

Größte Schwäche: Es ist das jüngste und das aufwendigste im Betrieb: Management-, Signal- und Relay-Dienste plus ein IdP, gegenüber Headscales einzelner Binary. Es entwickelt sich schnell weiter (v0.74.x, Stand Juli 2026, mit häufigen Releases und manchen Features noch in Beta), was gut für den Funktionsumfang ist, aber auch bedeutet, dass Sie ein sich schneller bewegendes Ziel verfolgen. Planen Sie mehr Zeit für Setup und Upgrades ein als bei Tailscale oder Headscale.

Die Betreiberperspektive, die die Suchergebnisse der Anbieter ignorieren

Die Hälfte der Suchergebnisse zu diesem Thema stammt von NetBird selbst (deren eigenem Knowledge Hub) oder einem Vendor-Partner, und keines davon behandelt den Fall, der für einen Infrastrukturbetreiber zählt: ein Mesh zu nutzen, um sicher Management- und Out-of-Band-Netzwerke zu erreichen.

Das Muster ist ein WireGuard-basiertes Mesh mit Subnet-Routing: Ein Relay/Exit-Node innerhalb eines geschützten Netzwerks kündigt Routen dorthin an, sodass autorisierte Mesh-Mitglieder ein IPMI/BMC-VLAN, ein OOB-Management-Segment oder ein internes Service-Netzwerk erreichen können, ohne davon irgendetwas dem öffentlichen Internet auszusetzen. Gut umgesetzt ersetzt das das Muster "Jump Box mit öffentlicher IP" durch ein identitätsgesteuertes Overlay: Der Zugriff ist an SSO gebunden und wird zentral entzogen, die Management Plane hat nie einen öffentlichen Listener, und jeder Hop ist Ende-zu-Ende WireGuard-verschlüsselt. Tailscale, Headscale und NetBird unterstützen alle Subnet-Routing; die Wahl zwischen ihnen ist dieselbe Frage nach dem Eigentum an der Control Plane wie überall sonst, mit dem zusätzlichen Gewicht, dass speziell für den Infrastrukturzugriff viele Betreiber den Koordinationsserver auf ihrer eigenen Hardware wollen (Headscale oder self-hosted NetBird) statt auf der eines Dritten.

Der praktische Rat für diesen Anwendungsfall: Kündigen Sie nur das konkrete Management-Subnetz an, das Sie brauchen, statt einer breiten Route, sichern Sie es hinter einer ACL ab, die an die kleinstmögliche Gruppe gebunden ist, und halten Sie den Subnet-Router selbst gepatcht und überwacht; er ist gerade zu einer Brücke in Ihr sensibelstes Netzwerk geworden und verdient daher dieselbe Sorgfalt wie ein Bastion-Host.

Fazit, mit Bedingungen

• Wählen Sie Tailscale, wenn Sie den geringsten Betriebsaufwand und die besten Clients wollen, eine geschlossene gehostete Control Plane für Sie kein Problem ist und Pricing pro Nutzer zu Ihrer Teamgröße passt. Es ist die richtige Standardwahl für Zero-Ops-Teams.
• Wählen Sie Headscale, wenn Sie die Tailscale-Erfahrung lieben, aber den Koordinationsserver auf eigener Hardware brauchen: ein Team oder eine Organisation, ein einzelnes Tailnet, keine Rechnung pro Seat. Die sauberste Antwort für "Tailscale-UX, self-hosted Control".
• Wählen Sie NetBird, wenn Sie alles offen und self-hosted wollen, mit eingebauter Identity/SSO und Zugriffsrichtlinien, und Sie bereit sind, dafür ein paar zusätzliche Dienste zu betreiben. Die beste Wahl für ein vollständig selbst kontrolliertes Zero-Trust-Mesh.
• Wählen Sie rohes WireGuard, wenn Ihre Topologie klein und statisch ist, Sie den schlankstmöglichen, schnellsten, am besten prüfbaren Pfad wollen und es Ihnen nichts ausmacht, Keys und Konfiguration selbst zu verwalten.

Speziell für einen Infrastrukturbetreiber ist das Zünglein an der Waage meist das Eigentum an der Control Plane für den Zugriff auf das Management-Netzwerk: Das zieht Richtung Headscale oder self-hosted NetBird statt der SaaS-Option, selbst wenn Tailscale am ersten Tag die einfachere Wahl wäre.

Häufig gestellte Fragen

Ist Tailscale einfach nur WireGuard?

Nein. Tailscale nutzt das WireGuard-Protokoll für seine Data Plane, setzt aber eine komplette Control Plane obendrauf: einen Koordinationsserver für Key-Distribution und Peer-Discovery, DERP-Relays für NAT-Traversal, SSO und ACLs. Und im Client kommt eine Userspace-Implementierung von WireGuard (wireguard-go) zum Einsatz statt des Kernel-Moduls. Tailscale ist also WireGuard plus alles, was WireGuard bewusst weglässt.

Ist Headscale produktionsreif?

Für den vorgesehenen Einsatzbereich ja: ein einzelnes Tailnet für ein Team oder eine Organisation, betrieben von Leuten, die es gewohnt sind, einen Open-Source-Server selbst zu betreiben. Es unterstützt ACLs und ein eingebettetes DERP-Relay und arbeitet mit den offiziellen Tailscale-Clients zusammen. Was es nicht ist: eine mandantenfähige, per GUI verwaltete Enterprise-Plattform; das ist Tailscales kostenpflichtiges Produkt. Setzen Sie Headscale für ein Deployment innerhalb einer einzelnen Organisation ein, und es läuft solide; rechnen Sie damit, es über CLI/API zu steuern und Ihr eigenes OIDC mitzubringen.

Lässt sich NetBird vollständig selbst hosten?

Ja. Das ist sein zentrales Merkmal. Sowohl die Clients als auch die Control Plane (Management-, Signal- und Relay-Dienste) sind Open Source und self-hostbar, und der Standard-Self-Host-Stack enthält einen eingebetteten Identity Provider, sodass Sie das gesamte Mesh (inklusive SSO) auf Ihrer eigenen Infrastruktur betreiben können, ganz ohne Abhängigkeit von der Cloud eines Anbieters.

Was ist am schnellsten?

Bei einer Standardkonfiguration hat rohes Kernel-WireGuard (und NetBirds Kernel-Modus unter Linux) einen kleinen Vorsprung gegenüber Userspace-Implementierungen wie der von Tailscale, weil es die User/Kernel-Übergänge pro Paket vermeidet; Tailscales eigene Benchmarks setzen Kernel-WireGuard bei 2.66 Gbit/s an, gegenüber 2.42 für unoptimiertes wireguard-go. Aber MTU und ob eine Verbindung direkt oder über ein Relay läuft, beeinflussen den Durchsatz weit stärker als die Produktwahl, und bei typischem Traffic unterhalb eines Gigabit ist der Unterschied nicht wahrnehmbar. Entscheiden Sie anhand von Betrieb und Funktionsumfang, nicht anhand eines Benchmarks, außer Sie wollen schnelle Leitungen auslasten.

Wo Sie die Control Plane, das Relay oder den Exit-Node betreiben

Jede Option hier, außer reinem SaaS-Tailscale, braucht einen Host: Headscales Koordinationsserver, NetBirds Management/Signal/Relay-Stack, ein self-hosted DERP-Node oder ein WireGuard-Exit/Subnet-Router wollen alle eine kleine, always-on Maschine mit niedriger Latenz und einer stabilen öffentlichen IP. Das ist ein natürlicher Fit für einen VPS in unserer Cloud, ausreichend für eine Control Plane und ein Relay, im selben ASN-55285-Netzwerk mit permanenter DDoS-Mitigation vor dem öffentlichen Listener. Routen Sie in schwerere Infrastruktur, oder betreiben Sie Exit-Nodes mit Line Rate, gibt Ihnen ein Dedicated Server die ungeteilte Bandbreite und die Kontrolle auf Kernel-Ebene, die WireGuard belohnt.

Bauen Sie schon direkt mit WireGuard? Unsere Guides zu einem Site-to-Site-VPN mit WireGuard auf VyOS und einem flexiblen Router- und VPN-Backbone auf VyOS decken das Rohprotokoll-Ende dieses Spektrums ab, und unser Linux-Distributionsguide deckt das Betriebssystem ab, das darunter läuft, egal wofür Sie sich entscheiden.