Die Kurzfassung: Ein normales VPN leitet 100 % des Gerätedatenverkehrs durch den verschlüsselten Tunnel. Split-Tunneling bricht diese Regel bewusst. Du legst fest, welche Apps oder Ziele den Tunnel umgehen und direkt über deine normale Verbindung kommunizieren. Das klingt einfach – und im Prinzip ist es das auch –, aber die praktische Umsetzung unterscheidet sich je nach Betriebssystem erheblich, und die Datenschutz-Kompromisse sind leicht zu übersehen. Eine Streaming-App, die außerhalb des Tunnels läuft, sieht weiterhin deine echte IP. Eine Banking-App außerhalb des Tunnels kommuniziert weiterhin mit deiner Bank über dein Heimnetz – was in Ordnung ist, bis dieselbe App eine DNS-Anfrage stellt, die über den Bypass-Pfad durchsickert und eine andere Domain offenbart, die du eigentlich nicht preisgeben wolltest.
Was VPN-Tunneling wirklich macht (die Ausgangslage)
Bevor du verstehen kannst, was aufgeteilt wird, musst du dir klarmachen, was der vollständige Tunnel leistet. Ein auf deinem Gerät laufender VPN-Client erstellt eine virtuelle Netzwerkschnittstelle – unter Linux heißt sie typischerweise tun0 oder wg0, unter macOS utun, unter iOS und Android verwaltet das Betriebssystem sie über eine App-spezifische Erweiterungs-API. Die Routing-Tabelle des Betriebssystems wird dann so angepasst, dass die Standardroute – die Regel, die besagt: „Pakete ohne andere passende Route über dieses Gateway senden“ – auf diese virtuelle Schnittstelle zeigt statt auf deine physische WLAN- oder Mobilfunkschnittstelle.
Von da an wird jedes Paket, das dein Gerät erzeugt, vom VPN-Client verschlüsselt, in einen neuen IP-Header verpackt, der auf den VPN-Server zeigt, und über die physische Schnittstelle als ein einheitlicher Datenstrom gesendet. Der VPN-Server entschlüsselt das Paket, leitet es an sein eigentliches Ziel im öffentlichen Internet weiter, empfängt die Antwort, verschlüsselt sie erneut und schickt sie zurück. Dein Internetanbieter sieht nur den verschlüsselten Datenstrom zu einer einzigen IP. Ziel-Websites sehen die IP des VPN-Servers, nicht deine.
Das ist der Standard. Split-Tunneling greift in dieses Modell ein, indem es spezifischere Routen zur Routing-Tabelle hinzufügt – Regeln, die besagen: „Für Datenverkehr zu diesem Ziel“ oder „Für Datenverkehr dieser App: ignoriere die Standard-Tunnelroute und nutze direkt die physische Schnittstelle.“
Was Split-Tunneling verändert
Konzeptionell führt Split-Tunneling eine Weiche in deinen Netzwerkfluss ein. Einige Pakete gehen durch den verschlüsselten Tunnel, andere direkt über die physische Schnittstelle. Die Entscheidung trifft der VPN-Client anhand der von dir konfigurierten Regeln. Es gibt drei gängige Kategorien von Split-Regeln:
- App-basiert – „Sende den gesamten Netflix-Datenverkehr außerhalb des Tunnels; alles andere durch den Tunnel.“ Umgesetzt, indem Pakete mit der UID oder PID des erzeugenden Prozesses markiert werden und Routing-Entscheidungen pro Tag getroffen werden.
- Zielbasiert – „Sende Datenverkehr zu
10.0.0.0/8außerhalb des Tunnels, damit ich mein Heim-NAS erreichen kann; alles andere durch den Tunnel.“ Rein über Routing-Tabelleneinträge umgesetzt – die einfachste Form. - URL- oder domainbasiert – „Sende Datenverkehr zu
*.bank.comaußerhalb des Tunnels.“ Das ist fehleranfällig, weil die OS-Routing-Schicht Domains nicht nativ kennt. Es erfordert, dass der VPN-Client entweder DNS abfängt und Antworten umschreibt oder eine dynamische IP-Zulassungsliste pflegt, die DNS-Auflösungen nachverfolgt. Anbieter setzen das unterschiedlich um.
Hier das architektonische Bild, vereinfacht:
Vollständiger Tunnel (kein Split):
[App A] -> [App B] -> [App C]
\ | /
[Virtuelle VPN-Schnittstelle]
|
[Verschlüsselter Tunnel]
|
[VPN-Server] -> Internet
Split-Tunnel (App-basiert, App C ausgeschlossen):
[App A] -> [App B] [App C]
\ / \
[Virtuelle VPN-Schnittstelle] [Physisches WLAN]
| |
[Verschlüsselter Tunnel] [Unverschlüsseltes Internet]
| |
[VPN-Server] direkt zum Ziel
Die „Aufspaltung“ ist der Verzweigungspunkt innerhalb deines Betriebssystems – die Wahl zwischen virtueller und physischer Schnittstelle wird getroffen, bevor die Verschlüsselung stattfindet. Ein Paket, das den Tunnel umgeht, wurde also von vornherein nie verschlüsselt. Es gibt keinen Entschlüsselungsschritt; das Paket verlässt dein Gerät unverändert.
Inverses Split-Tunneling – Zulassungsliste vs. Sperrliste
Split-Tunneling-Konfigurationen gibt es in zwei Varianten, die symmetrisch wirken, aber sehr unterschiedliches Verhalten im Fehlerfall zeigen:
- Sperrlisten-Modus (der häufige Standard) – „Alles tunneln, außer den Apps/Zielen auf dieser Liste.“ Der Standard ist geschützt; nur bestimmte Ausnahmen sickern durch. Vergisst du, eine App zur Liste hinzuzufügen, bleibt sie geschützt.
- Zulassungslisten-Modus (auch inverses Split-Tunneling genannt) – „Nur die Apps/Ziele auf dieser Liste tunneln; alles andere geht direkt.“ Der Standard ist ungeschützt; nur bestimmte Apps werden getunnelt. Vergisst du, eine App zur Liste hinzuzufügen, gibt sie Daten preis.
Der Zulassungslisten-Modus ist die richtige Wahl für „Ich möchte, dass nur mein Browser das VPN nutzt; alles andere kann meine normale Verbindung verwenden.“ Der Sperrlisten-Modus ist die richtige Wahl für „Ich möchte die meisten Verbindungen schützen, aber ein paar bestimmte Apps brauchen das echte Netzwerk.“ Die meisten Endverbraucher möchten den Sperrlisten-Modus. Betriebs- und DevOps-Teams bevorzugen manchmal den Zulassungslisten-Modus, weil sie bestimmte Dienste durch den Tunnel zugänglich machen wollen, ohne das restliche System zu beeinträchtigen.
Das Fehlerszenario beim Zulassungslisten-Modus ist schwerwiegend: Fügst du eine neue App hinzu und vergisst, sie zur Zulassungsliste hinzuzufügen, sickert der Datenverkehr dieser App durch. Das Fehlerszenario beim Sperrlisten-Modus ist milder: Vergessene Apps bleiben geschützt – es gibt lediglich lästige Kompatibilitätsprobleme, wenn eine Streaming- oder Banking-App fehlschlägt, weil sie die VPN-IP sieht.
Wann du Split-Tunneling nutzen solltest – fünf konkrete Szenarien
Split-Tunneling hat echte legitime Einsatzmöglichkeiten. Das sind die Situationen, in denen es das richtige Werkzeug ist:
1. Streaming-Dienste, die VPN-Endpunkte erkennen und blockieren
Netflix, Disney+, Hulu und die meisten regionalen Sender pflegen umfangreiche Zulassungslisten bekannter VPN-Rechenzentrum-IPs und verweigern das Streaming, sobald sie eine davon erkennen. Du kannst entweder das VPN abschalten (und damit jeden Schutz verlieren) oder die Streaming-App per Split-Tunnel ausschließen, damit sie deine echte IP sieht, während alles andere geschützt bleibt.
2. Banking- und Finanz-Apps mit standortbasierter Betrugserkennung
Banken werten einen plötzlichen IP-Wechsel zu einem VPN-Rechenzentrum häufig als Betrugs-Signal – sie lösen eine zusätzliche Authentifizierung aus, halten Transaktionen zurück oder sperren kurzzeitig das Konto. Wird die Banking-App aus dem Tunnel herausgenommen, bleibt deine echte-IP-Beziehung zur Bank konsistent. Das ist ein Komfort-Fix, kein Sicherheits-Upgrade – die Verbindung zur Bank ist bereits TLS-verschlüsselt, sodass das VPN dieser spezifischen Sitzung ohnehin kaum zusätzliche Sicherheit bietet.
3. Lokale Netzwerkressourcen (NAS, Drucker, Smart Home)
Wenn das VPN den gesamten Datenverkehr abfängt, kann dein Gerät den Drucker unter 192.168.1.50 nicht mehr erreichen, weil diese IP über den VPN-Tunnel nicht erreichbar ist. Zielbasiertes Split-Tunneling (Ausschluss von 192.168.0.0/16 und 10.0.0.0/8) stellt den lokalen Zugriff wieder her, ohne das VPN für das öffentliche Internet zu deaktivieren. Viele VPN-Clients tun dies standardmäßig automatisch; manche nicht.
4. Latenzempfindliche Anwendungen
Kompetitives Online-Gaming, Live-Videokonferenzen und Sprachtelefonie leiden, wenn durch die Weiterleitung über einen weit entfernten VPN-Server zusätzliche Latenz entsteht. Das Ausschließen dieser bestimmten Apps kann die Latenz verbessern, während alles andere verschlüsselt bleibt. Der Kompromiss: Diese Apps sind nun für deinen Internetanbieter erkennbar und für Netzwerk-Beobachter sichtbar.
5. Firmen-VPN neben privatem VPN
Wenn dein Arbeitgeber ein Unternehmens-VPN für den Zugriff auf interne Ressourcen vorschreibt und du deinen privaten Datenverkehr über ein anderes (datenschutzorientiertes) VPN leiten möchtest, lässt Split-Tunneling am Unternehmens-VPN – mit Weiterleitung nur der Unternehmens-IP-Bereiche – den restlichen Datenverkehr für das private VPN frei. Das ist ein Power-User-Setup, aber ein sauberer Weg, um Arbeits- und Privatdatenverkehr zu trennen.
Wann du Split-Tunneling NICHT nutzen solltest – die Datenschutz-Fallstricke
Split-Tunneling macht dein Netzwerkverhalten komplexer, und komplexes Netzwerkverhalten gibt Daten auf nicht offensichtliche Weise preis. Die häufigsten Fehlszenarien:
DNS-Lecks über den Bypass-Pfad
Auch wenn der TCP-Datenverkehr einer App außerhalb des Tunnels geleitet wird, können ihre DNS-Anfragen weiterhin so konfiguriert sein, dass sie den DNS-Resolver des VPNs verwenden – oder schlimmer noch, auf den DNS-Resolver des Internetanbieters zurückfallen, wenn der VPN-Client das System-DNS nicht sorgfältig verwaltet. Das Ergebnis: Eine App, die für deinen Internetanbieter unsichtbar sein sollte, wird teilweise sichtbar. Der Internetanbieter sieht die DNS-Anfrage für banking.example.com, auch wenn die anschließende TCP-Verbindung einen anderen Weg genommen hat. Wir haben einen ausführlicheren Artikel darüber, wie DNS-Verschlüsselung in unseren DNS-over-HTTPS-Leitfaden passt.
App-vs-Domain-Verwechslung
App-basiertes Split-Tunneling routet nach Prozessidentität, aber moderne Apps stellen Verbindungen zu vielen Domains her. Deine „Streaming-App“ lädt wahrscheinlich Werbung, Telemetrie, Empfehlungs-APIs und Analyse-Endpunkte von Dutzenden verschiedener Domains – von denen einige mit Apps geteilt werden, die du tunneln möchtest. Wenn du die gesamte App ausschließt, schließt du all diese Verbindungen aus. Domainbasiertes Split-Tunneling hat das entgegengesetzte Problem: Eine einzelne App könnte dieselbe CDN-Domain sowohl für das Streaming-Video (das du ungeschützt haben möchtest) als auch für Inhalte laden, die du lieber nicht preisgeben würdest.
IPv6-Lecks
Viele Split-Tunnel-Implementierungen wurden entwickelt, als IPv4 die einzige Routing-Sorge war. Wenn dein Netzwerk IPv6-Konnektivität hat und die Split-Tunnel-Regeln keine expliziten IPv6-Routen enthalten, können Pakete, die durch den Tunnel geleitet werden sollten, über IPv6 außerhalb des Tunnels austreten. Das ist eines der häufigsten VPN-Lecks im Jahr 2026 und wird fast immer durch eine unvollständige Konfiguration der Split-Tunnel-Regeln verursacht. Teste darauf mit einem IPv6-Lecktest nach dem Aktivieren von Split-Tunneling.
Interaktionen mit dem Kill-Switch
Ein Kill-Switch ist dazu gedacht, den gesamten Datenverkehr zu blockieren, wenn das VPN abbricht, damit nichts ungeschützt durchsickert. Mit aktiviertem Split-Tunneling wird die Kill-Switch-Logik schwieriger – der Kill-Switch sollte Split-Tunneling-Apps weiterhin die Kommunikation erlauben, aber nur diesen, und nur wenn das VPN selbst ebenfalls ausgefallen ist. Viele VPN-Clients haben Fehler, bei denen der Kill-Switch entweder getunnelte Apps beim VPN-Ausfall nicht blockiert oder fälschlicherweise Split-Tunneling-Apps blockiert, die weiterlaufen sollten. Teste die Kombination explizit.
Vergleich der Split-Tunneling-Modi
| Modus | Was wird verschlüsselt | Was wird preisgegeben | Geeignet für |
|---|---|---|---|
| Vollständiger Tunnel (kein Split) | Gesamter Datenverkehr, alle Apps, alle Ziele | Nichts auf Anwendungsseite; dem Internetanbieter ist sichtbar, dass du ein VPN nutzt | Feindliche Netzwerke, Reisen, alle, deren Bedrohungsmodell den Internetanbieter einschließt |
| App-basierte Sperrliste | Alle Apps außer den explizit ausgeschlossenen | Ausgeschlossene Apps sehen die echte IP; ihr DNS kann je nach Implementierung durchsickern oder nicht | Streaming, Banking, regionsbeschränkte Apps, die VPNs erkennen |
| App-basierte Zulassungsliste (invers) | Nur Apps auf der Liste | Alles andere – einschließlich OS-Hintergrunddienste, Updates, Telemetrie | Gezielte Anwendungsfälle: „nur meinen Browser tunneln“, Entwickler-Setups |
| Zielbasiert (LAN-Ausschluss) | Alles zum öffentlichen Internet | Lokaler Netzwerkdatenverkehr (Drucker, NAS, Smart Home) | Fast immer wünschenswert; viele Clients aktivieren dies standardmäßig |
| Domainbasiert (URL-Regeln) | Hängt von der DNS-Abfang-Logik ab | Variabel; gemeinsame CDNs und dynamisches DNS machen dies fehleranfällig | Bestimmte zugelassene Websites; für Endverbraucher selten die Komplexität wert |
Wie Split-Tunneling auf jedem Betriebssystem funktioniert
iOS – eingeschränkt und indirekt
iOS stellt Drittanbieter-VPN-Apps keine echte Split-Tunneling-API zur Verfügung. Das NetworkExtension-Framework erlaubt die Konfiguration eines VPNs entweder systemweit (gesamter Datenverkehr) oder per App (nur Apps, die explizit von einem MDM-Profil registriert wurden). Echtes App-basiertes Split-Routing erfordert Apples NEAppProxyProvider mit einem per MDM verteilten Konfigurationsprofil – also ein Managed-Device-Szenario. Consumer-VPN-Apps auf iOS, die „Split-Tunneling“ bewerben, implementieren typischerweise zielbasierte Ausschlüsse (z. B. bestimmte IP-Bereiche aus dem Tunnel ausschließen) oder nutzen die On-Demand-Rules-API, um das VPN basierend auf WLAN-SSID oder Domain-Treffer bedingt zu aktivieren. App-basiertes Split-Tunneling für iOS-Endverbraucher ist faktisch nicht verfügbar.
Android – erstklassige Unterstützung
Die VpnService-API von Android unterstützt nativ App-spezifisches Routing. Der VPN-Client kann addAllowedApplication() oder addDisallowedApplication() aufrufen, um festzulegen, welche Apps durch den Tunnel gehen. Das OS übernimmt das App-spezifische Routing transparent – der VPN-Client muss kein Paket-Level-Tagging vornehmen. Android unterstützt außerdem die systemweite Einstellung „Immer aktives VPN“ mit einer Option „Verbindungen ohne VPN blockieren“, die Kill-Switch-Verhalten mit der App-spezifischen Konfiguration kombiniert: Getunnelte Apps laufen durch, nicht getunnelte gehen direkt, und wenn das VPN abbricht, werden die getunnelten Apps blockiert.
macOS – Implementierung variiert
macOS unterstützt Split-Tunneling über mehrere Mechanismen: das NetworkExtension-Framework (ähnlich wie iOS, aber mit mehr Flexibilität), Paketfilter über pf-Regeln oder Routing-Tabellen-Manipulation durch VPN-Clients mit erhöhten Rechten. App-basiertes Split-Tunneling auf macOS ist machbar, erfordert aber, dass der VPN-Client den Kernel nach Socket-zu-Prozess-Zuordnungen abfragt. Zielbasiertes Splitting ist unkompliziert und zuverlässig.
Windows – die häufigste Plattform für Split-Tunneling
Windows-VPN-Clients nutzen Split-Tunneling seit über einem Jahrzehnt. Die Windows Filtering Platform (WFP) stellt die kernel-seitige Paketinspektion und Routing-Entscheidungs-API bereit, in die VPN-Clients einhaken. App-basiertes Split-Tunneling auf Windows ist gut unterstützt und weit verbreitet. Die meisten Enterprise-VPN-Deployments nutzen Windows-Split-Tunneling, um sicherzustellen, dass Unternehmens-Datenverkehr durch den Unternehmens-Tunnel läuft, während allgemeiner Internet-Datenverkehr direkt geht – teils aus Performance-Gründen, teils um die Last auf den Unternehmens-VPN-Konzentratoren zu reduzieren.
Häufige Fehler bei der Konfiguration von Split-Tunneling
Wer beobachtet, wie Menschen Split-Tunneling tatsächlich falsch konfigurieren, stößt auf einige wiederkehrende Muster. Wenn du es einrichtest, prüfe dich anhand dieser Liste:
- Kein DNS-Lecktest nach dem Aktivieren. Führe nach jeder Konfigurationsänderung einen Lecktest durch (dnsleaktest.com oder ähnlich). Wenn du den DNS-Resolver deines Internetanbieters für eine App siehst, die getunnelt werden sollte, sickert der Bypass-Pfad DNS durch.
- Vergessen, dass Browser besonders sind. Ein Browser, der eine Streaming-Web-App ausführt, leitet sowohl das Streaming-Video als auch deine anderen Tabs über denselben Prozess. Den Browser auszuschließen schließt dein gesamtes Surfen aus. Nutze für den Streaming-Fall ein separates Browser-Profil oder eine andere App.
- IPv6 nicht berücksichtigen. Deaktiviere IPv6 vollständig, wenn dein VPN-Client es nicht explizit behandelt. Die Leckrate durch vergessene IPv6-Split-Tunnel-Regeln ist hoch.
- Domainbasierte Regeln für sicherheitskritische Entscheidungen verwenden. Domainbasiertes Split-Tunneling ist für Komfort-Anpassungen geeignet. Es ist nicht zuverlässig genug, um zu erzwingen, dass „diese sensible App immer durch das VPN geht“ – dafür nutze App-basierte Regeln, bei denen die App explizit getunnelt ist, am besten im Zulassungslisten-Modus.
- Regeln nicht regelmäßig überprüfen. Apps werden hinzugefügt und entfernt; neue Apps desselben Herstellers erben nichts von den alten. Überprüfe deinen Split-Tunnel-Regelsatz regelmäßig.
Das ehrliche Fazit zu Split-Tunneling
Split-Tunneling ist für bestimmte Probleme wirklich nützlich – Streaming-Apps, die VPNs erkennen, Banking-Apps, die VPN-Logins markieren, lokaler Netzwerkzugriff – und hat eine lange Geschichte legitimer Nutzung in Unternehmensumgebungen. Für Endverbraucher ist die ehrliche Einschätzung: Es ist in erster Linie ein Komfort-Tool und erst in zweiter Linie ein Datenschutz-Tool. Jede Split-Tunnel-Regel schwächt das Schutzmodell auf eine bestimmte Weise, und der Sicherheits-Kompromiss lohnt sich nur, wenn der Schutz diesem Datenverkehr ohnehin nicht viel geboten hätte (z. B. eine Banksitzung, die bereits TLS-verschlüsselt ist und zu einem einzigen bekannten Ziel geht).
Wenn dein Bedrohungsmodell lautet: „Ich möchte ein VPN in feindlichen öffentlichen WLAN-Netzwerken, damit der lokale Netzwerkbetreiber meinen Datenverkehr nicht beobachten kann“, ist ein vollständiger Tunnel die richtige Antwort. Aktiviere Split-Tunneling nicht einfach, weil der VPN-Client es anbietet – jeder Ausschluss ist ein Loch. Wenn dein Bedrohungsmodell lautet: „Ich möchte die meisten Verbindungen schützen, aber bestimmte Apps brauchen das echte Netzwerk“, ist Split-Tunneling das richtige Werkzeug – konfiguriere es aber sorgfältig, teste anschließend auf DNS- und IPv6-Lecks, und überprüfe die Regeln regelmäßig. Die technische Referenz in der WireGuard-Schnellstart-Dokumentation zeigt, wie die zugrundeliegenden Routing-Entscheidungen auf Protokollebene funktionieren.
Casper's Cloak verwendet standardmäßig eine Vollständiger-Tunnel-Architektur, weil das Bedrohungsmodell, gegen das wir schützen – feindliche Netzwerke, ISP-Überwachung, Ad-Tech-Tracking – vom einfacheren „alles tunneln“-Modell profitiert. Wir ergänzen das mit Tracker-Filterung auf DNS-Ebene und KI-basierter Bedrohungserkennung für bekannt-bösartige Ziele, sodass der vollständige Tunnel auch aktiv filtert – nicht nur routet. Für die Sonderfälle Streaming und Banking ist der richtige Schritt meist ein kurzes Trennen der Verbindung, statt dauerhaft einen Satz von Split-Tunnel-Ausnahmen zu pflegen, den man schnell vergisst.