What split tunneling means in practical terms

Split tunneling is a VPN configuration where not all network traffic is routed through the VPN tunnel. Instead, you specify which traffic should use the VPN and which traffic should go directly to the internet from your device.

A common goal is to keep VPN protection for sensitive traffic (for example, access to particular services or internal resources) while letting other traffic—such as streaming, downloads, or local network discovery—use your normal connection.

In everyday terms, split tunneling turns the VPN from a full “all-traffic gateway” into a selective tunnel.

How it works: the decision points

Most split tunneling behavior comes down to where the “selection” happens. That selection is usually determined by one or more of these inputs:

  • Application-based selection: The VPN client routes traffic for specific apps through the tunnel.
  • Destination-based selection: The VPN routes traffic to specific IP ranges, domains, or categories of destinations through the tunnel.
  • DNS-based selection: Domain names are resolved in a way that matches your split rules, so the resulting connections follow the intended path.

Under the hood, the VPN client and your operating system cooperate to steer traffic. When traffic matches the include rules, it is sent into the VPN tunnel; when it does not match, it uses the system’s normal network path.

Key differences you should understand before relying on it

Even though split tunneling is conceptually simple, the real differences show up in the “boundaries” of the rules.

App rules vs. destination rules

  • App-based rules can miss traffic that apps trigger indirectly, such as browser helper processes or background services.
  • Destination-based rules can be more precise for networks you care about, but may not cover all variants if IPs change (for services that use dynamic addressing).

Domain and DNS behavior

Split tunneling often depends on DNS outcomes. If DNS resolution is not aligned with your split rules, some connections may not go where you expect.

IPv6 and local network traffic

Many users focus on IPv4, but systems can also use IPv6. If the VPN client and OS handle IPv6 differently from IPv4, you may see traffic that bypasses or partially follows split rules.

Also decide whether local network access (printers, NAS devices, or internal LAN services) should remain direct. Some split configurations intentionally leave local/LAN traffic outside the VPN.

Limitations and edge cases (what can go wrong)

Split tunneling trades “simplicity” for “control,” and that control comes with limitations.

1) Misconfiguration can create unintended bypass

If the include/exclude rules are too broad or incorrectly specified, traffic you intended to protect may go directly.

2) Unexpected traffic paths

Some activities use multiple components (app processes, system services, CDNs). Even if the main app is selected, not all sub-connections may follow the same route.

3) DNS and caching can confuse verification

If your device caches DNS results, changing split tunneling rules may not take immediate effect for every domain until cache expires or is flushed.

4) IPv6 behavior may differ

If split tunneling rules primarily target IPv4 destinations, IPv6 connections might still follow a different path.

Because of these edge cases, split tunneling should be treated as something you verify, not something you assume.

Practical checks to confirm your traffic is split as expected

You can validate split tunneling behavior with a repeatable, low-effort approach.

Check 1: Confirm DNS resolution path

Pick a domain that you expect to route through the VPN. Then:

  • Resolve the domain while split tunneling is enabled.
  • Re-check after you change rules or restart the affected app/browser.

If you see DNS responses that do not match your expectations, you may need to adjust DNS-related settings or ensure the client applies rules consistently.

Check 2: Compare public IPs for different activities

Split tunneling should produce different “external” paths for different destinations.

  • Use a “what is my IP” check from traffic that should be through the VPN.
  • Then repeat for traffic that should be bypassed.

If both show the same external IP, your exclusions may not be working, or the VPN client may still route more traffic than you intended.

Check 3: Use connection/route inspection

On many devices, you can inspect active network connections and see which interface or gateway they use. Confirm that:

  • Connections to included destinations use the VPN tunnel.
  • Connections to excluded destinations do not.

This is especially helpful for catching edge cases like background connections.

Check 4: Test with both IPv4 and IPv6 targets

If your environment uses IPv6, test a reachable IPv6 address or domain. You’re looking for consistency: included destinations should reliably use the VPN path across address families.

Choosing split tunneling rules: a clear way to think about it

When setting split tunneling, start with your intent:

  • If the priority is protecting access to specific services, use destination/domain rules for those services.
  • If the priority is containing risk to certain apps, use app-based rules, but still verify behavior for background and helper components.
  • If the priority is keeping local connectivity, explicitly exclude local subnets/LAN-type destinations.

After setting rules, always verify with targeted tests rather than relying on what the interface claims. Configuration details vary across VPN clients and operating systems, so behavior can differ.

A full-tunnel VPN routes all traffic through the tunnel. Split tunneling routes only selected traffic through the tunnel.

If your main concern is minimizing the chance of accidental bypass, full-tunnel behavior is usually the simpler baseline. If your main concern is performance or local access while still protecting specific destinations, split tunneling is a good fit—provided you verify it works as intended for your specific network and address families.

Because implementations vary, the most reliable approach is to combine the configuration you want with the practical checks above.