Tailscale vs WireGuard: Der ehrliche Vergleich mit eigenen Messungen (2026)

Tailscale vs WireGuard ist ein schiefer Vergleich, und genau deshalb wird er so oft gesucht. WireGuard ist ein VPN-Protokoll: ein kleines, schnelles Stück Software, das zwei Rechner verschlüsselt verbindet, sobald beide die Schlüssel des anderen kennen. Tailscale ist ein Produkt, das WireGuard benutzt und alles drumherum erledigt: Schlüssel verteilen, Adressen vergeben, Geräte finden, sich durch Router und Firewalls durchschlagen. Die eigentliche Frage lautet also nicht „welches ist besser”, sondern: Willst du die Verwaltung selbst machen, oder soll sie jemand für dich machen?

Die meisten Vergleiche zu dem Thema bleiben bei Funktionslisten. Wir wollten wissen, was das in Zahlen bedeutet. Am 4. Oktober 2026 haben wir zwischen zwei unserer Server (Hetzner Nürnberg und Hetzner Helsinki, rund 24 ms auseinander) drei Varianten nebeneinander gemessen: die nackte Verbindung, einen Kernel-WireGuard-Tunnel und Tailscale mit einem selbst betriebenen Headscale als Steuerserver. Drei Befunde vorweg:

1. Beim Durchsatz lagen beide fast gleichauf: Kernel-WireGuard um 670 Mbit/s, Tailscale zwischen 475 und 750 Mbit/s. Und, für uns überraschend: Tailscale verbrauchte pro übertragenem Gigabyte nicht mehr CPU als Kernel-WireGuard, eher weniger.

2. Als wir die direkte Verbindung künstlich blockiert haben, fiel Tailscale auf sein Relay-Netz zurück und lief weiter. Mit 18 Mbit/s statt 600. Es funktioniert, aber es ist ein anderer Dienst.

3. Selbst mit eigenem Steuerserver hat der Tailscale-Client von sich aus Verbindungen zu Servern von Tailscale aufgebaut. Warum, und wie man das abstellt, steht weiter unten.

Tailscale vs WireGuard: die Kurzfassung

Wenn du nur eine Minute hast:

• WireGuard ist das Protokoll und die Kernel-Software. Kostenlos, quelloffen, seit Linux 5.6 (2020) fest im Kernel. Du schreibst pro Gerät eine Konfigurationsdatei mit Schlüsseln, IP-Adressen und dem Endpunkt der Gegenseite. Jeder neue Teilnehmer heißt: Dateien auf allen Geräten anpassen, mit denen er sprechen soll.
• Tailscale ist ein Dienst, der WireGuard-Verbindungen automatisch aufbaut. Du installierst den Client, meldest dich an, fertig. Der Client holt sich vom Steuerserver die Liste der anderen Geräte, tauscht Schlüssel aus, sucht den direkten Weg und weicht auf ein Relay aus, wenn kein direkter Weg möglich ist.
• Headscale ist ein quelloffener Nachbau des Tailscale-Steuerservers. Du nutzt die normalen Tailscale-Clients, aber die Verwaltung läuft auf deinem eigenen Server.

Die Daten selbst sind in allen drei Fällen mit WireGuard verschlüsselt. Tailscale sieht deinen Datenverkehr nicht, die privaten Schlüssel verlassen die Geräte nicht. Was Tailscale sieht und steuert, ist wer mit wem sprechen darf. Darauf kommen wir zurück, denn das ist der Teil, der in Sicherheitsdiskussionen meistens untergeht.

Was ist WireGuard?

WireGuard ist ein VPN-Protokoll, das Jason A. Donenfeld ab 2015 entwickelt hat. Es war von Anfang an als Gegenentwurf zu OpenVPN und IPsec gedacht: wenige tausend Zeilen Code statt hunderttausender, feste moderne Kryptografie (Curve25519, ChaCha20-Poly1305, BLAKE2s) statt einer Auswahl aus Dutzenden Verfahren, und keine Verhandlung darüber, welche Algorithmen benutzt werden. Was nichts zu verhandeln hat, kann sich nicht auf etwas Schwaches herunterhandeln lassen.

Auf unserem Ubuntu-Server ist das Kernelmodul 55 KB groß (komprimiert), das Verwaltungswerkzeug wg 100 KB. Mehr braucht es nicht.

Eine WireGuard-Verbindung besteht aus genau drei Dingen:

1. Einem Schlüsselpaar pro Gerät (wg genkey, wg pubkey).
2. Einer Interface-Konfiguration: eigener privater Schlüssel, eigene Tunnel-IP, Port.
3. Einer Liste von Peers: öffentlicher Schlüssel der Gegenseite, deren Tunnel-IPs (AllowedIPs) und, wenn bekannt, wo sie erreichbar ist (Endpoint).

So sieht das in der Praxis aus. Genau diese Befehle haben wir für die Messung benutzt:

# Auf beiden Servern: Schlüssel erzeugen
umask 077
wg genkey > privat.key
wg pubkey < privat.key > public.key

# Server B (Helsinki) wartet auf Verbindungen
ip link add wg0 type wireguard
wg set wg0 listen-port 51820 private-key privat.key \
  peer <PUBKEY_VON_A> allowed-ips 10.99.0.1/32
ip addr add 10.99.0.2/24 dev wg0
ip link set wg0 up

# Server A (Nürnberg) verbindet sich
ip link add wg0 type wireguard
wg set wg0 private-key privat.key \
  peer <PUBKEY_VON_B> endpoint 203.0.113.20:51820 allowed-ips 10.99.0.2/32
ip addr add 10.99.0.1/24 dev wg0
ip link set wg0 up

ping 10.99.0.2

Das ist der ganze Tunnel. Der erste Ping inklusive Schlüssel-Handshake brauchte bei uns 59 ms, danach lag die Laufzeit bei 24,5 ms, nur 0,6 ms über der direkten Verbindung (23,8 ms). Für den Dauerbetrieb schreibt man dasselbe in eine Datei unter /etc/wireguard/wg0.conf und startet sie mit systemctl enable --now wg-quick@wg0.

Und genau hier liegt das, was WireGuard nicht macht:

• Es verteilt keine Schlüssel. Du kopierst öffentliche Schlüssel von Hand oder per eigenem Skript.
• Es findet keine Wege. Wenn beide Seiten hinter einem Router ohne Portfreigabe sitzen, kommt keine Verbindung zustande.
• Es kennt keine Benutzer, keine Gruppen, keine Rechte. Wer den Schlüssel hat, ist drin, und darf alles, was die Firewall dahinter erlaubt.
• Es merkt sich nicht, dass ein Gerät verloren wurde. Den Schlüssel musst du auf allen Gegenstellen entfernen.

Bei zwei Servern ist das egal. Bei zehn Geräten, von denen drei Laptops in wechselnden WLANs sind, wird es Arbeit.

Was ist Tailscale?

Tailscale ist ein Unternehmen aus Kanada und gleichzeitig der Name seines Produkts. Der Client (tailscaled) läuft auf jedem Gerät, baut WireGuard-Verbindungen zu allen anderen Geräten im eigenen Netz auf (bei Tailscale heißt das „Tailnet”) und gibt jedem Gerät eine feste Adresse aus dem Bereich 100.64.0.0/10.

Der wichtige Unterschied zu einem klassischen VPN: Es gibt keinen zentralen VPN-Server, durch den alle Daten laufen. Der Steuerserver (bei Tailscale „Coordination Server”) verteilt nur Informationen: welche Geräte es gibt, welche öffentlichen Schlüssel sie haben, unter welchen Adressen sie gerade erreichbar sein könnten und was sie miteinander dürfen. Die Daten selbst fließen direkt von Gerät zu Gerät. Das nennt man ein Mesh-Netz.

Was Tailscale zusätzlich zu WireGuard mitbringt:

• Anmeldung über bestehende Konten (Google, Microsoft, GitHub, eigener OIDC-Anbieter) statt Schlüsseldateien.
• NAT-Durchdringung: Die Clients probieren gleichzeitig viele Wege, um auch hinter Heimroutern und Mobilfunk-NAT eine direkte Verbindung herzustellen.
• DERP-Relays: Wenn gar kein direkter Weg geht, laufen die (weiterhin verschlüsselten) Pakete über Relay-Server von Tailscale.
• ACLs: Regeln wie „Laptops der Gruppe dev dürfen auf Port 22 der Server mit dem Tag prod”.
• MagicDNS: Geräte sind unter ihrem Namen erreichbar statt unter einer IP.
• Exit Nodes und Subnet Router: ein Gerät leitet Verkehr ins Internet oder in ein ganzes lokales Netz weiter.
• Tailscale SSH, Funnel, Serve: Zusatzfunktionen, die über reines Netzwerken hinausgehen.

Wichtig für den Vergleich: Auf Linux benutzt Tailscale nicht das WireGuard-Kernelmodul, sondern seine eigene WireGuard-Implementierung in Go, die im Benutzerbereich läuft (wireguard-go). Lange galt das als der große Nachteil von Tailscale: langsamer, mehr CPU. Genau das wollten wir prüfen.

Video: Björn Albers richtet einen WireGuard-Server Schritt für Schritt ein. Achtung, das Video enthält Werbung für einen Hosting-Anbieter. Für das Grundverständnis, wie viel Handarbeit reines WireGuard bedeutet, ist es trotzdem gut.

Was ist der Unterschied zwischen Tailscale und WireGuard?

Die Tabelle fasst zusammen, was wir gemessen und nachgelesen haben. Die Messwerte stammen aus unserem Test vom 4. Oktober 2026, die Preise von der Tailscale-Preisseite am selben Tag.

