Nachteile von Tailscale: Was der Dienst nicht kann

Die Nachteile von Tailscale, kurz gefasst

Die Nachteile von Tailscale folgen alle aus einer Entscheidung: Schlüsselverteilung, NAT-Traversal, Adressvergabe und DNS laufen über einen Koordinationsserver, den Tailscale Inc. betreibt, und nicht über Sie. Ein Dritter verwaltet also Ihr Netz, der Login hängt an Google, Microsoft, GitHub oder Apple, und wenn kein direkter Pfad zwischen zwei Geräten zustande kommt, läuft der Verkehr verschlüsselt über ein Relay von Tailscale. Dazu kommen Grenzen im kostenlosen Tarif, ein Bedrohungsmodell, das nichts mit Anonymität zu tun hat, Akkufragen auf dem Telefon und ein paar Überraschungen im Heimnetz.

Diese Bewertung ist keine Abrechnung und keine Werbung. Sie zählt auf, was im Betrieb konkret stört, sagt bei jedem Punkt, warum es so ist, und nennt die Gegenmaßnahme, wo es eine gibt. Alle Verhaltensbeschreibungen stammen aus der Tailscale-Dokumentation, nicht aus eigenen Messungen. Wer erst wissen will, was Tailscale überhaupt ist, liest zuerst die Einführung in Tailscale und sein Mesh-Modell.

Der Koordinationsserver gehört Tailscale Inc. Was sieht er?

Jedes Gerät meldet sich beim Koordinationsserver an und hinterlegt dort seinen öffentlichen WireGuard-Schlüssel, seine aktuellen Endpunkte (öffentliche IP-Adresse und Port), seinen Gerätenamen, sein Betriebssystem und die Identität des Nutzers, dem es gehört. Der Server verteilt diese Informationen an die anderen Geräte des Netzes und schickt ihnen die Zugriffsregeln (ACLs) als Paketfilter mit. Ohne ihn lernt kein Gerät den Schlüssel eines anderen kennen.

Was der Server nicht sieht, steht in der Architekturbeschreibung von Tailscale deutlich: Der private Schlüssel verlässt das Gerät nie. Die Verschlüsselung zwischen zwei Geräten ist Ende-zu-Ende, nur die beiden Kommunikationspartner können Pakete einer WireGuard-Sitzung ent- oder verschlüsseln. Tailscale Inc. kann den Inhalt Ihres Datenverkehrs also nicht lesen, auch nicht über die eigenen Relay-Server, die laut Dokumentation bereits verschlüsselte Pakete blind weiterleiten.

Der Koordinationsserver kann aber etwas anderes: Er entscheidet, welche Geräte einander kennen. Ein kompromittierter oder böswilliger Koordinationsserver könnte ein fremdes Gerät mit einem fremden Schlüssel in Ihr Netz einschleusen, und Ihre Geräte würden ihm vertrauen, weil sie dem Server vertrauen. Der eigentliche Kritikpunkt ist also die Kontrolle über die Mitgliedschaft im Netz. Wie sich das zur Verschlüsselung verhält, erklärt die Sicherheitsbewertung von Tailscale ausführlich.

Dazu kommen die Client-Logs. Jeder Tailscale-Client streamt laut Dokumentation seine Betriebsprotokolle standardmäßig an log.tailscale.com, darunter Informationen über den eigenen Betrieb und über Verbindungsversuche zu anderen Geräten. Der Inhalt des Verkehrs ist nicht darin. Wer das nicht will, startet tailscaled mit dem Flag --no-logs-no-support oder setzt die Umgebungsvariable TS_NO_LOGS_NO_SUPPORT. Der Name sagt, was es kostet: Tailscale kann dann keinen technischen Support leisten.

