Headscale vs WireGuard (2026): Das eine ist der Tunnel, das andere verteilt die Schlüssel

Affiliate-Hinweis - Dieser Artikel enthält einen Contabo-Affiliate-Link. Wenn Sie über unseren Link einen VPS bestellen, erhalten wir eine Provision, ohne dass Ihnen Mehrkosten entstehen. Die Angaben zu Headscale und WireGuard wurden am 8. Oktober 2026 in der offiziellen Dokumentation der jeweiligen Projekte gelesen.

Kurze Antwort: "Headscale vs WireGuard" ist keine Wahl zwischen zwei VPN-Protokollen. WireGuard ist der Tunnel. Headscale ist ein Kontrollserver, der Tailscale-Clients mitteilt, welche WireGuard-Schlüssel, Adressen und Routen sie verwenden sollen, damit Sie diese nicht von Hand schreiben müssen. Nehmen Sie reines WireGuard, wenn Sie einen Server und eine Handvoll Geräte haben, die nur diesen Server erreichen müssen. Nehmen Sie Headscale, wenn viele Geräte einander erreichen sollen, über NAT hinweg, mit Namen, Zugriffsregeln und ohne Konfigurationsdatei, die auf jeder Maschine gepflegt werden muss.

Zwei Schichten, keine zwei Rivalen

Das WireGuard-Projekt beschreibt seine Aufgabe in einem Satz: Es kapselt IP-Pakete sicher in UDP. Sie legen eine Schnittstelle an, geben ihr Ihren privaten Schlüssel und die öffentlichen Schlüssel Ihrer Peers, und die Pakete fließen. Dieselbe Seite sagt ebenso deutlich, was fehlt: Alle Fragen der Schlüsselverteilung und der verteilten Konfiguration liegen außerhalb des Umfangs von WireGuard ("out of scope" im Original).

Genau diese fehlende Schicht liefert Headscale. Das README definiert es als quelloffene, selbst gehostete Implementierung des Tailscale-Kontrollservers und beschreibt diesen Server als Austauschpunkt der öffentlichen WireGuard-Schlüssel der Knoten im Netz: Er vergibt die IP-Adressen der Clients und macht die von ihnen angekündigten Routen bekannt.

Der eigentliche Vergleich lautet also:

• Reines WireGuard: Die Kontrollebene sind Sie. Sie erzeugen Schlüssel, wählen Adressen, schreiben jeden [Peer]-Block und kopieren ihn auf beide Seiten.
• Headscale: Die Kontrollebene ist ein Dienst, den Sie hosten. Die Geräte führen den Tailscale-Client aus, melden sich an Ihrem Server an und erhalten ihre Peers automatisch.

In beiden Fällen wird der Verkehr zwischen Ihren Maschinen mit dem WireGuard-Protokoll verschlüsselt.

Was reines WireGuard von Ihnen verlangt

Ein WireGuard-Netz wird durch Konfigurationsdateien definiert. Jeder Peer ist ein öffentlicher Schlüssel plus die Tunneladressen, die er verwenden darf. Das Projekt nennt das Cryptokey Routing:

[Interface]
PrivateKey = <server-private-key>
Address = 10.8.0.1/24
ListenPort = 51820

[Peer]
PublicKey = <laptop-public-key>
AllowedIPs = 10.8.0.2/32

Für einen zentralen Server mit wenigen Clients ist das kurz und durchschaubar, und außer der Schnittstelle selbst läuft nichts. Unsere Anleitung zu WireGuard auf Contabo beschreibt diesen Aufbau von Anfang bis Ende, und wg-easy setzt eine Weboberfläche darauf, ohne das Modell zu ändern.

Der Aufwand zeigt sich, wenn das Netz in eine bestimmte Richtung wächst:

• Jedes neue Gerät bedeutet mindestens zwei geänderte Dateien. Der neue Peer braucht den Server, der Server braucht den neuen Peer.
• Ein volles Mesh vervielfacht das. Sollen 10 Geräte jeweils die 9 anderen direkt erreichen, sind 45 Paare zu beschreiben, auf beiden Seiten.
• Jemand muss erreichbar sein. Ein Tunnel wird zu einem Endpunkt aufgebaut, einer IP-Adresse und einem UDP-Port. Zwei Geräte, die beide hinter NAT sitzen, haben füreinander keinen solchen Endpunkt. Das ist die Lage, die unsere Anleitung zu WireGuard hinter CGNAT beschreibt. Die übliche Antwort: alles über den Server leiten.
• Namen und Zugriffsregeln bauen Sie selbst. WireGuard gibt Ihnen Adressen. DNS und Filterung zwischen Peers sind eigene Arbeit.

Nichts davon ist ein Mangel. Es ist der Umfang, den das Projekt gewählt hat, und für einen einzelnen Server ist das ein Vorteil: weniger bewegliche Teile, ein UDP-Port.

Was Headscale hinzufügt

Mit Headscale schrumpft die Arbeit pro Gerät auf einen Befehl. Auf dem Server legen Sie einen Benutzer und einen vorab authentifizierten Schlüssel an:

headscale users create <USER>
headscale preauthkeys create --user <USER_ID>