Der Kern ist die vorletzte und letzte Zeile: WireGuard gibt dir Verschlüsselung und sonst nichts. Tailscale gibt dir Verwaltung, und du gibst dafür einen Teil der Kontrolle ab.

Unsere Messung: Wie wir getestet haben

Damit du die Zahlen einordnen kannst, hier der Aufbau, ohne Schönfärberei:

• Sender: unser Entwicklungsserver bei Hetzner in Nürnberg, 12 vCPU, Ubuntu 24.04, Kernel 6.8.
• Empfänger: ein Hetzner-Cloud-Server in Helsinki, 4 vCPU (AMD EPYC Genoa), Ubuntu 24.04, Kernel 6.8. Auf ihm läuft produktiv ein Trading-Dienst und ein anderer WireGuard-Tunnel. Beide haben wir nicht angefasst.
• Werkzeug: iperf3 3.16, TCP, jeweils 10 Sekunden, mehrere Läufe.
• WireGuard: Kernelmodul, wireguard-tools 1.0.20210914, eigenes Interface wgtest0 auf UDP-Port 51999.
• Tailscale: Client 1.102.4 (offizielles statisches Paket), auf beiden Seiten als eigener Prozess mit eigenem State-Verzeichnis, eigenes TUN-Interface.
• Steuerserver: Headscale 0.29.4, nur für diesen Test, auf dem Nürnberger Server, per Firewall nur für den Helsinki-Server freigegeben.
• CPU-Messung: /proc/stat auf dem Empfänger vor und nach jedem Lauf. Daraus die gesamte CPU-Zeit, die das System beschäftigt war, geteilt durch die übertragenen Gigabyte. Das schließt iperf3 selbst mit ein, ist also eine Systemzahl, keine reine Tunnelzahl.

Nach dem Test haben wir alles wieder entfernt: Interfaces, Prozesse, die temporäre Firewall-Freigabe, State-Verzeichnisse. Der produktive Tunnel in Helsinki hatte währenddessen weiter regelmäßige Handshakes.

Ein kleiner Stolperstein am Rande, weil er jedem passieren kann: Beim Neustart des Test-Headscale haben wir den Prozess mit pkill -f "headscale serve -c ..." beendet. Das Muster stand aber auch in der Befehlszeile der eigenen Shell, und pkill hat die gleich mit beendet. Seitdem merken wir uns PIDs in einer Datei und beenden gezielt. Dasselbe ist uns schon beim Vergleich von Caddy und Nginx passiert, man lernt es offenbar nicht beim ersten Mal.

Ist Tailscale langsamer als WireGuard?

Kurze Antwort: In unserem Test nicht nennenswert. Lange Antwort mit Zahlen:

Was auffällt:

1. Die Leitung selbst schwankt stark. Ohne Tunnel lagen die Werte zwischen 484 und 756 Mbit/s, mit vielen TCP-Wiederholungen (bis 1.310 pro Lauf). Das ist eine Verbindung über das öffentliche Internet zwischen zwei Ländern, kein Laborkabel.
2. Kernel-WireGuard war am gleichmäßigsten. Alle Läufe zwischen 648 und 689 Mbit/s, im ersten Lauf null Wiederholungen. Gut möglich, dass der Tunnel die Paketgröße so verändert, dass weniger verworfen wird. Das ist eine Vermutung, wir haben es nicht weiter untersucht.
3. Tailscale streute mehr, im Mittel etwas unter WireGuard, im besten Lauf darüber. Bei unseren rund 600 bis 700 Mbit/s ist der Unterschied für fast jeden Einsatzzweck egal.

Die ältere Faustregel „Tailscale ist im Benutzerbereich, also langsamer” stammt aus einer Zeit, in der wireguard-go jedes Paket einzeln verarbeitet hat. Tailscale hat in den letzten Jahren Segmentierungs- und Zusammenfassungs-Optimierungen (GSO/GRO) für TUN und UDP eingebaut, die viele kleine Pakete zu großen bündeln. Auf aktueller Hardware und aktuellem Kernel ist die Lücke klein geworden. Bei Verbindungen im Bereich von mehreren Gigabit pro Sekunde, also im Rechenzentrum oder lokalen Netz, kann das anders aussehen. Das haben wir nicht gemessen.

CPU-Verbrauch: der überraschende Teil

Durchsatz allein sagt wenig, wenn eine Seite dafür einen ganzen Prozessorkern verbrennt. Deshalb haben wir die CPU-Zeit des Empfängers pro übertragenem Gigabyte gemessen:

Verschlüsselung kostet also etwa das Drei- bis Neunfache dessen, was die reine Übertragung kostet, egal welche Variante. Kernel-WireGuard erledigt die Entschlüsselung in Software-Interrupts im Kernel, Tailscale im eigenen Prozess. Unterm Strich war Tailscale auf dieser Maschine nicht teurer, eher etwas günstiger. Während der Läufe zeigte top den Tailscale-Prozess in Helsinki bei 100 % eines Kerns, also einen von vier Kernen voll ausgelastet. Bei einer kleinen Maschine mit einem oder zwei Kernen wird das spürbar.