Zwei Antworten auf das Problem existieren. Tailnet Lock lässt Ihre Geräte neue Knoten nur akzeptieren, wenn ein von Ihnen bestimmter Signierknoten sie unterschrieben hat. Die Dokumentation formuliert das Ziel so: Selbst wenn Tailscale böswillig wäre oder die Infrastruktur gehackt würde, könnten Angreifer keinen Verkehr in Ihrem Tailnet senden oder empfangen. Tailnet Lock ist laut Dokumentation für den Personal-Tarif und den Enterprise-Tarif verfügbar, erlaubt maximal 20 Signierknoten, und ein Android-Gerät kann nicht signieren. Zum Abschalten brauchen Sie eines der zehn Deaktivierungsgeheimnisse aus der Einrichtung; sind alle verloren, ist das Tailnet laut Dokumentation nicht wiederherstellbar. Was das im Alltag bedeutet, steht in der Erklärung zu Tailnet Lock.

Die zweite Antwort ist headscale, eine quelloffene, selbst gehostete Implementierung des Koordinationsservers. Das Projekt beschreibt seinen Zweck eng: ein einzelnes Tailnet, für private Nutzung oder eine kleine Organisation, und es ist nicht mit Tailscale Inc. verbunden. Sie nutzen die offiziellen Tailscale-Clients weiter, nur der Server steht auf Ihrem VPS. Dafür fehlen Ihnen die Funktionen, die headscale nicht nachbaut; Tailnet Lock steht zum Beispiel nicht auf seiner Funktionsliste, wobei die Bedrohung, gegen die Tailnet Lock schützt, bei einem eigenen Server ohnehin Sie selbst sind. Die Anleitung zu headscale auf einem VPS zeigt den Aufbau. Wer wissen will, welchem Recht Tailscale Inc. mit Sitz in Toronto unterliegt, findet die Antwort in der Frage, ob Tailscale ein kanadisches Unternehmen ist.

Was der kostenlose Tarif erlaubt, Stand 20. September 2026

Die folgenden Zahlen stammen von tailscale.com/pricing am 20. September 2026. Tailscale ändert die Tarife gelegentlich; frühere Tarife wie Personal Plus oder Starter laufen laut Preisseite als Legacy-Konten weiter, sind aber nicht mehr buchbar.

Der Tarif Personal kostet nichts und erlaubt bis zu 6 Nutzer mit unbegrenzt vielen Geräten pro Nutzer. Enthalten sind 50 getaggte Ressourcen, also Geräte, die einem Tag statt einer Nutzeridentität gehören, was typisch für Server ist. Erlaubt sind bis zu 3 ACL-Gruppen und 1.000 Minuten ephemerer Ressourcen pro Monat. Subnet-Router, Exit-Nodes, MagicDNS und Tailscale SSH sind enthalten.

Der Tarif Standard kostet 8 US-Dollar pro Nutzer und Monat und hebt die Nutzergrenze auf; Premium kostet 18 US-Dollar pro Nutzer und Monat und bringt unter anderem bis zu 300 ACL-Gruppen. Netzwerk-Flow-Logs, also die Aufzeichnung, welches Gerät wann mit welchem gesprochen hat, gibt es nur in Premium und Enterprise.

Wo das im Alltag beißt: Ein "Nutzer" ist eine Login-Identität. Eine WG mit sieben Personen, die alle eigene Konten wollen, passt nicht mehr in den Personal-Tarif. Server zählen als getaggte Ressourcen, und wer viele Container oder VMs einzeln ins Tailnet hängt, erreicht die 50 schneller als gedacht. Und 3 ACL-Gruppen reichen für "Familie" und "Server", aber nicht für eine saubere Trennung nach Rollen. Die Grenzen des kostenlosen Tailscale-Tarifs geht jeden Wert einzeln durch, und die Erklärung der Tailscale-Preise rechnet vor, was ein Haushalt oder ein kleines Team tatsächlich zahlt.

Wenn kein direkter Pfad zustande kommt: das DERP-Relay

Tailscale versucht, zwei Geräte direkt miteinander zu verbinden, auch wenn beide hinter NAT (Network Address Translation, die Adressumsetzung Ihres Routers) sitzen. Gelingt das nicht, geht der Verkehr über einen DERP-Server (Designated Encrypted Relay for Packets) von Tailscale. Die Dokumentation nennt zwei Hauptursachen: blockierte UDP-Pakete und hartes NAT, bei dem jede ausgehende Verbindung einen eigenen externen Port bekommt, sodass die Gegenseite den Rückweg nicht erraten kann.

