Split Tunneling vs Full Tunneling: Which VPN Mode Should You Use?

Full tunneling makes the VPN the default route for internet traffic; split tunneling creates rules that send only selected apps, destinations, or networks through—or around—the tunnel. Full tunnel gives the simplest privacy boundary. Split tunnel reduces unnecessary detours and preserves local access, but every exception becomes traffic you must classify, secure, and test.

The correct choice is not “security versus speed” in the abstract. It depends on which traffic needs the VPN, whether the device is trusted, how DNS and IPv6 follow the policy, and whether direct traffic still receives endpoint, cloud, or network security controls.

Routes decide, not labelsHow VPN Traffic Routing Actually Works

A device chooses a network interface using its routing table and policy rules. A consumer VPN app creates a virtual interface, encrypts packets sent to it, and transports them to a VPN server. In a full/force-tunnel design, the app normally installs IPv4 and IPv6 default routes through that interface. In a split design, more-specific rules select traffic by destination, application, or an exclusion from the VPN default. Microsoft’s Windows VPN routing documentation shows this distinction at the route-table level.

“All traffic” is useful shorthand, not a literal guarantee. The VPN control connection itself must reach the server over the physical network. Local-network routes, captive portals, system services, IPv6, multicast, or explicit exclusions may behave differently. A strong client accounts for these paths and explains local-network access separately.

One default privacy boundaryWhat Is Full Tunneling?

Full tunneling routes internet-bound traffic through the VPN unless a more-specific permitted route says otherwise. Websites see the VPN exit address; the local network and ISP generally see an encrypted connection to the VPN rather than each remote destination. DNS should follow the protected path, and a system-wide kill switch can block traffic if that path disappears.

Full tunneling does not make a device anonymous or safe from malware. Logins, cookies, browser fingerprints, endpoint compromise, and the VPN provider’s data practices remain separate concerns. See our guide to VPN logging policies.

Selective routingWhat Is Split Tunneling?

Split tunneling sends two classes of traffic over different paths at the same time. The protected class uses the VPN; the direct class uses the ordinary Wi-Fi, Ethernet, or cellular interface. Direct traffic normally exposes the user’s ISP-assigned IP to destinations and may expose metadata to the local network or ISP. It is not “partly encrypted” by the VPN—it is outside that VPN.

The feature can improve performance and compatibility, but only for bypassed traffic that would otherwise suffer a meaningful detour or bottleneck. If the VPN server is nearby and fast, the difference may be negligible. If the app itself uses HTTPS or another secure protocol, direct traffic may still be encrypted end-to-end, but it loses the VPN’s IP masking and tunnel-level protections.

Five rule modelsTypes of VPN Split Tunneling

Side-by-sideSplit Tunneling vs Full Tunneling

Measure your actual pathPerformance: What Split Tunneling Can and Cannot Improve

There is no defensible universal “10–30% VPN slowdown.” Overhead changes with server distance, congestion, protocol, CPU, MTU, ISP peering, upload/download mix, and whether the workload is latency-sensitive. Split tunneling improves only the traffic sent direct; it does not accelerate the protected apps.

Benchmark both modes on the same server and network. Record latency, jitter, upload, download, application behavior, and VPN-gateway load—not only a browser speed test. Voice/video calls care about latency and jitter; backups care about throughput; gaming cares about route stability; local device access cares about reachability.

The bypass path is deliberate exposureSecurity and Privacy Considerations

Split tunneling is not inherently insecure. It changes which controls cover each flow. A direct SaaS connection can still use strong TLS, phishing defenses, device posture, MFA, endpoint detection, and cloud access policies. The risk comes from assuming that traffic remains behind VPN-based filtering, logging, or IP allowlists when it no longer does.

A split-tunneled machine does not automatically “bridge” the public internet into a private network, but a compromised endpoint can become a pivot because it has both paths. Strong host firewalling, patching, EDR, least-privilege access, MFA, segmentation, and service-side authorization remain essential.

The hidden edge casesDNS, IPv6, Local Networks, and Kill Switches

DNS may not follow the app rule

Some clients keep every DNS query on the VPN resolver even for excluded apps; ExpressVPN documents this behavior. Other implementations scope DNS by interface, namespace, or app. Browser DoH can create another resolver path. Test hostname resolution as well as public IP, and read our guide to preventing DNS leaks.