Wir sagen das so vorsichtig, weil die Messung Grenzen hat: ein Rechnerpaar, eine Strecke, TCP mit einem Datenstrom, virtuelle Maschinen mit Nachbarn auf derselben Hardware. Auf einem Raspberry Pi oder einem Router mit schwacher CPU sieht das Verhältnis wahrscheinlich anders aus, weil dort ein Prozesswechsel pro Paket stärker ins Gewicht fällt.

Der Fund, der eine Messung fast verdorben hätte

Zwei Tailscale-Läufe brauchten plötzlich 28 bis 31 CPU-Sekunden pro GB, also doppelt so viel. Ein Blick auf tailscale status erklärte es:

100.64.0.1  ts-hel  tstest  linux  active; direct 10.99.0.2:41699

10.99.0.2 ist die Adresse unseres WireGuard-Testtunnels. Tailscale hatte das neue Interface entdeckt, die Adresse als möglichen Weg zur Gegenseite gemeldet, und weil der Weg funktionierte, lief der Tailscale-Verkehr durch den WireGuard-Tunnel. Doppelt verschlüsselt, doppelte CPU-Last, ohne Fehlermeldung. Nachdem wir den Testtunnel abgebaut hatten, wechselte Tailscale von selbst zurück auf die öffentliche IPv6-Adresse.

Das ist kein Fehler von Tailscale, sondern genau sein Versprechen: „Ich finde einen Weg.” Es heißt aber auch: Wenn du Tailscale neben anderen VPNs betreibst, prüfe mit tailscale status, welcher Weg tatsächlich benutzt wird. Ein Tunnel im Tunnel fällt im Alltag nicht auf, er macht nur alles etwas langsamer und teurer.

Latenz und MTU

Bei der Laufzeit (20 Pings, 200 ms Abstand) lagen die Varianten so:

• direkt: 23,8 ms im Mittel
• WireGuard: 24,5 ms
• Tailscale: 30,0 ms im Mittel, aber mit einem Ausreißer von 128 ms; ohne ihn ebenfalls um 24,5 ms. tailscale ping meldete 26 ms.

Beide Tunnel kosten also weniger als eine Millisekunde. Der Ausreißer bei Tailscale kam in einer Phase, in der der Client gerade Wege neu bewertet hat.

Ein Detail, das in Vergleichen selten auftaucht: Die MTU (maximale Paketgröße) ist unterschiedlich. WireGuard setzt standardmäßig 1420 Byte, Tailscale 1280 Byte. Tailscale wählt bewusst den kleinsten Wert, den IPv6 garantiert, damit Pakete auch über Mobilfunk und verschachtelte Tunnel nicht zerstückelt werden. Kleinere Pakete bedeuten etwas mehr Overhead, dafür weniger Ärger mit Verbindungen, die „irgendwie hängen”, weil große Pakete unterwegs verschwinden.

Was passiert, wenn kein direkter Weg möglich ist?

Das ist die Situation, für die Tailscale eigentlich gebaut wurde: Zwei Geräte, beide hinter Routern, keiner hat einen Port freigegeben. Mit reinem WireGuard gibt es dann keine Verbindung, zumindest eine Seite muss erreichbar sein.

Wir haben den Fall nachgestellt, indem wir auf dem Nürnberger Server per nftables alle UDP-Pakete zum Tailscale-Port der Gegenseite verworfen haben. Nach rund 20 Sekunden meldete der Client:

100.64.0.1  ts-hel  tstest  linux  active; relay "hel"
pong from ts-hel (100.64.0.1) via DERP(hel) in 29ms

Die Verbindung lief weiter, über einen DERP-Server von Tailscale in Helsinki. Die Laufzeit stieg nur leicht auf 29 ms, weil das Relay zufällig in derselben Stadt wie das Ziel steht. Der Durchsatz dagegen:

18 Mbit/s über das Relay, statt rund 600 Mbit/s direkt.

Das ist kein Fehler, sondern Absicht. Die Relays sind ein kostenloser Notbehelf für alle Tailscale-Nutzer weltweit und werden gedrosselt. Für SSH, ein Admin-Panel oder gelegentliche Dateizugriffe reicht das völlig. Für Backups oder Medien-Streaming nicht.

Nachdem wir die Sperre aufgehoben hatten, war die direkte Verbindung nach 4 Sekunden wieder da, ohne dass wir etwas tun mussten.

