What split tunneling means for a VPN

Split tunneling is a VPN configuration approach where the tunnel is used for only part of your network traffic.

Instead of sending all traffic through the VPN, your device applies rules so that:

  • Some destinations (for example, specific websites, subnets, or internal services) go through the VPN.
  • Other destinations stay on your normal connection (the “local” route), which can be your ISP connection or corporate network route.

This is often chosen to reduce overhead, improve performance for local services, or avoid sending unnecessary traffic through the VPN.

How it works (the mental model)

A practical way to understand split tunneling is to think in terms of “routing decisions” made by your device:

  1. When an app tries to connect somewhere, the operating system needs to decide which path to use.
  2. Split tunneling rules influence that decision by matching the traffic to “VPN or not VPN.”
  3. If matched to the VPN path, packets are routed into the VPN tunnel.
  4. If matched to the local path, packets follow the normal network route.

Rules may be expressed as:

  • App-based rules (some apps always use VPN; others bypass it).
  • Destination-based rules (IP ranges, domain lists, or “only these networks over VPN”).
  • Exclusion rules (everything uses VPN except specific destinations, or the reverse).

Because matching happens before the final network transfer, the exact scope of “selected traffic” can vary by platform and by how the app establishes connections.

Setup: where split tunneling settings typically live

Split tunneling is usually configured inside the VPN client’s settings, often under terms like “split tunneling,” “bypass,” “route,” “allowed/disallowed networks,” or “app rules.”

Regardless of the label, the workflow is generally:

  1. Decide the intent: “Send only certain traffic through VPN” vs. “Bypass certain traffic from VPN.”
  2. Choose rule type: apps, destinations, or both.
  3. Enter the include/exclude items carefully (e.g., app identifiers, IP ranges, or domain names if supported).
  4. Confirm DNS behavior (if the client offers DNS over VPN vs. local DNS).
  5. Save changes and reconnect the VPN session (some clients apply routing changes only after reconnect).

If your VPN client provides only one rule mode (for example, only destination-based), prefer that mode over trying to force an app-based expectation that the client can’t implement.

Differences you should expect (and what can break)

Split tunneling can work well, but it introduces complexity. Common differences and failure modes include:

DNS can defeat your expectations

Even if an app’s traffic is “intended” for local routing, DNS resolution may still be handled in a way that changes outcomes. If DNS requests go through the VPN (or if they do not), you may observe:

  • Different IP addresses being returned (especially for content delivery networks).
  • Confusion where the browser shows one behavior but other apps behave differently.

Traffic selection may not match what you assume

“App-based” routing might apply only to traffic generated by the VPN-aware network stack, while some apps spawn helper processes or use components that may not be covered the way you expect.

Similarly, “destination-based” routing depends on accurate matching. If the client expects IP ranges but you provide domain names, or vice versa, matches may fail.

Only IPv4 vs. IPv6 and mixed environments

Many devices and networks use both IPv4 and IPv6. If split tunneling rules are primarily built around one address family, you may see partial bypass behavior where only one type of traffic is routed as intended.

Some networks and security software restrict changes

Enterprise policies, endpoint security tools, or restricted environments may prevent the client from installing the required routing behavior. In those cases, split tunneling may be unavailable, partially applied, or revert after reconnect.

Practical checks: confirm which traffic actually uses the VPN

Because split tunneling is rule-driven, “it should work” isn’t enough—verify it.

1) Check outward identity for non-bypassed traffic

Pick a destination that you expect to go through the VPN (for example, a service that should match your include rule). Then:

  • Compare your visible public IP (from a simple “what is my IP” check) when VPN is on and when it is off.

If your include traffic truly uses the VPN, public identity should reflect the VPN path.

2) Check that bypass traffic stays local

Now choose a destination you intend to bypass. Repeat the same kind of check.

  • If bypass is working, you should generally see behavior consistent with your local route rather than VPN identity.

If both checks look identical, your bypass rules may not be applying or might be overridden.

3) Validate DNS expectations

To test DNS consistency, you can:

  • Resolve the same hostname using the device’s usual methods with VPN on vs. off.
  • Compare whether DNS resolution appears to follow the same path you intended.

If the resolved IP changes between modes, your routing outcomes may change too.

4) Confirm with a controlled test destination

For the most reliable check, use a small set of destinations you control or that have stable addressing. Vague “most websites” testing can be misleading because many sites use dynamic resolution.

5) Review rule overlap

Rule ordering matters when both include and exclude rules exist. If your configuration allows “everything” plus a narrow bypass, an accidental broad include can cause bypass not to trigger.

After adjustments, always reconnect the VPN to ensure the routing rules are re-applied.

Limitations and best-fit scenarios

Split tunneling helps when you want selective routing, but it is not a universal solution.

  • If your main goal is to ensure all traffic uses the VPN, split tunneling is the opposite approach.
  • If you need predictable behavior for complex apps (multiple processes, custom networking stacks), expect some trial-and-error.
  • If you rely on consistent DNS behavior across all apps, confirm whether the client supports DNS routing choices that match your plan.

A safe way to proceed is to start with a narrow set of rules (few apps or a small list of destinations), verify with the checks above, then expand.

Two closely related terms you’ll often see alongside split tunneling are:

  • Include rules: only listed traffic is sent through the VPN.
  • Exclude/bypass rules: most traffic goes through the VPN, except what’s excluded.

Whether you choose include or exclude often depends on how broad your target is. If the VPN should cover a small set of sensitive destinations, an include approach can be easier. If you want VPN coverage broadly but need local exemptions, an exclude approach is usually more natural.