What split tunneling is (and what it is not)

Split tunneling is a VPN setup where not all of your network traffic is sent through the encrypted VPN tunnel. Instead, the VPN only handles traffic that matches certain criteria (for example, specific domains, IP ranges, or applications), while the remaining traffic continues using your regular internet path.

This differs from full tunneling, where essentially all outbound traffic goes through the VPN. With split tunneling, the key trade-off is that your protection is more selective: protected destinations benefit from the VPN’s privacy and security properties, while unprotected traffic does not.

How it works in practice

In a typical split-tunnel design, you configure rules that decide which traffic uses the VPN tunnel. Common rule types include:

  • Domain-based selection (e.g., only send traffic to certain websites through the VPN)
  • IP range selection (e.g., only route traffic for specific networks)
  • App-based selection (e.g., only route traffic generated by certain applications)

Once a rule matches, the client routes that traffic into the VPN tunnel. Traffic that does not match continues through the local network interface and exits via the normal route.

Because VPN “selection” usually depends on networking details, the effective behavior can vary by device and operating system, and also by how an application establishes connections. Some apps may open multiple connections, use embedded browsers, or rely on both DNS and direct IP access—each of which can affect whether traffic is classified as “VPN” or “not VPN.”

The benefits: better security where it matters, more flexibility elsewhere

The main advantage is control. Split tunneling lets you protect selected resources while keeping other traffic unencumbered.

1) Improved performance and reduced latency for non-sensitive traffic

By not encrypting and routing everything through the VPN, you can reduce overhead for everyday browsing, streaming, or other activities that don’t need the VPN’s protections. The result can be more responsive experiences—especially when the VPN path is longer or slower than your direct connection.

2) Access to local services without routing them through the VPN

If you need to reach printers, local web interfaces, or other on-premises services, split tunneling can avoid sending that local traffic through the VPN tunnel. This can improve usability because local services often work best when traffic stays on the local network.

3) Clearer scope of what gets protected

Split tunneling encourages you to define “what should be protected” rather than assuming everything is. When you choose a narrow scope (for example, only certain work-related services), you reduce the impact of the VPN on unrelated activities while still adding protection to the selected targets.

4) Flexibility for mixed work and personal use

Many users want work resources to be protected while still using local or personal services normally. Split tunneling can support this mixed behavior by separating the traffic streams.

Differences and limitations you should understand

Split tunneling can be beneficial, but it changes your threat model. The limitations below are often the difference between “works as expected” and “it looks protected but isn’t.”

1) Non-VPN traffic is not protected by the VPN

Anything not routed through the tunnel is exposed to the same risks as a normal internet connection (including local network observation and ISP path visibility, depending on your network environment). If your goal is consistent protection across all traffic, full tunneling is typically closer to that objective.

2) DNS and name resolution can create confusion

Even if only selected domains are intended for the VPN, DNS resolution is a common source of “unexpected routing.” For example, if DNS queries are handled differently than the actual traffic, you may end up with behavior that does not match your intent.

This is not a universal rule—it depends on the client, OS, and configuration—but it’s a reason to treat DNS behavior as part of split-tunnel validation, not an afterthought.

3) “Leak” risk depends on your configuration and client behavior

Misconfiguration can cause traffic to escape the VPN tunnel when you expected it to be protected. Conversely, traffic can be routed into the VPN when you expected it to stay direct. Either case undermines the main promise of selective routing.

Because client software and network stacks differ, it’s difficult to guarantee correctness without checking.

4) Application behavior can break simple assumptions

Some applications use techniques that make traffic classification more complex:

  • Multiple domains resolving to changing IPs
  • Persistent connections that continue after rule changes
  • Embedded components (browsers, in-app views) that may not map cleanly to “app-based” rules

As a result, a policy that seems correct at the domain level may still fail in edge cases.

Practical checks you can do before relying on split tunneling

To use split tunneling safely, validate what is actually routed through the VPN and what is not.

1) Confirm routing for the intended destinations

Pick a destination that should go through the VPN (based on your rule) and another destination that should not. Verify that each behaves as expected—especially in terms of connection path and how the VPN client reports matched traffic.

Since exact verification methods vary, the key is comparing behavior against your intended scope, not relying on assumptions.

2) Validate DNS resolution behavior

Use controlled tests (for example, querying a domain you expect to be protected and one you expect to stay direct). Make sure the resolution and the resulting connection follow the same scope you intended.

If DNS handling differs from traffic routing, you may need to adjust your policy or client settings.

3) Re-check after changes and updates

Rule sets, client versions, and OS networking components can change behavior over time. Re-run basic checks after:

  • Updating the VPN client
  • Changing the rule list
  • Switching networks (home ↔ office, Wi‑Fi ↔ cellular)

4) Watch for edge cases with apps you use frequently

Test the applications that matter most for your workload (work tools, remote portals, video calls, or internal web apps). If one app behaves inconsistently, refine the scope method (domain/IP/app rules) rather than assuming all apps follow the same pattern.

Split tunneling is often discussed alongside:

  • Full tunneling (protecting most or all traffic)
  • Kill switch behavior (preventing traffic from leaving the device when the VPN connection is down)
  • DNS configuration choices (how names resolve and where queries are sent)

The important link is that “security guarantees” depend on the overall design. Split tunneling reduces the amount of traffic going through the VPN, so your protections become as selective as your routing rules.