Die praktische Lehre: Wenn sich Tailscale „langsam” anfühlt, ist es fast immer das Relay. tailscale status zeigt relay statt direct, und tailscale netcheck verrät, warum. Oft hilft es, auf einer Seite einen UDP-Port freizugeben (Standard 41641) oder IPv6 zu aktivieren. In unserem Fall lief die direkte Verbindung übrigens über IPv6, obwohl beide Server auch IPv4 haben.

Was passiert, wenn der Steuerserver ausfällt?

Das ist die zweite Frage, die man sich bei jedem verwalteten Dienst stellen sollte. Wir haben unseren Test-Headscale einfach beendet.

Bestehende Verbindungen liefen weiter. Pings über den Tunnel: 0 % Verlust, 25 ms. Die Geräte kennen sich bereits, die WireGuard-Schlüssel sind ausgetauscht, der Steuerserver ist für den laufenden Verkehr nicht nötig.

Ein Neustart des Clients während des Ausfalls war etwas anderes. Wir haben tailscaled auf dem Nürnberger Server neu gestartet, während Headscale aus war. Ergebnis:

You are logged out. The last login error was: fetch control key:
  ... dial tcp ...:18780: connect: connection refused
load netmap from cache: netmap cache is not available

Kein Steuerserver, keine Liste der Gegenstellen, keine Verbindung: 100 % Paketverlust. Erst als Headscale wieder lief, war der Tunnel nach 4 Sekunden zurück.

Das ist der eigentliche Preis von Tailscale gegenüber WireGuard. Ein WireGuard-Tunnel hängt nur von den beiden Enden ab. Ein Tailscale-Gerät, das genau dann neu startet, wenn der Steuerserver nicht erreichbar ist, bleibt offline. Bei Tailscales eigener Cloud ist das selten, kommt aber vor. Bei einem selbst betriebenen Headscale bist du selbst dafür zuständig, und gerade beim Wartungsfenster des Headscale-Servers kann es passieren, dass genau der Server neu startet, über den du dich eigentlich einloggen wolltest.

Faustregel daraus: Den Zugang, mit dem du einen kaputten Server reparierst, hängt man nicht an ein System, das von genau diesem Server abhängt. Wir haben für Notfälle immer einen direkten SSH-Zugang mit Schlüssel über die öffentliche Adresse, abgesichert per Firewall und fail2ban.

Ist Tailscale sicher? Und ist WireGuard sicherer?

Die Verschlüsselung ist in beiden Fällen dieselbe: WireGuard. Tailscale kann deinen Datenverkehr nicht mitlesen, die privaten Schlüssel bleiben auf den Geräten. Das sagt Tailscale selbst, und es ergibt sich aus der Architektur.

Der Unterschied liegt woanders. Bei WireGuard entscheidest du, welche öffentlichen Schlüssel ein Gerät akzeptiert. Bei Tailscale entscheidet der Steuerserver, welche Schlüssel und Adressen an deine Geräte verteilt werden. Ein kompromittierter Steuerserver, ein übernommenes Admin-Konto oder ein gestohlener Anmeldeschlüssel kann ein fremdes Gerät in dein Netz holen. Das Gerät kann dann nicht den Verkehr anderer mitlesen, aber es kann alles erreichen, was deine ACLs erlauben.

Tailscale hat dafür Gegenmittel: Tailnet Lock (neue Geräte müssen von bereits vertrauenswürdigen Geräten signiert werden, nicht nur vom Steuerserver), kurzlebige und nicht wiederverwendbare Anmeldeschlüssel, und ACLs, die standardmäßig viel enger sein sollten als „alle dürfen alles”. In unserem Test haben wir aus Bequemlichkeit einen wiederverwendbaren Schlüssel mit zwei Stunden Gültigkeit benutzt. Für den Produktivbetrieb wäre das genau die Art Schlüssel, die man nicht in einem Skript oder einer Umgebungsvariable herumliegen lassen will.

Video (englisch): Devsplainers vergleicht Tailscale, WireGuard und Headscale aus der Frage heraus, wer eigentlich die Schlüssel kontrolliert. Das ist der richtige Blickwinkel für die Sicherheitsfrage.

Die Verbindungen, die wir nicht bestellt hatten

Während des Tests haben wir mit ss -tnp nachgesehen, mit wem tailscaled spricht. Erwartet hatten wir nur unseren eigenen Headscale. Tatsächlich bestanden vier Verbindungen:

1. zu unserem Headscale (wie erwartet),
2. zu zwei DERP-Relay-Servern von Tailscale (derp26b.tailscale.com, derp28d.tailscale.com),
3. zu einer Adresse im Netz von log.tailscale.com.

Punkt 2 war unsere eigene Konfiguration: Wir hatten Headscale angewiesen, die öffentliche Relay-Liste von Tailscale zu benutzen, statt einen eigenen DERP-Server zu betreiben. Das ist die Standardvorlage und für einen Test praktisch. Wer das nicht will, schaltet den eingebauten DERP-Server von Headscale ein und entfernt die Tailscale-URL.

