What is split tunneling — how VPN per-app routing actually works

The short version: a standard VPN routes 100% of your device's traffic through the encrypted tunnel. Split tunneling breaks that rule on purpose. You pick which apps or which destinations bypass the tunnel and go straight out your normal connection. It sounds simple, and in concept it is — but the practical implementation differs significantly across operating systems, and the privacy trade-offs are easy to miss. A streaming app routed outside the tunnel still sees your real IP. A banking app routed outside the tunnel still talks to your bank over your home network — which is fine, until the same app also makes a DNS query that leaks through the bypass and exposes a different domain you didn't intend to reveal.

What VPN tunneling actually does (the baseline)

Before you can understand what's being split, you need to be clear on what the full tunnel does. A VPN client running on your device creates a virtual network interface — on Linux it's typically called tun0 or wg0, on macOS it's utun, on iOS and Android the operating system manages it through a per-app extension API. The operating system's routing table is then modified so that the default route — the rule that says "send packets with no other matching route to this gateway" — points to that virtual interface instead of your physical Wi-Fi or cellular interface.

From that point on, every packet your device generates is encrypted by the VPN client, wrapped in a new IP header that targets the VPN server, and sent out the physical interface as a single homogeneous stream. The VPN server decrypts the packet, forwards it to its real destination on the public internet, receives the reply, encrypts it again, and sends it back. Your ISP sees only the encrypted stream going to a single IP. Destination websites see the VPN server's IP, not yours.

That's the default. Split tunneling intervenes in this model by adding more specific routes to the routing table — rules that say "for traffic going to this destination" or "for traffic generated by this app, ignore the default tunnel route and use the physical interface directly."

What split tunneling changes

Conceptually, split tunneling introduces a fork in your network flow. Some packets go through the encrypted tunnel; some go out the bare interface. The decision is made by the VPN client according to rules you configure. There are three common categories of split rule:

• App-based — "Send all traffic from Netflix outside the tunnel; tunnel everything else." Implemented by tagging packets with the originating process's UID or PID, then making routing decisions per-tag.
• Destination-based — "Send traffic to 10.0.0.0/8 outside the tunnel so I can reach my home NAS; tunnel everything else." Implemented purely with routing-table entries — the simplest form.
• URL or domain-based — "Send traffic to *.bank.com outside the tunnel." This is fragile because the OS routing layer doesn't natively know domains; it requires the VPN client to either intercept DNS and rewrite responses, or to maintain a dynamic IP allowlist that follows DNS resolutions. Vendors implement this inconsistently.

Here's the architectural picture, simplified:

Full tunnel (no split):
  [App A] -> [App B] -> [App C]
        \        |        /
         [Virtual VPN interface]
                 |
         [Encrypted tunnel]
                 |
         [VPN server] -> internet

Split tunnel (app-based, App C excluded):
  [App A] -> [App B]        [App C]
        \        /               \
   [Virtual VPN interface]   [Physical Wi-Fi]
              |                    |
       [Encrypted tunnel]    [Plain internet]
              |                    |
        [VPN server]         direct to dest

The "split" is the divergence point inside your operating system — the choice between virtual interface and physical interface is made before encryption happens, so a packet that bypasses the tunnel was never encrypted in the first place. There's no decryption step; it just leaves your device as-is.

Inverse split tunneling — allowlist vs blocklist

Split tunneling configurations come in two flavors that look symmetric but have very different default-fail behavior:

• Blocklist mode (the common default) — "Tunnel everything except the apps/destinations on this list." The default is protected; only specific exceptions leak. If you forget to add an app to the list, it stays protected.
• Allowlist mode (also called inverse split tunneling) — "Tunnel only the apps/destinations on this list; everything else goes direct." The default is unprotected; only specific apps are tunneled. If you forget to add an app to the list, it leaks.

Allowlist mode is the right choice for "I only want my browser to use the VPN, everything else can use my normal connection." Blocklist mode is the right choice for "I want most things protected, but a few specific apps need the real network." Most consumers want blocklist mode. Operations and DevOps teams sometimes prefer allowlist mode because they're trying to expose specific services through the tunnel without disrupting the rest of the system.

The failure mode for allowlist mode is severe: if you add a new app and forget to add it to the allowlist, that app's traffic leaks. The failure mode for blocklist mode is milder: forgotten apps stay protected — you just have annoying compatibility issues when a streaming or banking app fails because it sees the VPN IP.