Das Relay ist verschlüsselt und funktional, aber die Dokumentation sagt selbst, dass Relay-Verbindungen im Allgemeinen langsamer sind als direkte und einen niedrigeren maximalen Durchsatz bieten können. Der Pfad führt über einen Server, der oft in einer anderen Stadt steht, und jedes Paket macht den Umweg mit.

Ob Sie betroffen sind, zeigt tailscale status. Steht in der Zeile eines Geräts direct mit IP-Adresse und Port, ist die Verbindung direkt. Steht dort relay "fra", läuft sie über den DERP-Server in Frankfurt. tailscale ping <gerätename> zeigt dasselbe Bild: Die ersten Antworten kommen via DERP(fra), dann sollte die Ausgabe auf via <ip>:<port> wechseln. Bleibt sie bei DERP, wird kein direkter Pfad gefunden. Warum das passiert und was Sie dagegen tun können, steht in der Analyse langsamer Tailscale-Verbindungen über DERP; das muss hier nicht wiederholt werden.

Eigene DERP-Server sind möglich. Die Dokumentation stuft das aber als fortgeschrittene Operation ein, die erhebliche Ressourcen erfordert, und Sie übernehmen damit Bau, Betrieb, Absicherung und Aktualisierung des derper-Binaries selbst.

Ein Hinweis für deutsche Anschlüsse: Hinter einem DS-Lite-Anschluss, wie ihn viele Kabelanbieter schalten, hat Ihre Fritzbox keine eigene öffentliche IPv4-Adresse. Die IPv4-Adressumsetzung passiert beim Provider, und dessen NAT bestimmt, ob ein direkter Pfad zustande kommt. Das ist die häufigste Ursache, warum ein Heimserver in Deutschland dauerhaft im Relay landet. Die Details stehen im verlinkten Beitrag zu Relay-Verbindungen, und wer Tailscale gerade deshalb einsetzt, um kein Port-Forwarding mehr einrichten zu müssen, liest Tailscale als Ersatz für Portweiterleitungen.

Ohne Identity Provider gibt es keinen Login

Tailscale hat keine eigenen Benutzerkonten. Die Dokumentation sagt ausdrücklich, dass eine Registrierung mit E-Mail-Adresse und Passwort nicht unterstützt wird, weil Tailscale absichtlich kein Identity Provider (IdP, ein Dienst, der Identität und Anmeldung verwaltet) sein will. Anmelden können Sie sich mit Apple, Google, GitHub, Microsoft, Okta oder OneLogin, mit einem eigenen OpenID-Connect-Anbieter oder per Passkey.

Die Folge ist eine Abhängigkeit, die vielen erst auffällt, wenn es zu spät ist. Verlieren Sie den Zugang zu Ihrem Google-Konto, verlieren Sie den Zugang zur Verwaltung Ihres Tailnets. Sperrt der Anbieter Ihr Konto, gilt dasselbe. Bestehende Geräte laufen weiter, bis ihr Node-Key abläuft; die Dokumentation nennt 180 Tage als Standard, und danach muss sich das Gerät neu anmelden. Ein Tailnet, dessen einziger Admin über ein Gmail-Konto angemeldet ist, hat also genau einen Ausfallpunkt, und der steht bei Google.

Die Gegenmaßnahmen: Legen Sie einen zweiten Admin mit einer anderen Identität an. Oder betreiben Sie headscale, dann entscheiden Sie selbst, ob Sie einen eigenen OIDC-Anbieter anbinden oder Geräte mit vorab erzeugten Auth-Keys registrieren.

Tailscale ist kein Anonymitäts-VPN

Das Wort VPN weckt in Deutschland eine bestimmte Erwartung: verstecke meine IP-Adresse vor Websites, umgehe Geosperren, tarne meinen Standort, halte den Provider aus meinem Verkehr heraus. Tailscale erfüllt davon fast nichts, und es behauptet auch nicht das Gegenteil.

