What split tunneling means for a VPN

Split tunneling is a VPN configuration where not all network traffic is forced through the VPN tunnel. Instead, the VPN routes only specific traffic—commonly chosen by app, domain, IP range, or destination category—while the remaining traffic goes directly to the internet without VPN protection.

The practical goal is to balance privacy and security with day-to-day performance and compatibility. For example, you might want sensitive work traffic to use the VPN, while streaming services or local network features remain outside the tunnel.

How split tunneling works in practice

Most VPN clients implement split tunneling using a ruleset that decides what should “match” the VPN path.

Typical rule styles include:

  • App-based selection: Certain applications are allowed through the VPN, while other applications are excluded.
  • Destination-based selection: Traffic to particular domains, IP ranges, or networks is routed via the VPN.
  • Combination rules: Some clients let you refine the selection by both app and destination.

When a rule matches, the client intercepts outbound traffic from your device and forwards it through the encrypted VPN tunnel. When there is no match, the traffic follows the normal operating system networking path (often directly via your local interface).

Conceptually, split tunneling changes three things:

  1. Where traffic is encrypted: Only matching traffic is encrypted by the VPN.
  2. Which DNS and egress path applies: Depending on the client settings, name resolution and outbound routing for selected traffic may differ from non-selected traffic.
  3. How policies and access controls behave: Some services may “see” different source networks or routes depending on whether they’re using the tunneled path.

Differences to expect: full-tunnel vs split tunneling

A full-tunnel setup routes essentially all outbound traffic through the VPN. A split-tunnel setup routes only part of it.

Key differences you should expect:

  • Security boundary: With split tunneling, excluded traffic is not protected by the VPN and may be visible to observers along the local path.
  • Performance trade-offs: Excluded traffic can avoid VPN overhead and may feel faster or more compatible. However, tunneled and non-tunneled traffic can still contend for system resources.
  • Troubleshooting complexity: Failures can become harder to interpret because only part of your traffic might be affected by VPN settings.

Be careful with the assumption that “VPN is on, therefore everything is protected.” Split tunneling can intentionally do the opposite.

Limitations and “gotchas” to plan for

Split tunneling can help, but several limitations commonly affect real-world outcomes:

  • DNS and name resolution behavior may not match expectations. Even if a service is tunneled, the way your device resolves hostnames (and which DNS servers are used) can influence what traffic actually reaches the intended route. If resolution differs between tunneled and non-tunneled traffic, some requests may not behave like you expect.
  • Applications may open multiple connections. A single app “request” can involve several destinations or background services. If your split-tunnel rules cover only part of what the app uses, some connections may bypass the VPN.
  • Web browsers can blur app-based rules. Some clients treat browser traffic differently (for example, by how the browser spawns processes or uses system networking). This can lead to surprising results where some browser requests are tunneled and others are not.
  • Inconsistent policy paths can break access. If an internal service expects traffic to come from a specific network path, excluded traffic may be blocked while tunneled traffic works—or vice versa.
  • Mobile and network changes can reset routing. When you switch Wi‑Fi/LTE networks, sleep/resume, or change interfaces, the client’s routing rules may need to re-apply cleanly. A momentary mismatch can cause partial connectivity.

Because exact behavior depends on the VPN client implementation and the OS networking model, treat split tunneling outcomes as something you should verify rather than assume.

Practical checks: confirm what’s really going through the VPN

Use a short, controlled checklist to validate your setup.

1) Verify with a “known destination” test

  • Pick a site or service you can reliably access.
  • Compare behavior with split tunneling enabled vs disabled (or with a broader vs narrower rule set).
  • Look for differences in reachability and latency.

2) Confirm app coverage

  • Ensure the specific app you care about is actually included in the tunneled rules.
  • If your client uses app-based selection, test by closing the app completely and relaunching after changes.

3) Check DNS consistency (when possible)

  • If your client offers DNS options (such as custom DNS or DNS routing), review them alongside split tunneling settings.
  • If you notice that some connections don’t follow the expected route, DNS resolution is a frequent cause.

4) Watch for partial connectivity

  • If you can load some pages but not others, or some API calls fail while others succeed, that often indicates mixed routing.
  • Try isolating whether the issue correlates with excluded vs included destinations.

5) Re-test after network changes

  • Switch between networks, change Wi‑Fi, or trigger a sleep/resume cycle.
  • Confirm the routing rules still apply and that excluded traffic remains excluded.

Split tunneling is closely related to allowlists and exclusions. In many practical setups, it functions like a policy engine:

  • Allowlist-like behavior: Only specified traffic is tunneled.
  • Exclusion-like behavior: Everything is tunneled except what you exclude.

Whether you choose an allowlist or exclusion approach affects what you protect. If excluded traffic includes sensitive destinations by mistake, your overall privacy and security posture changes.

A useful way to think about it is threat modeling: define which traffic must be protected (or should be protected for compliance reasons) and which traffic can accept the default local path. Split tunneling makes that trade-off explicit.

Quick checklist: decide if split tunneling fits your goals

Use these criteria to decide whether split tunneling is appropriate:

  • You need better usability for certain apps while keeping VPN protection for others.
  • You understand that excluded traffic is not VPN-protected.
  • You can test and validate that the intended apps/domains are routed via the tunnel.
  • You’re comfortable managing more nuanced troubleshooting when things break.

If you cannot reliably verify traffic routing, a full-tunnel configuration may be simpler to reason about—because it reduces the chances of accidental leakage via excluded paths.