When to use split tunneling — five concrete scenarios

Split tunneling has real legitimate uses. These are the situations where it's the right tool:

1. Streaming services that detect and block VPN endpoints

Netflix, Disney+, Hulu, and most regional broadcasters maintain large allowlists of known VPN datacenter IPs and refuse to stream when they detect one. You can either turn the VPN off (losing all protection) or split-tunnel the streaming app so it sees your real IP while everything else stays protected.

2. Banking and financial apps with location-based fraud detection

Banks frequently treat a sudden IP change to a VPN datacenter as a fraud signal — they'll trigger step-up authentication, hold transactions, or briefly lock the account. Splitting the bank's app out of the tunnel keeps your real-IP relationship with the bank consistent. This is a usability fix, not a security upgrade — the bank's connection is already TLS-encrypted, so the VPN was never adding much security to that specific session.

3. Local network resources (NAS, printer, smart home)

When the VPN captures all traffic, your device can no longer reach the printer at 192.168.1.50 because that IP is unreachable through the VPN tunnel. Destination-based split tunneling (excluding 192.168.0.0/16 and 10.0.0.0/8) restores local access without disabling the VPN for the public internet. Many VPN clients do this automatically as a default; some don't.

4. Latency-sensitive applications

Competitive online gaming, live video conferencing, and voice calls suffer when extra latency is introduced by routing through a VPN server in a distant region. Splitting those specific apps out can recover the latency while keeping everything else encrypted. The trade-off: those apps are now identifiable to your ISP and visible to network observers.

5. Work VPNs alongside personal VPNs

If your employer requires a corporate VPN for accessing internal resources, and you want personal traffic going through a different (privacy-focused) VPN, split tunneling on the corporate VPN — sending only the corporate IP ranges through it — leaves the rest of your traffic available to the personal VPN. This is a power-user setup but it's a clean way to keep work and personal traffic separated.

When NOT to use split tunneling — the privacy gotchas

Split tunneling makes your network behavior more complex, and complex network behavior leaks in non-obvious ways. The most common failure modes:

DNS leaks through the bypass path

Even when an app's TCP traffic is routed outside the tunnel, its DNS queries may still be configured to use the VPN's DNS resolver — or worse, may fall back to the ISP's DNS resolver if the VPN client doesn't manage system DNS carefully. The result: an app that should be invisible to your ISP becomes partly visible. The ISP sees the DNS query for banking.example.com even though the subsequent TCP connection went through some other path. We have a deeper writeup of how DNS encryption fits in our DNS-over-HTTPS guide.

App-vs-domain confusion

App-based split tunneling routes by process identity, but modern apps make connections to many domains. Your "streaming app" probably loads ads, telemetry, recommendation APIs, and analytics endpoints from dozens of different domains — some of which are shared with apps that you do want tunneled. Excluding the entire app means excluding all of those connections. Domain-based split tunneling has the opposite problem: a single app might load the same CDN domain for both the streaming video (which you want unprotected) and for content you'd rather not reveal.

IPv6 leaks

Many split-tunnel implementations were designed when IPv4 was the only routing concern. If your network has IPv6 connectivity and the split-tunnel rules don't explicitly include IPv6 routes, packets that should be tunneled may exit over IPv6 outside the tunnel. This is one of the most common VPN leaks in 2026 and is almost always caused by incomplete split-tunnel rule configuration. Test for it with an IPv6 leak test after enabling split tunneling.

Kill switch interactions

A kill switch is designed to block all traffic if the VPN drops, so nothing leaks unprotected. With split tunneling enabled, the kill switch logic gets harder — the kill switch should still allow split-tunneled apps to communicate, but only those, and only when the VPN itself is also down. Many VPN clients have bugs where the kill switch either fails to block tunneled apps when the VPN drops, or incorrectly blocks split-tunneled apps that should keep working. Test the combination explicitly.

Split tunneling mode comparison

How split tunneling works on each operating system

iOS — limited and indirect

