Split tunneling is widely written up as a risky feature. That framing is slightly off, and the correction matters.
The mechanism does exactly what it says. It sends the traffic you nominated through the tunnel and lets the rest out normally. There is no bug here and nothing hidden.
The risk is the list, and the list was written by someone who does not know everything their machine talks to.
Why the list is always incomplete
Open a network monitor on a quiet laptop and count the destinations. Updaters checking versions. Telemetry. Sync clients. Font services, time services, certificate checks. Helper processes started by applications you did have in mind.
None of these are on anybody's list, because the list is written by thinking about what you do, and these are things your machine does.
They are also, individually, uninteresting. Collectively they are a schedule: when the machine is awake, where it is, which software it runs, how that changes over weeks.
Two routes exist and the sign says who takes which. The arrangement works precisely as designed, and whether it protects anything depends entirely on whether the right things were sent down the right lane, which is a decision made long before anyone arrives.
The two implementations fail differently
Application-based rules protect the programs you named. They break when an application hands work to a helper process or a system service, because the helper is not the program on your list. Your browser is protected; the thing it spawned to fetch an update is not.
Route-based rules protect destinations, by address range. They break when a service changes its ranges, which happens regularly and without announcement. Your rule still matches what it always matched, and the service moved.
Neither is safer in the abstract. The useful question is which failure you would notice, and the honest answer for most people is neither, because both fail silently.
What to actually check
Look at connections, not at your settings screen.
Every platform can list active network connections and show which are bound to the tunnel interface. That output is the measurement. Your settings screen is the claim.
The result almost always contains something you did not expect, and that surprise is the whole value of the exercise. It is a few minutes of work and it tells you about your machine rather than about the vendor's description of the feature.
Sorting at this speed only works if the rule was right when it was written. Nobody is inspecting individual pieces, and nothing on the line will tell you the rule has drifted; the output simply stops matching what you intended, quietly, for as long as it takes someone to look.
When split tunneling is the right call
When the alternative is not using the VPN at all. A tunnel you switch off because your bank app breaks protects nothing. A tunnel with two deliberate exceptions protects everything else, every day.
That trade is usually worth making. It is worth making with the list open in front of you, rather than by adding an exception at the moment something breaks and never revisiting it.
The honest limits
Anything you excluded carries your real address. That is the feature, not a defect, and it means the excluded set should be short enough to hold in your head.
And it does not interact well with a kill switch. When the tunnel drops, the switch blocks the protected traffic and the excluded traffic keeps flowing, because it was never going through the tunnel in the first place. Both features are working correctly, and the result is not what most people picture when they enable them together.
Frequently asked questions
- What is split tunneling and why would I use it?
- It sends some of your traffic through the VPN and lets the rest go out normally. People enable it for good reasons: a banking app that refuses foreign addresses, a printer on the local network, a video call that suffers from the extra hop, or a large download that would otherwise saturate the tunnel. The feature is legitimate and often the difference between using a VPN daily and abandoning it.
- What are the actual risks of split tunneling?
- The risk is not the mechanism, it is the list. You decide in advance which applications deserve protection, and that decision is made by someone who does not know everything their machine contacts. Background updaters, telemetry, sync clients and helper processes rarely appear on anyone's list, and they are exactly what reveals a pattern of activity over time. What escapes is not what you thought about, it is what you did not think about.
- Does split tunneling leak my IP address?
- For any traffic you excluded, yes, by design: that traffic uses your ordinary connection and carries your real address. That is what the feature does rather than a fault in it. The problem arises when the excluded set is larger or different from what you believe, which is common when the rule is written per application rather than per destination.
- Is app-based or route-based split tunneling safer?
- They fail differently. App-based rules break when an application delegates work to a helper process or a system service, because the helper is not the application you listed. Route-based rules break when a service changes its address ranges, which happens without notice. Neither is safe in the abstract, and the practical question is which failure you are more likely to notice.
- How do I check what is actually going outside the tunnel?
- Look at connections rather than at your settings screen. On any platform you can list active network connections and see which are bound to the tunnel interface and which are not, and the result usually contains something you did not expect. That check takes a few minutes and is worth more than any comparison of implementations, because it measures your machine rather than the vendor's description of the feature.
Store your files privately → pCloud
Swiss privacy · 10 GB free · optional zero-knowledge Crypto