und auf jedem Gerät mit installiertem Tailscale-Client:

tailscale up --login-server <YOUR_HEADSCALE_URL> --authkey <YOUR_AUTH_KEY>

Das Gerät erhält dann seine Adresse und seine Peers von Ihrem Server. Die Funktionsliste in der Headscale-Dokumentation umfasst unter anderem:

• MagicDNS und Split DNS, damit Maschinen Namen statt Adressen haben.
• ACLs in einer zentralen Richtliniendatei statt Firewall-Regeln auf jedem Host.
• Subnet-Router und Exit-Nodes, um ein ganzes LAN zu erreichen oder den gesamten Verkehr über einen Knoten zu leiten.
• Einen eingebetteten DERP-Server. Die Dokumentation beschreibt DERP als Relay, das vor allem dann genutzt wird, wenn zwischen zwei Knoten keine direkte Verbindung zustande kommt. Er ist standardmäßig deaktiviert.
• Registrierung über OpenID Connect, zusätzlich zu vorab authentifizierten Schlüsseln.

Was Headscale laut eigener Dokumentation nicht ist

Diesen Teil lassen Vergleiche gern aus, dabei schreibt ihn das Projekt selbst unmissverständlich auf.

• Umfang. Laut README deckt Headscale einen engen Umfang ab: ein einzelnes Tailscale-Netz (Tailnet), geeignet für den persönlichen Gebrauch oder eine kleine Open-Source-Organisation.
• Größenordnung. Die FAQ hält fest, dass Headscale keine Enterprise-Software ist ("not enterprise software") und dass Performance kein Schwerpunkt ist. Sie schätzt, dass der Server voraussichtlich Hunderte von Geräten bewältigt, wenn sich im Netz wenig ändert.
• Fehlende Funktionen. Funnel, Serve und Network Flow Logs sind in der Funktionsliste nicht abgehakt.
• Betrieb. Im README steht, dass die Maintainer den Einsatz von Reverse Proxies und Containern für Headscale weder unterstützen noch empfehlen. Offiziell unterstützt werden die Binärdateien und die DEB-Pakete. Container-Images werden der Bequemlichkeit halber gebaut.
• Clients. Die Geräte nutzen den Tailscale-Client. Das Projekt strebt an, dessen letzte 10 Versionen zu unterstützen, unter Linux, OpenBSD, FreeBSD, Windows, Android, macOS, iOS und tvOS.
• Datenbank. Empfohlen wird SQLite. PostgreSQL wird weiterhin unterstützt, aber als im "maintenance mode" befindlich beschrieben.

Headscale steht unter der BSD-3-Clause-Lizenz. Die neueste Version auf GitHub zum Zeitpunkt der Erstellung dieser Seite ist v0.29.4, veröffentlicht am 23. September 2026.

Was beide auf dem Server brauchen

Quellen: wireguard.com, das Headscale-README und die Headscale-Dokumentation (Voraussetzungen, Funktionen, FAQ, DERP), gelesen am 8. Oktober 2026.

Beide brauchen darunter dasselbe: eine kleine Linux-Maschine mit öffentlicher IP-Adresse, die online bleibt. Keines der beiden Projekte nennt auf den hier zitierten Seiten ein Minimum an RAM oder CPU, und ein Einstiegs-VPS ist für beide das übliche Zuhause.

Aktuelle Contabo-Cloud-VPS-Tarife ansehen

Was sollten Sie betreiben?

Wenn die letzte Zeile Ihrem Fall näherkommt, vergleicht Tailscale vs Headscale den gehosteten Dienst mit dem selbst gehosteten Server, und Tailscale vs selbst gehostetes WireGuard behandelt dieselbe Frage von der WireGuard-Seite.

Kann man beides betreiben?

Ja, und das ist ein vernünftiger Aufbau. Eine gewöhnliche WireGuard-Schnittstelle auf ihrem eigenen UDP-Port und ein Headscale-Dienst auf TCP 443 konkurrieren nicht um denselben Port. Eine gängige Aufteilung: ein WireGuard-Tunnel für eine feste Strecke, etwa die Site-to-Site-Verbindung zwischen zwei Netzen, und Headscale für die persönlichen Geräte, die unterwegs sind. Der Preis sind zwei Systeme, die aktuell gehalten werden müssen. Tun Sie es also nur, wenn jedes ein Problem löst, das das andere nicht löst.

Fazit

WireGuard ist ein Protokoll und überlässt Ihnen die Schlüsselverteilung. Headscale ist ein Weg, diese Verteilung selbst zu übernehmen, mit dem Tailscale-Client, auf einem Server unter Ihrer Kontrolle. Beginnen Sie mit reinem WireGuard, solange ein zentraler Server genügt. Wechseln Sie zu Headscale, wenn die Konfigurationsdateien zur Hauptsache dessen werden, was Sie pflegen, und lesen Sie vorher die Dokumentation: Sie sagt ausdrücklich, dass das Projekt für persönliche Netze und kleine Gruppen gebaut ist. Die Installation Schritt für Schritt finden Sie in unserer Anleitung zur Headscale-Kontrollebene.