Das Bedrohungsmodell von Tailscale ist ein anderes. Es verschlüsselt den Verkehr zwischen Ihren eigenen Geräten und stellt sicher, dass nur Geräte mit bekanntem Schlüssel und passender ACL-Regel miteinander reden. Dagegen schützt es: Mitlesen im Café-WLAN, offene Ports auf dem Heimserver, SSH auf den VPS über die öffentliche IP, und Dienste, die nur für Sie selbst gedacht sind und trotzdem im Internet stehen.

Dagegen schützt es nicht: Websites sehen Ihre normale IP-Adresse, denn Tailscale leitet Ihren Internetverkehr standardmäßig gar nicht um. Erst wenn Sie einen Exit-Node einrichten, geht der gesamte Verkehr über dieses Gerät, und die Website sieht dann dessen IP-Adresse, also die Ihres VPS oder Ihres Heimanschlusses. Diese Adresse ist auf Sie registriert. Dazu kommt, was die Dokumentation zum Mullvad-Zusatz sagt: Tailscale ist identitätsbewusst, anonyme Tailnets werden nicht unterstützt, und jeder Nutzer ist mit einer E-Mail-Adresse oder einem GitHub-Konto verknüpft. Beim Mullvad-Zusatz weiß Tailscale, welches Mullvad-Konto zu welchem Tailscale-Nutzer gehört; Mullvad erhält keine Identitätsdaten von Tailscale, und Tailscale kann den Verkehr zu Mullvad-Servern nicht lesen.

Wer einen eigenen Exit-Node aufsetzt, um unterwegs über den heimischen oder den VPS-Anschluss zu surfen, macht das aus guten Gründen, aber Anonymität gehört nicht dazu. Ein Tailscale-Exit-Node auf dem VPS erklärt, was Sie damit bekommen. Wer wirklich nicht identifizierbar sein will, braucht ein anderes Werkzeug, und der Vergleich von Tor und VPN sortiert, welches. Ob Tailscale überhaupt ein VPN im üblichen Sinn ist, klärt die Antwort auf genau diese Frage.

Akku und Always-on auf dem Smartphone

Auf iOS läuft Tailscale als Network Extension, also als System-VPN, das im Hintergrund den Verkehr aller Apps sichern kann. Das ist praktisch, hat aber zwei dokumentierte Nebenwirkungen.

Erstens der Akku. Die Troubleshooting-Seite von Tailscale nennt als häufigste Ursache für hohen Verbrauch ein Gerät, das einen Exit-Node für den gesamten Verkehr nutzt. Dann läuft jedes Paket des Telefons durch den Tunnel, und der Prozess kann nie ruhen. Ein Telefon, das nur gelegentlich den Heimserver erreichen soll, braucht keinen Exit-Node.

Zweitens die Always-on-Logik. iOS und Android erlauben jeweils nur ein aktives System-VPN. Ist Tailscale verbunden, kann die Firmen-VPN-App nicht gleichzeitig laufen, und umgekehrt. Auf iOS und macOS kommt VPN On Demand dazu, das den Tunnel nach Regeln automatisch startet oder stoppt; laut Dokumentation kann nur eine VPN-App gleichzeitig On Demand aktiviert haben. Eine falsch gesetzte Regel erzeugt ein Verhalten, das wie ein Fehler aussieht: Ist On Demand auf "Never" konfiguriert, trennt das System Tailscale, und beim manuellen Neuverbinden trennt es sofort wieder. Wer das nicht kennt, sucht den Fehler an der falschen Stelle.

MagicDNS und Split-DNS im Heimnetz

MagicDNS registriert für jedes Gerät im Tailnet automatisch einen DNS-Namen, sodass ssh nas statt ssh 100.101.102.103 funktioniert. Dafür schiebt sich Tailscale in die DNS-Auflösung des Geräts und beantwortet Anfragen unter der Adresse 100.100.100.100. Für Tailnet-Namen ist das unsichtbar. Für alles andere entscheidet eine Einstellung, die in der Admin-Konsole leicht zu übersehen ist.