Punkt 3 ist Telemetrie: Der Tailscale-Client lädt standardmäßig Diagnose-Logs hoch, auch wenn er gar nicht mit Tailscales Steuerserver verbunden ist. Abschalten lässt sich das mit dem Startparameter --no-logs-no-support für tailscaled (oder über die Umgebungsvariable TS_NO_LOGS_NO_SUPPORT=true). Der Name sagt es: Dann gibt es von Tailscale auch keinen Support. Bei einem Headscale-Setup bekommt man den sowieso nicht.

Wir erwähnen das nicht als Vorwurf. Es steht in der Dokumentation. Aber wer Headscale wählt, weil er „unabhängig von Tailscale” sein will, sollte wissen, dass das nicht der Standardzustand ist, sondern eine Konfiguration, die man aktiv herstellen muss.

Headscale: Tailscale ohne Tailscale-Cloud

Headscale ist ein unabhängiges Open-Source-Projekt, das den Steuerserver von Tailscale nachbaut. Es wird nicht von Tailscale entwickelt, aber Tailscale-Mitarbeiter tragen nach eigenen Angaben dazu bei, und die offiziellen Clients unterstützen fremde Steuerserver über --login-server.

So sah unser Testaufbau aus, gekürzt auf das Wesentliche:

# Headscale (eine einzelne Binärdatei, 51 MB)
./headscale serve -c config.yaml

# Benutzer und Anmeldeschlüssel anlegen
./headscale users create team
./headscale preauthkeys create --user 1 --expiration 1h

# Auf jedem Gerät
tailscale up --login-server=https://vpn.example.com --authkey=<SCHLUESSEL>

Die Konfigurationsdatei hatte bei uns 37 Zeilen. Vom Start von Headscale bis zum ersten erfolgreichen Ping zwischen beiden Servern vergingen wenige Minuten, tailscale up selbst dauerte knapp 2 Sekunden.

Was Headscale gut kann: Geräte, Benutzer, Anmeldeschlüssel, ACLs, MagicDNS, Subnet Router und Exit Nodes, ein eingebauter DERP-Server. Was fehlt oder schwächer ist: manche neueren Tailscale-Funktionen (etwa Funnel, also öffentliche Freigaben über Tailscales Infrastruktur), eine offizielle Weboberfläche (es gibt Drittprojekte), und natürlich Tailscales Betriebserfahrung. Headscale unterstützt außerdem jeweils nur Client-Versionen ab einer Mindestversion; bei uns meldete es beim Start, dass Clients unter 1.80 abgelehnt werden. Wer Headscale betreibt, muss also Server und Clients im Blick behalten.

Für wen sich Headscale lohnt: für alle, die Tailscales Bequemlichkeit wollen, aber die Liste der Geräte und Rechte nicht bei einem externen Anbieter liegen haben möchten, oder die mehr als sechs Personen im Netz haben, ohne pro Nutzer zu bezahlen. Für wen nicht: für alle, die genau keinen weiteren Server betreuen wollen. Dann ist die Tailscale-Cloud ehrlicher.

Was kostet Tailscale?

Stand der Preisseite am 4. Oktober 2026:

• Personal: 0 $, bis zu 6 Nutzer, unbegrenzte Nutzergeräte, 50 „tagged resources” (Server, Exit Nodes und ähnliches) inklusive. Nur für nicht-kommerzielle Nutzung.
• Standard: 8 $ pro Nutzer und Monat.
• Premium: 18 $ pro Nutzer und Monat.
• Enterprise: auf Anfrage.
• Zusätzliche tagged resources: 1 $ pro Stück und Monat.

Abgerechnet wird nach Nutzern, nicht nach Geräten. Wer ein Tailnet mit einer eigenen Firmendomain anlegt, landet automatisch in einer Business-Testphase. Preise ändern sich, im Zweifel gilt die Seite von Tailscale.

WireGuard und Headscale kosten nichts außer dem Server, auf dem sie laufen. Ein kleiner VPS reicht für Headscale. Was du dabei bezahlst, ist deine Zeit für Einrichtung, Updates und die Fehlersuche, wenn es mal nicht geht. Was ein VPS ist und worauf man bei der Wahl achtet, haben wir separat aufgeschrieben.

Wann WireGuard, wann Tailscale?

Aus unseren Messungen und aus dem, was wir selbst betreiben, ergibt sich ein ziemlich klares Bild.

Nimm reines WireGuard, wenn …

• du zwei oder drei feste Standorte verbinden willst, von denen mindestens einer eine öffentliche Adresse hat (Server zu Server, Büro zu Rechenzentrum, Heimserver zu VPS),
• du keine Abhängigkeit von einem weiteren Dienst willst, auch nicht von einem selbst betriebenen,
• du einen eigenen VPN-Zugang ins Internet brauchst (klassischer „VPN-Server”),
• die Konfiguration sich selten ändert.

