Split tunneling is a routing choice. Instead of sending every eligible connection through one VPN path, a device directs some traffic through the tunnel and some through another route. That can be useful for a clearly defined compatibility need, but it also creates exceptions you need to understand.
The feature is easiest to evaluate when you stop thinking of it as a speed button. Its real purpose is selective routing. Before enabling it, identify the application or destination that needs a different path, why the exception is necessary, and which information can leave outside the tunnel. The right configuration is the smallest understandable change that meets your requirement.
Start with the full-tunnel baseline
In a typical full-tunnel configuration, eligible internet traffic is directed through the VPN rather than taking the ordinary default route. This does not mean every possible communication is automatically covered in every operating system. Platform behavior, local-network exceptions, and the implementation still matter.
Split tunneling changes that arrangement by design. It creates more than one intended path. A successful direct connection from an excluded application may therefore be exactly what the configuration asked for, not evidence that the VPN unexpectedly failed.
Microsoft's VPN routing documentation describes the distinction between split and force tunneling in Windows. Consumer applications may present different controls, so use that explanation for the routing concept and your provider's documentation for the exact interface you will operate.
Distinguish include rules from exclude rules
An include-based setup identifies the traffic that should use the VPN. Everything else follows the applicable non-VPN routes. An exclude-based setup starts with broader VPN coverage and identifies the traffic that should bypass it. The labels vary between products, but the difference changes what happens to an application you have not explicitly listed.
Consider installing a new browser after configuring the feature. In an include-only arrangement, that browser may not use the tunnel until added. In an exclude arrangement, it may follow the general VPN route unless excluded. The important question is the default behavior for new or unlisted traffic.
Write the rule in a complete sentence rather than copying a label. “Only this app uses the tunnel” and “all eligible apps except this one use the tunnel” are different policies. Confirm which sentence matches the actual setting before continuing.
Identify whether the control is app-based or route-based
Some clients let you select applications. Other configurations identify destination addresses or networks. A work connection may route internal resources through an organizational gateway while leaving unrelated internet traffic elsewhere. These approaches can look similar in a diagram but require different checks.
App-based rules can become confusing when a program launches helper processes or uses another application to open a link. Route-based rules require attention to the destinations they cover. Do not assume that a friendly product name corresponds to one executable or that a website has one permanent address.
For a personal setup, prefer the provider's supported interface and documented scope. Avoid improvising firewall or routing changes alongside it unless you understand how the controls interact. For a work-managed setup, the administrator's intended routing policy is the starting point, not a consumer tutorial.
Name the reason for each exception
A local printer, a specific application compatibility problem, or a required organizational route can motivate a limited exception. The important step is to connect the exception to an actual need. Do not exclude a whole group of applications merely because a troubleshooting suggestion once mentioned split tunneling.
Keep a small inventory containing the application or route, the reason, and the date you last checked it. You do not need a complex tracking system. A short note is enough to distinguish a deliberate rule from an old experiment that remained enabled after the problem disappeared.
Our VPN essentials hub provides the surrounding terminology. When your only goal is better performance, first read the slow VPN troubleshooting guide so that you do not reduce tunnel coverage to compensate for a problem elsewhere.
Think through the privacy tradeoff
Traffic deliberately sent outside the tunnel does not receive that tunnel's protection. Its destinations may see the ordinary public address associated with the direct route rather than a VPN exit address. Other protections, including correctly implemented HTTPS, can still apply. “Outside the VPN” and “completely unencrypted” are not synonyms.
The key is whether the changed visibility is acceptable for the particular task. If your requirement is that an application use the tunnel, excluding it contradicts that requirement even when doing so makes it work. A functional application and an appropriate privacy route are separate success criteria.
Avoid making the exception broader than necessary. After an initial test, ask whether the rule can be narrowed or removed. A configuration with fewer unexplained paths is easier to maintain and less likely to surprise you when your habits or software change.
Check name resolution separately
DNS translates names into addresses. Its route may be influenced by the operating system, the VPN client, browser settings, or an application's own resolver. Do not infer the path of every DNS query merely from the path used by the application's other traffic.
This matters when troubleshooting split routing. A website might load through the intended route while its name resolution follows a different configured policy. Alternatively, a resolver choice could be deliberate and documented. The correct interpretation depends on the expected setup, not simply on seeing an unfamiliar resolver name in a test.
Use the DNS leak guide to define what you are checking. Record both the intended application route and the intended DNS behavior. Keeping those questions separate helps prevent an apparent fix in one area from hiding a mismatch in the other.
Review the interaction with traffic blocking
A kill switch and split tunneling can have product-specific interactions. Some combinations may be unavailable, while others may treat protected and excluded traffic differently. Do not assume the kill switch silently overrides every exception or that an excluded application always remains connected after a tunnel failure.
Read the documentation for your exact app and operating system. Then write the expected outcome for both an included and an excluded application. The kill-switch explainer shows why manual disconnect, unexpected interruption, and startup can be different scenarios.
Keep tests modest and non-sensitive. Save work and follow a supported method. A test that only checks one browser cannot demonstrate the behavior of every process on the device, so describe observations narrowly and leave untested cases marked as unknown.
Make one change, then observe
Begin with a working baseline. Add one intended exception, restart the relevant application if the provider requires it, and repeat the task that motivated the change. Confirm that the application behaves as expected and that another application still follows its intended route.
If the change does not help, remove it before trying a different approach. Accumulating exceptions makes later diagnosis difficult because each new test begins from an increasingly unclear configuration. Record the outcome, including whether the original compatibility problem actually changed.
Repeat relevant checks after major app updates, operating-system changes, or replacement of an application covered by a rule. Revisit exceptions you no longer recognize. Maintenance is part of selective routing because the list of applications and destinations is not necessarily static.
The takeaway: clarity is the feature
Split tunneling can be useful when it solves a specific routing requirement and its tradeoff is acceptable. Define the default route, identify each exception, check DNS and kill-switch interactions, and keep a rollback path. Do not use it as a vague promise of better privacy or performance. A good configuration is one you can explain application by application, including what happens when the tunnel is unavailable. Explore the guides library for the next part of your setup rather than adding more exceptions by habit.