IPv4 and IPv6 need equivalent policy

A rule that matches only an IPv4 address does not automatically cover the service’s IPv6 address. A reliable client must tunnel, exclude, or block each address family consistently. Test both after changing split rules.

Local network access is its own control

A “allow LAN” switch commonly adds private-address routes for printers, casting, routers, and NAS devices. It is broader than excluding one internet app. Leave it off on hostile Wi-Fi unless you need local discovery, and never assume a hotel’s private subnet is trusted.

Kill-switch semantics vary

A system-wide kill switch cannot block intentionally direct apps without defeating split tunneling. Good implementations block protected-app traffic when the VPN fails while preserving declared bypass traffic. Proton currently documents split tunneling as incompatible with its kill switch on most platforms except Windows; this kind of interaction must be checked per device.

Choose by objectiveBest Tunneling Mode for Common Scenarios

For content-access troubleshooting, see how to unblock websites with VPNs or proxies.

From perimeter to policySplit Tunneling for Businesses and Remote Teams

Enterprises use split tunneling to avoid hairpinning high-volume cloud traffic through a data center. Microsoft documents several models, from force tunnel with a few trusted exclusions to a selective tunnel that carries only corporate networks. Its Microsoft 365 guidance favors tightly scoped, high-volume, latency-sensitive “Optimize” endpoints rather than a blanket bypass for every cloud service.

The security question is not whether packets traverse headquarters; it is whether equivalent controls exist on the direct path. Modern designs can enforce identity, device compliance, MFA, EDR, DLP, secure web gateways, CASB/SSE, and application-layer authorization outside a legacy VPN perimeter.

1. Inventory flows and owners. Identify applications, destinations, ports, DNS needs, data sensitivity, and business impact.
2. Start with force tunnel plus narrow exclusions. Prefer vendor-published, machine-readable endpoint sets with change management.
3. Move controls to the correct layer. Direct traffic needs endpoint and cloud enforcement, not an assumption that the VPN gateway sees it.
4. Protect the private side. Segment internal resources, require MFA/device posture, and prevent a compromised remote host from reaching more than necessary.
5. Observe both paths. Collect endpoint, identity, SaaS, DNS, and gateway telemetry with privacy and retention controls.
6. Test failure and rollback. Validate DNS, IPv6, route changes, network transitions, kill switch, and emergency revocation.

Current documented supportSplit Tunneling by VPN Provider and Platform

Capabilities move quickly and feature names hide meaningful differences. At the platform level, Android’s official VpnService.Builder reference shows that VPN apps can set routes and DNS, allow or disallow individual applications, and control IPv4/IPv6 families—one reason two Android VPNs can implement “split tunneling” differently. The table reflects vendor documentation reviewed for this update; verify the exact app build and protocol before purchase.

Platform support is not feature equivalence. For example, a website exception on iOS, an Android per-app exclusion, and a Windows IP range are three different routing controls.

Trust, then verifyHow to Configure and Test Split Tunneling Safely

1. Write the desired policy in plain language. Example: “Everything uses VPN except the game and 192.168.1.0/24 at home.”
2. Choose exclude mode when possible. It keeps future and unknown apps protected by default.
3. Add the smallest rule. Prefer one signed application or narrow subnet over a broad browser or cloud range.
4. Reconnect and restart affected apps. Existing sockets may keep their old route; Proton specifically requires restarts for affected Linux apps.
5. Verify public IP per app. Protected apps should show VPN exit; bypass apps should show ISP IP. Check IPv4 and IPv6.
6. Verify DNS and local access. Confirm resolvers and private routes match the policy rather than merely “working.”
7. Force a VPN drop. Protected traffic should stop or follow documented behavior; bypass traffic should behave as intentionally configured.
8. Retest after updates. App paths, CDN addresses, helper processes, and OS routing can change.

On Windows, advanced users can inspect routes before and after connecting:

Do not edit managed corporate routes. Send discrepancies to the administrator with timestamps, app version, connection profile, and route/DNS output.

Common questionsSplit vs Full Tunneling FAQ

Disclosure: This article contains affiliate links. Purchases may earn us a commission at no extra cost to you. Affiliate relationships do not change the routing analysis or comparison criteria. Features vary by app version, platform, protocol, and region; confirm current vendor documentation.