How split tunneling works in a VPN

Split tunneling is a configuration where only some traffic is routed through the VPN tunnel, while the rest uses your normal network path. Instead of “everything goes through the VPN,” the VPN client (or the device/network configuration behind it) decides which destinations, apps, or IP ranges should be sent over the tunnel.

In practice, this decision can be based on patterns such as:

  • Per-application selection (certain apps use the VPN, others bypass it)
  • Per-destination selection (only certain domains/IP ranges are tunneled)
  • Network/interface policies (traffic to local subnets may stay local)

Because the VPN only protects what it carries, split tunneling changes your baseline expectations: traffic that bypasses the tunnel will not get the VPN’s protections (for example, it will not be routed to the VPN’s exit network).

What you gain—and what you trade off

Split tunneling is often used for operational reasons. For example, keeping local traffic outside the VPN may help with:

  • Accessing local devices/services (such as printers or LAN-hosted tools)
  • Reducing overhead for traffic that is sensitive to latency on the local network

However, the trade-off is that you must accept a narrower “protected surface.” If an application or destination that you assumed was protected is actually bypassing the tunnel, your privacy and threat model no longer match the behavior you would expect from full tunneling.

Key practical trade-offs to consider:

  • Consistency: With split tunneling, different parts of your activity may follow different network paths.
  • Observability: Debugging becomes more complex because “the VPN” is no longer the single path for all traffic.
  • Assumption mismatch: Users often think “VPN is on, so everything is covered,” which is not necessarily true.

Limitations and the most common exceptions

The biggest limitation is not the concept itself, but what’s excluded. Exclusions can be wider than intended—especially when rules are broad (for example, allowing entire local networks) or when applications do not behave as expected.

Common categories of issues include:

  • DNS behavior: Even if “website traffic” appears to be tunneled, name resolution may still occur outside the VPN depending on configuration. If DNS queries leak, observers can infer which domains you’re trying to reach.
  • Authentication flows: Some login or token refresh components may use different endpoints or background requests than you expect.
  • Background services: Apps may spawn helper processes, use system components, or make calls to multiple domains/IPs—some of which might not match your tunneling rules.
  • Overlapping networks: If the tunneling rules treat “local” or “private ranges” broadly, traffic that you didn’t mean to bypass may do so.

A useful mindset is: split tunneling narrows the set of connections you can treat as protected. Anything you exclude could still carry sensitive metadata—such as destination, timing, and possibly content—depending on the protocol and path.

Practical checks before relying on split tunneling

Because the exact behavior depends on your VPN client settings and the device’s networking features, you should verify your setup rather than rely on assumptions. Use checks aligned to the main question: which traffic is actually going through the VPN, and which is not?

Consider these practical verification steps:

  1. Confirm per-app and per-destination rules. Review which apps and which domains/IP ranges are selected for tunneling, and which are explicitly bypassed.
  2. Check DNS handling. Look for whether DNS resolution is performed through the VPN path or via your local network. If your environment supports inspection, compare behavior for tunneled vs bypassed traffic.
  3. Validate with “path-sensitive” endpoints. Pick a few representative destinations—one that should be tunneled and one that should bypass (e.g., a local service vs a remote site)—and confirm that they behave as expected.
  4. Test for leaks or mismatches. If your VPN client offers diagnostics, use them to see whether certain requests escape the tunnel. If not, you can still reason from observed behavior: different IPs/egress characteristics for the same app across different destinations usually indicate split routing.
  5. Re-check after changes. Rule updates, network changes (Wi-Fi to mobile), or app updates can change which traffic matches your split policies.

Split tunneling is often discussed alongside other routing ideas. Two related concepts to keep clear are:

  • Full tunneling: All (or nearly all) traffic goes through the VPN tunnel.
  • Bypass lists / exclusions: Rules that explicitly keep certain traffic outside the tunnel.

Another related area is local network access (allowing access to LAN resources while tunneling the rest). Local access can be legitimate and useful, but it directly affects the scope of what remains outside VPN protection.

Because different implementations vary and you may not know the exact internals of your client or operating system, treat split tunneling as a configuration you must verify end-to-end. If you can’t confidently confirm which traffic is tunneled—especially DNS and authentication-related requests—assume the protection scope is smaller than full tunneling and adjust your expectations accordingly.