Die Option "Override DNS servers" (Override local DNS) tut laut Dokumentation Folgendes: Geräte im Tailnet ignorieren ihre lokalen DNS-Einstellungen und verwenden immer die globalen Nameserver des Tailnets. Tragen Sie dort einen öffentlichen Resolver wie 1.1.1.1 ein, dann fragt Ihr Laptop im Heimnetz nicht mehr die Fritzbox nach Namen. Die Folge: fritz.box, der Name des Druckers oder das NAS, dessen Namen nur der Router kennt, sind plötzlich nicht mehr auflösbar, obwohl sich am Heimnetz nichts geändert hat. Der öffentliche Resolver kennt diese Namen nicht, und die Fritzbox wird nicht mehr gefragt.

Die dokumentierte Lösung heißt Split-DNS, in der Tailscale-Oberfläche "restricted nameservers". Sie weisen einem Nameserver eine Domain zu, etwa 192.168.178.1 für fritz.box, und nur Anfragen zu dieser Domain gehen an diesen Server. Alles andere folgt weiter den globalen Einstellungen oder, ohne Override, den lokalen. Der Haken: Die Fritzbox ist aus dem Tailnet nur erreichbar, wenn ein Subnet-Router im Heimnetz die Route dorthin anbietet; sonst schlägt die Anfrage von unterwegs fehl, weil 192.168.178.1 von außen nicht erreichbar ist. Wie so ein Router auf einem Server läuft, zeigt die Anleitung zum Tailscale-Subnet-Router.

Unter Linux gibt es eine weitere Überraschung. Findet Tailscale keinen DNS-Manager wie systemd-resolved, überschreibt es laut Dokumentation /etc/resolv.conf direkt, sobald MagicDNS aktiv ist. Auf einem Server, der seine Resolver-Konfiguration von Hand pflegt, ist die Datei danach eine andere. tailscale set --accept-dns=false schaltet das für dieses eine Gerät ab. Die Dokumentation ergänzt, dass der MagicDNS-Server trotzdem weiter unter 100.100.100.100 antwortet, solange MagicDNS im Tailnet aktiviert ist; nur das Gerät fragt ihn nicht mehr automatisch.

Wer Tailscale nicht einsetzen sollte, und was stattdessen

Sie wollen im Internet nicht identifizierbar sein. Tailscale ist an eine Identität gebunden und leitet Ihren Verkehr über Adressen, die auf Sie registriert sind. Nehmen Sie Tor oder einen kommerziellen Anbieter mit Bezahlung ohne Konto, und lesen Sie vorher den verlinkten Vergleich.

Kein Dritter darf Ihre Topologie sehen, aus Compliance-Gründen oder aus Prinzip. Dann bleiben zwei Wege. Bei einer Handvoll Geräte mit festen Adressen reicht reines WireGuard, und die Anleitung zum eigenen WireGuard-VPN auf dem VPS braucht dafür etwa vierzig Zeilen Konfiguration. Bei vielen Geräten hinter wechselnden NATs behalten Sie die Tailscale-Clients und ersetzen den Server durch headscale. Was Sie mit dem Wechsel von Tailscale zu WireGuard gewinnen und verlieren, steht in dem direkten Vergleich von WireGuard und Tailscale.

Sie verbinden genau zwei Server. Ein Koordinationsserver, ein Login, eine Client-Software pro Seite und ein Konto bei einem Identity Provider sind dafür zu viel Apparat. Zwei VPS über ein privates Netz zu verbinden geht mit WireGuard direkt.

Sie haben mehr als sechs Personen und kein Budget. Der Personal-Tarif endet bei sechs Nutzern, und ab dem siebten zahlen Sie pro Kopf. Ein selbst gehosteter Koordinationsserver kennt diese Grenze nicht, headscale ebenso wenig wie ein eigener NetBird-Server, der denselben WireGuard-Unterbau mit einer anderen Steuerebene versieht.

