What split tunneling means and how it works

Split tunneling is a VPN setup where only part of your network traffic goes through the VPN tunnel, while the rest continues to use your normal internet connection. Instead of routing everything through the VPN, the client applies rules to decide which traffic is “tunneled” and which is “direct.”

In practice, decisions are often based on one or more of these matchers:

  • App-based selection (traffic generated by specific programs goes through the VPN)
  • Destination-based selection (specific domains, IP ranges, or networks are routed via the VPN)
  • Sometimes protocol or port grouping (less common, but it can occur)

Because the VPN client must map traffic to these rules, split tunneling behavior depends on how well the matchers cover real-world traffic patterns (for example, apps that use multiple domains, CDNs, or dynamic endpoints).

Common problems (and why they happen)

Split tunneling can be useful, but it also introduces failure modes that full-tunnel setups usually avoid.

  1. “Traffic goes where you didn’t expect” (effective routing confusion) If the rule matchers are incomplete, some destinations that you intended to protect may be sent outside the tunnel. Conversely, you may inadvertently route more than intended through the VPN, negating performance benefits.

  2. DNS-related issues A frequent cause of surprising behavior is DNS resolution. Even if traffic to an app is tunneled, inconsistent DNS handling can lead to:

  • Requests being sent to unexpected IPs
  • Domain-to-IP changes not being covered by your tunneling rules
  • Different apps appearing to “work” differently because they rely on different DNS paths

  1. Leaks across boundaries A “leak” in this context means traffic that should have followed the tunnel ends up using the direct path (or vice versa). Leaks are often due to rule gaps (domains/IPs not included), DNS mismatches, or platform-specific routing behavior.

  2. Connection instability or blocked traffic Some VPN clients implement split tunneling by adjusting routing tables and firewall rules. If those rules conflict with the operating system, corporate policies, or other security software, you can see symptoms like:

  • Apps timing out only under certain destinations
  • Intermittent connectivity
  • “Works on Wi‑Fi, fails on mobile hotspot” style differences (environment-specific routing)
  1. Performance outcomes that don’t match expectations Split tunneling can improve performance when most heavy traffic remains local. But if tunneled destinations include bandwidth-heavy services, or if the tunneled path has higher latency, overall performance may degrade.

Differences and limits you should understand

Split tunneling is not automatically a stronger security model—it changes what is protected.

Key limitation: you may only be protecting “the selected part.” If a destination is not included by your split rules, it may not receive the same privacy and risk reduction benefits as tunneled traffic.

Another practical limit is rule coverage: domain-based matching can be brittle when services use:

  • CDNs with frequently changing IP addresses
  • Multiple subdomains
  • Redirects that send the connection to a different hostname
  • Applications that connect to endpoints discovered at runtime

Finally, behavior differs by platform and by how an application establishes connections. Some apps may use embedded network libraries or system proxy settings, which can affect which traffic is classified as tunneled.

Practical checks and troubleshooting steps

You can reduce guesswork by verifying the outcome for the traffic you care about.

  1. Test one app or one destination at a time Choose a single application and one known site/service. Make a change to your split tunneling settings, then retest. Isolating variables helps confirm whether the issue is rule coverage, DNS, or routing.

  2. Check the external IP for both tunneled and direct paths Use a public “what is my IP” check twice:

  • Once while the app/destination should be tunneled
  • Once while the same app/destination should be direct

If both show the same IP, your “split” may not be taking effect as intended. If they differ, you’ve at least confirmed the split is active.

  1. Verify DNS behavior for the same test Because DNS often drives rule matching and destination selection, confirm whether tunneled traffic resolves via the expected DNS path. If your VPN client offers options for DNS handling, ensure they align with your intent (e.g., keeping DNS consistent with the tunneled destinations).

  2. Look for routing or firewall conflicts If connectivity fails only for certain apps or destinations, suspect OS routing rules, firewall rules, or security software interference. A minimal experiment helps: temporarily reduce other network security features (if you can) and observe whether the problem persists.

  3. Review rule matchers for realistic destinations If a service you use is not consistently tunneled, examine whether your rules cover:

  • The service’s full set of hostnames/subdomains
  • Any related APIs or redirect targets
  • The IP ranges if domain matching is unreliable
  1. Confirm redirects and authentication flows Many modern services redirect during login or session setup. A tunneled homepage that later redirects to a different domain can lead to partial tunneling. Test the full workflow, not only the initial page.

When to avoid split tunneling

If your primary goal is consistent protection for all connections, split tunneling may not fit. It can be a poor match when:

  • You need uniform handling for every destination
  • Your apps rely on many dynamically discovered endpoints
  • You can’t reliably validate DNS and routing behavior in your environment

If you choose to use split tunneling anyway, keep your expectations aligned: you’re trading blanket coverage for more control, and correctness depends on maintaining accurate tunnel-selection rules over time.