What split tunneling is, and why it can help

Split tunneling is a network setup where some of your online traffic goes through a VPN tunnel while other traffic bypasses the VPN and uses your normal internet connection. The practical goal is to balance security and convenience: keep sensitive or work-related traffic protected by the VPN, while letting low-risk traffic (for example, certain streaming, downloads, or local network access) use the direct path.

Because only part of your traffic is routed through the VPN, split tunneling can sometimes feel faster or more stable than forcing everything through a single encrypted tunnel—especially when the VPN path has higher latency or bandwidth limits than your direct connection. At the same time, it changes your threat exposure: traffic that does not go through the VPN is not covered by the same tunnel protections.

How split tunneling works (the key moving parts)

Most split tunneling configurations rely on one or more rules that match traffic to decide where it should go. These rules typically fall into categories such as:

  • Destination-based rules: route specific IP ranges, subnets, or domains through the VPN.
  • Application-based rules: route traffic generated by certain apps or processes through the VPN.
  • Port/protocol-based rules: route only certain protocols (like specific TCP/UDP traffic) through the tunnel.

When traffic matches a rule that sends it “into” the VPN tunnel, packets are encrypted and carried to the VPN server, and then forwarded onward. Traffic that does not match (or matches a rule to bypass) is sent directly from your device to the internet.

A crucial detail is name resolution (DNS). If your device resolves domain names in a way that doesn’t align with your routing rules, you can end up with partial protection—sometimes called a DNS “visibility” problem. Even when packet routing is correct, DNS handling can affect what portion of your activity remains outside the tunnel.

Comparison: two example setups you can reason about

Below are two realistic patterns. They aren’t endorsements—just concrete examples of how choices affect optimization.

Example A: Route only work apps through the VPN

  • You enable split tunneling so that only your browser instance used for company work, an email client, and a corporate chat app go through the VPN.
  • Personal browsing, OS updates, and streaming remain direct.

What you optimize: potentially better performance for entertainment and less VPN overhead, while still protecting work-related traffic.

Trade-off: personal traffic is outside the VPN, so your risk profile differs between work and leisure.

What could go wrong: if the “work” apps open links that trigger new processes, or if the browser fetches resources from unexpected domains, those requests may not match your intended routing rules.

Example B: Route specific domains (allowlist) through the VPN

  • You define an allowlist for certain domains or IP ranges tied to your organization, such as internal services or specific public endpoints.
  • Everything else bypasses the VPN.

What you optimize: tighter control over what is protected—useful when you want most traffic direct but need select services tunneled.

Trade-off: if a domain changes (CDN aliases, redirected domains, dynamic endpoints), matching can fail. You may think traffic is tunneled but it’s actually going direct.

What could go wrong: redirects, CNAME chains, and third-party resources loaded by a page can create traffic to domains you didn’t explicitly include.

Differences and limits you should plan for

Split tunneling is not a single feature with one universal behavior. The limitations you’re likely to encounter depend on the platform and how rules are implemented.

1) Rule mismatches and unexpected bypass

If a destination, domain, or app doesn’t match your configured rule, the traffic may go direct. This can happen due to:

  • domain redirects
  • dynamically generated endpoints
  • new processes spawned by an app
  • protocols that behave differently than expected

2) DNS and name-resolution inconsistencies

Even if packet routing is “split,” DNS resolution may still leak outside your intended path. For optimization, you want a consistent approach: the component that decides where traffic goes should also handle—or align with—how names are resolved.

3) Local network and special traffic

Some split tunneling setups treat local network access differently, or exclude it from tunneling to preserve device discovery and LAN behavior. This is useful for usability, but it means local traffic may not have the same protection as tunnel traffic.

4) You may reduce protection for bypassed traffic

Split tunneling can improve day-to-day performance, but it reduces the scope of tunnel protections. If your threat model assumes that all traffic is protected, split tunneling may not meet that expectation.

Practical checks to confirm what’s actually happening

Instead of assuming behavior, verify it. Here are non-invasive ways to check whether traffic is being split as intended.

Check 1: Identify what stays on the direct path

Use your browser/app to access a site you expect to be tunneled and another you expect to be direct. Compare observable network outcomes such as:

  • which IP address you reach
  • whether the connection appears to originate from the VPN server versus your ISP path

If your tunneled target shows the VPN’s egress behavior while your direct target does not, that’s a good sign your rules are working.

Check 2: Validate DNS behavior for tunneled versus direct destinations

When you use a domain that should be tunneled, observe whether name resolution and subsequent connections follow the same tunnel path. If DNS resolution results point outside the tunnel path while packets are tunneled (or vice versa), that indicates a mismatch.

Check 3: Test redirects and embedded resources

Open pages that commonly redirect or load third-party resources. Confirm that the final destinations you care about remain routed according to your rules. If parts of the page unexpectedly behave like direct traffic, you may need to broaden your matching criteria.

Check 4: Confirm app-based behavior with new windows and spawned processes

For application-based split tunneling, test with:

  • opening links in new tabs/windows
  • clicking from within apps
  • launching file downloads or embedded viewers If the new activity isn’t routed like the rest of the app, your rule boundaries may be too narrow.

Split tunneling is closely related to two ideas people often mix together:

  • Selective routing (routing policy): the general principle of sending only certain traffic via a chosen path.
  • Threat model alignment: the practice of ensuring your configuration matches what you’re trying to protect.

In optimization terms, the “right” split tuning depends on what you’re optimizing (performance, usability, access to specific services) and what you’re trying to protect (work credentials, sensitive browsing, internal endpoints).