Genau so läuft auf unserem Helsinki-Server seit Monaten ein WireGuard-Tunnel zu einem Partnerprojekt: zwei Enden, ein Schlüsselpaar, ein Keepalive alle 25 Sekunden. Da gibt es nichts zu verwalten, also braucht es auch keine Verwaltung.

Nimm Tailscale (oder Headscale), wenn …

• viele Geräte miteinander sprechen sollen, besonders Laptops und Handys in wechselnden Netzen,
• Geräte hinter NAT oder CGNAT sitzen, wo du keine Ports freigeben kannst (Mobilfunk, Glasfaser mit geteilter IPv4),
• mehrere Personen Zugang brauchen und du Rechte pro Person oder Gruppe vergeben willst,
• du Geräte schnell hinzufügen und wieder entfernen willst, ohne auf allen anderen Configs anzupassen.

Nimm Headscale statt Tailscale-Cloud, wenn …

• du die Bequemlichkeit von Tailscale willst, aber die Geräteliste selbst kontrollieren möchtest,
• du mehr als sechs Nutzer hast und nicht pro Kopf zahlen willst,
• du ohnehin Server betreibst und einer mehr nicht ins Gewicht fällt.

Typische Fehler, die wir gesehen (oder gemacht) haben

1. Tunnel im Tunnel. Tailscale nimmt jeden funktionierenden Weg, auch durch ein anderes VPN. Prüfen mit tailscale status.
2. Relay für Datenmengen. Backups über eine Relay-Verbindung laufen mit einem Bruchteil der Geschwindigkeit. Wer viel überträgt, sorgt für einen direkten Weg (UDP-Port oder IPv6).
3. Wiederverwendbare Anmeldeschlüssel in Skripten. Praktisch und gefährlich. Lieber kurzlebige, einmal nutzbare Schlüssel oder OAuth-Clients.
4. Keine ACLs. Standard bei Tailscale war lange „alle dürfen alle erreichen”. Das ist bequem und genau das Gegenteil von Zero Trust.
5. Den Notfallzugang ans VPN hängen. Wenn SSH nur noch über Tailscale erreichbar ist und der Steuerserver ausfällt, während der Server neu startet, bist du ausgesperrt.
6. Bei WireGuard: Port vergessen. WireGuard antwortet auf nichts, was nicht korrekt signiert ist. Ein blockierter UDP-Port sieht deshalb genauso aus wie ein falscher Schlüssel: Es passiert einfach nichts. wg show zeigt dann keinen „latest handshake”.
7. Bei WireGuard: AllowedIPs falsch verstanden. Das Feld ist gleichzeitig Routing-Tabelle und Absenderfilter. Steht dort 0.0.0.0/0, geht der gesamte Verkehr durch den Tunnel, auch wenn das nicht gewollt war.

Was wir nicht gemessen haben

Damit niemand mehr aus diesem Artikel liest, als drinsteht:

• Nur eine Strecke (Nürnberg–Helsinki), nur Rechenzentrums-Server mit guter Anbindung. Heimanschlüsse, WLAN und Mobilfunk verhalten sich anders.
• Nur TCP mit einem Datenstrom. Viele parallele Verbindungen, UDP-Anwendungen oder sehr viele kleine Pakete (etwa VoIP) haben wir nicht getestet.
• Keine schwache Hardware. Auf einem Raspberry Pi, einem NAS oder einem Router kann der Unterschied zwischen Kernel und Benutzerbereich deutlich größer sein.
• Keine Windows-, macOS- oder Handy-Clients. Dort gibt es kein Kernel-WireGuard im Linux-Sinne, beide Varianten laufen über Systemschnittstellen.
• Keinen Langzeitbetrieb von Tailscale bei uns. Wir haben es für diesen Test aufgebaut und wieder abgebaut.
• Die Tailscale-Cloud selbst nicht, sondern Headscale. Der Client ist derselbe, die Datenpfade auch. Verfügbarkeit und Funktionen des echten Tailscale-Steuerservers haben wir nicht geprüft.

Häufige Fragen

Was ist der Unterschied zwischen Tailscale und WireGuard?

WireGuard ist ein VPN-Protokoll, das zwei Geräte verschlüsselt verbindet, wenn beide sich gegenseitig konfiguriert haben. Tailscale ist ein Dienst, der WireGuard benutzt und die Konfiguration automatisch übernimmt: Schlüsselverteilung, Adressvergabe, Wegfindung durch NAT, Relay-Fallback, Benutzer und Rechte.

Basiert Tailscale auf WireGuard?

Ja. Die Verschlüsselung und das Paketformat sind WireGuard. Auf Linux nutzt Tailscale aber nicht das Kernelmodul, sondern eine eigene Implementierung in Go (wireguard-go), die im Benutzerbereich läuft.

Ist Tailscale langsamer als WireGuard?