iOS does not expose a true split-tunneling API to third-party VPN apps. The NetworkExtension framework allows a VPN to be configured as either system-wide (all traffic) or per-app (only apps explicitly registered by an MDM profile). True per-app split routing requires Apple's NEAppProxyProvider with an MDM-distributed configuration profile — meaning a managed-device scenario. Consumer VPN apps on iOS that advertise "split tunneling" typically implement destination-based exclusions (e.g., excluding specific IP ranges from the tunnel) or use the on-demand rules API to conditionally activate the VPN based on Wi-Fi SSID or domain match. App-based split tunneling for consumer iOS users isn't really available.

Android — first-class support

Android's VpnService API supports per-app routing natively. The VPN client can call addAllowedApplication() or addDisallowedApplication() to specify which apps go through the tunnel. The OS handles the per-app routing transparently — the VPN client doesn't need to do packet-level tagging. Android also supports the "Always-on VPN" system setting with a "Block connections without VPN" option, which combines kill-switch behavior with the per-app config: tunneled apps go through, non-tunneled apps go direct, and if the VPN drops, the tunneled apps are blocked.

macOS — implementation varies

macOS supports split tunneling through several mechanisms: the NetworkExtension framework (similar to iOS, with more flexibility), packet filters configured via pf rules, or routing-table manipulation by VPN clients running with elevated privileges. App-based split tunneling on macOS is workable but requires the VPN client to query the kernel for socket-to-process mappings. Destination-based splitting is straightforward and reliable.

Windows — most common platform for split tunneling

Windows VPN clients have used split tunneling for over a decade. The Windows Filtering Platform (WFP) provides the kernel-level packet inspection and routing decision API that VPN clients hook into. Per-app split tunneling on Windows is well-supported and widely deployed. Most enterprise VPN deployments use Windows split tunneling to ensure that corporate traffic goes through the corporate tunnel while general internet traffic goes direct — partly for performance, partly to reduce load on the corporate VPN concentrators.

Common mistakes when configuring split tunneling

Watching how people actually misconfigure split tunneling reveals a few recurring patterns. If you set it up, check yourself against this list:

• Not testing for DNS leaks after enabling it. Run a leak test (dnsleaktest.com or similar) after every config change. If you see your ISP's DNS resolver listed for an app that should be tunneled, the bypass is leaking DNS.
• Forgetting that browsers are special. A browser running a streaming web app routes both the streaming video and your other tabs through the same process. Excluding the browser excludes all of your browsing. Use a separate browser profile or a different app for the streaming case.
• Not handling IPv6. Disable IPv6 entirely if your VPN client doesn't handle it explicitly. The leak rate from forgotten IPv6 split-tunnel rules is high.
• Using domain-based rules for security-critical decisions. Domain-based split tunneling is fine for usability tweaks. It's not reliable enough to enforce "this sensitive app must always go through the VPN" — for that, use app-based rules with the app explicitly tunneled, ideally in allowlist mode.
• Not reviewing the rules quarterly. Apps get added and removed; new apps from the same publisher inherit nothing from the old ones. Periodically audit your split-tunnel ruleset.

The honest verdict on split tunneling

Split tunneling is genuinely useful for specific problems — streaming apps that detect VPNs, banking apps that flag VPN logins, local network access — and it has a long history of legitimate deployment in enterprise environments. For consumers, the honest framing is that it's a usability tool first and a privacy tool second. Every split-tunnel rule weakens the protection model in some specific way, and the security trade-off is only worth it when the protection wouldn't have helped that traffic anyway (e.g., a bank session that's already TLS-encrypted and going to a single well-known destination).

If your threat model is "I want a VPN on hostile public Wi-Fi networks so the local network operator can't observe my traffic," a full tunnel is the right answer. Don't enable split tunneling just because the VPN client offers it — every exclusion is a hole. If your threat model is "I want most traffic protected but specific apps need the real network," split tunneling is the right tool, but configure it carefully, test for DNS and IPv6 leaks afterward, and review the rules periodically. The technical reference at the WireGuard quickstart documentation shows how the underlying routing decisions work at the protocol layer.

Casper's Cloak uses a full-tunnel architecture by default because the threat model we're protecting against — hostile networks, ISP surveillance, ad-tech tracking — benefits from the simpler "tunnel everything" model. We pair that with tracker filtering at the DNS layer and AI threat detection for known-malicious destinations, so the full tunnel is also doing active filtering — not just routing. For the streaming and banking edge cases, the right move is usually to briefly disconnect rather than maintain a permanent set of split-tunnel exclusions that you'll forget about.