How split tunneling works

Split tunneling is a VPN configuration where only some network traffic is sent through the VPN tunnel, while the rest goes out directly via your normal internet connection.

In practice, your device decides “which destinations belong to the VPN” based on routing rules (often called allowlists or route lists). Traffic to destinations that match those rules is encrypted and sent through the VPN. Traffic that does not match the rules is handled by the standard network path.

This is different from a full-tunnel configuration, where most or all traffic is forced through the VPN. Because split tunneling changes the path traffic takes, it also changes the security model and how you troubleshoot connectivity issues.

Benefits of split tunneling

Split tunneling is commonly used to balance VPN protection with everyday usability.

  • Potential performance gains: If latency-sensitive or high-bandwidth traffic (for example, streaming or local network interactions) is allowed to bypass the VPN, the VPN’s additional overhead may affect it less.
  • Better local access: Devices often need to reach local resources (such as printers, NAS devices, or local web interfaces). With split tunneling, you can keep these connections local instead of forcing everything through the VPN.
  • More predictable user experience for mixed workloads: Some apps benefit from VPN routing (for example, accessing a workplace site), while others work better without it. Split tunneling lets you separate those needs.

What “benefit” you get depends on your rule set and on where the traffic actually ends up. If the rules are broad, performance and local-access benefits may shrink; if rules are narrow, the VPN’s protective coverage may be reduced.

Limitations and trade-offs to understand

Split tunneling is not a free upgrade over full tunneling. It changes what is protected by the VPN and what is not.

  • Reduced VPN coverage for bypassed traffic: Any traffic that is not routed through the VPN follows your direct internet path. From a security perspective, this means that bypassed traffic may not receive the same protections that you expect from a VPN tunnel.
  • Harder to reason about “what is protected”: With split tunneling, two traffic flows may behave differently. A site might load normally (because it went direct), while another might fail (because it must match the VPN rules).
  • DNS and name resolution complexity: Many systems use DNS to map hostnames to IPs. If DNS queries or DNS responses take different paths than expected, the same “website” may resolve to different routes, leading to confusing results.
  • Rule maintenance: As destinations change (new subdomains, different IP ranges, updated service endpoints), your routing rules may become outdated. That can create partial connectivity or unexpected leakage via bypassed routes.

Because split tunneling behavior depends on platform and VPN client implementation, the exact user experience can vary. If you want high confidence, rely on verification steps rather than assumptions.

Practical checks: confirm where your traffic goes

To use split tunneling safely and effectively, you should verify the behavior that matters for your setup.

  1. Confirm DNS behavior: Check whether DNS queries are going through the VPN for the traffic you intend to protect, or whether only certain domains use VPN-resolved routes. If DNS is leaking or behaving unexpectedly, connectivity and security expectations may diverge.
  2. Verify routing for the destinations you care about: For a few known test endpoints (for example, a workplace domain you expect to route through the VPN, and a local service you expect to remain local), confirm which path they use. If the VPN is intended for specific destinations, those destinations should match the VPN rules.
  3. Test both “expected VPN” and “expected bypass” scenarios: Don’t only confirm that the VPN works—also confirm that bypassed services still function as intended (for example, local web pages or device discovery).
  4. Watch for app-specific behavior: Some applications use different networking mechanisms or maintain their own connections. If your rules target destinations by domain or IP ranges, ensure the app actually connects to the expected endpoints.

Split tunneling often comes up alongside a few related ideas:

  • Full tunneling: Most traffic is routed through the VPN, which simplifies “what’s protected” but may add overhead and can reduce local access.
  • Policy-based routing / route-based selection: Split tunneling relies on selection rules to decide which traffic uses the VPN tunnel.
  • Threat model alignment: If your goal is to protect only particular resources (for example, access to specific internal services), split tunneling can align with that. If your goal is broad protection for almost everything you do, a full-tunnel approach may be closer to your intent.

A useful rule of thumb: split tunneling is best viewed as a controlled exception to full tunneling. You should decide deliberately which destinations deserve VPN handling, and then verify those decisions with DNS and routing checks.