In unserer Messung zwischen Nürnberg und Helsinki kaum: Kernel-WireGuard lag bei rund 670 Mbit/s, Tailscale zwischen 475 und 750 Mbit/s. Deutlich langsamer wird Tailscale, wenn keine direkte Verbindung möglich ist und der Verkehr über ein Relay läuft. Das waren bei uns 18 Mbit/s.

Verbraucht Tailscale mehr CPU als WireGuard?

Nicht in unserem Test. Pro übertragenem Gigabyte lag Tailscale bei 11 bis 16 CPU-Sekunden auf dem Empfänger, Kernel-WireGuard bei rund 15,5. Auf schwacher Hardware kann das anders aussehen.

Ist Tailscale sicher?

Die Verschlüsselung ist WireGuard, Tailscale kann deinen Verkehr nicht mitlesen. Das Risiko liegt in der Verwaltung: Wer den Steuerserver, dein Admin-Konto oder einen Anmeldeschlüssel kontrolliert, kann Geräte in dein Netz aufnehmen. Tailnet Lock, enge ACLs und kurzlebige Schlüssel reduzieren das deutlich.

Kann Tailscale meinen Datenverkehr sehen?

Nein, den Inhalt nicht. Die privaten Schlüssel bleiben auf den Geräten. Tailscale sieht aber Metadaten: welche Geräte es gibt, wann sie online sind, unter welchen Adressen sie erreichbar sind. Über die Relays laufen außerdem verschlüsselte Pakete, wenn kein direkter Weg möglich ist.

Ist Tailscale kostenlos?

Für private, nicht-kommerzielle Nutzung ja: Der Personal-Plan kostet 0 $ für bis zu 6 Nutzer mit unbegrenzten Geräten (Stand 4. Oktober 2026). Geschäftliche Pläne kosten 8 $ oder 18 $ pro Nutzer und Monat.

Was ist Headscale?

Headscale ist ein quelloffener, selbst betreibbarer Ersatz für den Tailscale-Steuerserver. Man benutzt die normalen Tailscale-Clients, meldet sie aber mit --login-server am eigenen Headscale an. Kostenlos, aber man ist selbst für Betrieb, Updates und Verfügbarkeit zuständig.

Funktioniert Tailscale ohne Internetverbindung zum Steuerserver?

Bestehende Verbindungen laufen weiter, das haben wir getestet. Ein Gerät, das neu startet, während der Steuerserver nicht erreichbar ist, kommt aber nicht wieder ins Netz, weil es die Liste der Gegenstellen nicht laden kann.

Brauche ich eine Portfreigabe für Tailscale?

Nein, in den meisten Fällen nicht. Tailscale schafft es oft durch NAT hindurch und weicht sonst auf Relays aus. Eine Freigabe von UDP 41641 oder funktionierendes IPv6 hilft aber, eine schnelle direkte Verbindung zu bekommen.

Brauche ich eine Portfreigabe für WireGuard?

Ja, mindestens eine Seite muss per UDP erreichbar sein. Wenn beide Seiten hinter NAT ohne Freigabe sitzen, kommt mit reinem WireGuard keine Verbindung zustande.

Gibt es Alternativen zu Tailscale?

Ja, etwa NetBird, ZeroTier, Nebula oder Netmaker. NetBird und Netmaker bauen ebenfalls auf WireGuard auf und lassen sich selbst betreiben. ZeroTier und Nebula nutzen eigene Protokolle. Getestet haben wir sie für diesen Artikel nicht.

Fazit: Zwei Antworten auf zwei verschiedene Fragen

Tailscale vs WireGuard ist am Ende keine Frage der Geschwindigkeit. Auf unserer Strecke waren beide gleich schnell, und beim CPU-Verbrauch hat Tailscale sogar etwas besser abgeschnitten, als wir erwartet hatten. Der Unterschied liegt darin, wer die Liste der Teilnehmer führt.

Bei WireGuard führst du sie selbst, in Konfigurationsdateien. Das ist mühsam, sobald es mehr als eine Handvoll Geräte werden, aber es gibt nichts dazwischen, was ausfallen, kompromittiert werden oder Daten nach Hause schicken kann. Für Server-zu-Server-Verbindungen und feste Standorte ist das schwer zu schlagen.

Bei Tailscale führt sie ein Steuerserver. Das macht Netze mit vielen wechselnden Geräten überhaupt erst handhabbar, und Relays retten Verbindungen, die mit WireGuard allein nie zustande kämen. Dafür hängt dein Netz an einem weiteren Dienst, und du solltest wissen, was er standardmäßig tut (Relays, Logs) und was passiert, wenn er weg ist.

Headscale liegt dazwischen: Tailscales Komfort, deine Kontrolle, deine Arbeit.

Wenn du gerade einen ersten eigenen Server aufsetzt, fang mit den Grundlagen an: Linux-Server einrichten, SSH verstehen und eine saubere Firewall. Ein VPN ist die nächste Schicht, nicht die erste.