Sie sitzen hinter DS-Lite und brauchen vollen Durchsatz zum Heimserver. Solange kein direkter Pfad zustande kommt, teilt sich Ihr Verkehr das Relay. Prüfen Sie erst, ob IPv6 auf beiden Seiten einen direkten Pfad ermöglicht; wenn nicht, ist ein VPS mit öffentlicher IPv4 als WireGuard-Endpunkt die verlässlichere Lösung.

Für alle anderen, also für den typischen Fall "Laptop, Telefon, Heimserver, ein VPS, eine Person oder eine Familie", bleibt Tailscale eine gute Wahl, deren Nachteile Sie jetzt kennen. Die Übersicht der Tailscale-Alternativen hilft, wenn einer dieser Punkte für Sie der entscheidende ist.

FAQ

Kann Tailscale Inc. meinen Datenverkehr mitlesen?

Nein. Laut Architekturbeschreibung verlässt der private WireGuard-Schlüssel das Gerät nie, und nur die beiden beteiligten Geräte können Pakete einer Sitzung entschlüsseln. Auch die DERP-Relay-Server leiten bereits verschlüsselte Pakete nur weiter. Der Koordinationsserver sieht aber Metadaten: öffentliche Schlüssel, Endpunkt-Adressen, Gerätenamen, Betriebssysteme und Nutzeridentitäten, und er entscheidet, welche Geräte einander kennen. Gegen einen kompromittierten Koordinationsserver hilft Tailnet Lock, gegen die Abhängigkeit insgesamt headscale.

Was passiert, wenn mein Google-Konto gesperrt wird?

Tailscale hat keine eigenen Passwörter; die Anmeldung läuft immer über einen Identity Provider wie Google, Microsoft, GitHub oder Apple, über einen eigenen OIDC-Anbieter oder per Passkey. Ohne Zugang zu diesem Konto kommen Sie nicht mehr in die Admin-Konsole. Bereits angemeldete Geräte funktionieren weiter, bis ihr Node-Key abläuft, standardmäßig nach 180 Tagen. Legen Sie deshalb einen zweiten Admin mit einer anderen Identität an, oder betreiben Sie den Koordinationsserver mit headscale selbst.

Warum ist meine Tailscale-Verbindung langsam, obwohl beide Anschlüsse schnell sind?

Prüfen Sie mit tailscale status, ob in der Zeile des Zielgeräts direct oder relay steht. Bei relay läuft der Verkehr über einen DERP-Server, weil kein direkter Pfad gefunden wurde, meist wegen hartem NAT oder blockiertem UDP. Die Dokumentation beschreibt Relay-Verbindungen als im Allgemeinen langsamer und mit niedrigerem maximalen Durchsatz. Hinter DS-Lite-Anschlüssen ist das in Deutschland häufig. Der verlinkte Beitrag zu direkten und Relay-Verbindungen erklärt die Ursachen im Detail.

Versteckt Tailscale meine IP-Adresse vor Websites?

Nein. Ohne Exit-Node verlässt Ihr Internetverkehr das Gerät wie bisher über Ihren normalen Anschluss. Mit einem Exit-Node sehen Websites die Adresse dieses Geräts, also Ihres VPS oder Ihres Heimanschlusses, und beide sind auf Sie registriert. Tailscale unterstützt laut Dokumentation keine anonymen Tailnets; jeder Nutzer ist mit einer E-Mail-Adresse oder einem GitHub-Konto verknüpft. Für Anonymität sind Tor oder ein kommerzieller VPN-Anbieter ohne Kontobindung die passenden Werkzeuge.

Kann ich Tailscale ganz ohne Tailscale Inc. betreiben?

Ja, mit headscale. Das ist eine quelloffene, selbst gehostete Implementierung des Koordinationsservers für ein einzelnes Tailnet, gedacht für private Nutzung oder eine kleine Organisation, und nicht mit Tailscale Inc. verbunden. Die offiziellen Clients bleiben. Sie verzichten auf die Funktionen, die headscale nicht nachbaut, und Sie übernehmen Betrieb und Updates des Servers. Die DERP-Relays von Tailscale können Sie weiter nutzen oder durch den in headscale eingebauten DERP-Server ersetzen.