Windows VPN split tunneling lets you send selected apps through a VPN while other apps continue using your normal internet connection. It can be useful when a work tool needs a VPN route but local services, games, or other software work better without one. The important detail is that “split tunneling” can describe different kinds of routing: a Windows VPN connection may split traffic by destination network, while a third-party client may offer rules for individual applications.
This guide explains how to choose the right method, add and test app rules, and troubleshoot common problems. Exact labels and capabilities vary by VPN client, so use the steps as a practical checklist rather than assuming every Windows client has the same controls. Before changing settings, note your current configuration and keep a way to reconnect if a rule blocks an app you need.
Understand the difference between app rules and network routes
With app-based split tunneling, a client identifies traffic from a selected application and sends it through the VPN or directly over your usual connection. Depending on the client, you may choose “include” mode, where only selected apps use the VPN, or “exclude” mode, where most traffic uses the VPN except the apps you list. The names can differ, so read the description in the client before applying a rule.
Windows also supports destination-based split tunneling for some VPN connection types. That approach routes traffic according to IP networks or address ranges, not simply according to the application that created it. It can be appropriate for connecting to a company network while keeping other destinations on the regular route, but it is not a general substitute for an app-selection control in a consumer VPN client.
Proxy settings are another distinct mechanism. A browser or app that supports a proxy may send its requests to a local proxy endpoint, which then forwards them according to the client’s configuration. An app that ignores the system proxy may connect directly instead. Consequently, setting a Windows proxy does not necessarily route every app, and a VPN client that creates a system-wide tunnel does not necessarily provide per-app rules.
- ✅ Choose app-based rules when the goal is to route specific programs, and your client explicitly supports that feature.
- ✅ Choose destination-based routes when you need to include or exclude defined network ranges.
- ✅ Check whether your chosen mode sends unlisted traffic through the VPN or directly over your normal connection.
- ❌ Assume that changing the Windows proxy automatically controls every desktop app.
- ❌ Treat a “connected” indicator as proof that the selected application is using the intended route.
Before configuring anything, decide which outcome you want. For example, you might want a browser to use the VPN while a local printer utility stays direct, or you might want access to a private work network without routing unrelated destinations through it. Write down the apps and destinations involved; that makes it easier to choose the right mode and spot unintended routing.
Prepare the Windows client before adding rules
Start by confirming that the VPN connection works without split tunneling. Open the client, connect to a route, and test the applications you depend on. If the connection already fails, adding routing rules will make diagnosis harder. Resolve the basic connection first, then enable split tunneling and change one setting at a time.
Look in the client’s settings for terms such as “Split tunneling,” “App rules,” “Per-app routing,” “Bypass apps,” or “Only selected apps.” Read the mode description carefully: an allow-list and a bypass list have opposite effects. Some clients provide separate controls for traffic that uses the VPN and traffic that bypasses it; others expose only one of these choices. If you cannot find an app-routing option, check the client’s current documentation rather than assuming that Windows’ built-in VPN interface provides per-app routing.
Update the client using its normal update mechanism, and make sure the Windows account has permission to change network settings if the client requests it. A VPN may install a network adapter or filtering component that needs elevated permission. Do not disable Windows security features just to make a rule work; if installation or permission prompts look unexpected, verify that the client came from a trusted source.
Make a simple baseline record: which VPN route is selected, whether the client is in system-wide or proxy mode, and which apps currently work. Note whether a firewall, security suite, another proxy, or another VPN client is active. Having multiple tools attempt to manage routes at the same time can make results confusing. Close or disconnect competing proxy and VPN applications while testing.
2
Common rule types: include or exclude apps
3
Checks: rule, route, and app behavior
The figures above describe configuration concepts, not a promise that every client offers the same controls. If a client uses different terminology, map its options to the actual behavior: which traffic enters the tunnel, which stays direct, and what happens when the tunnel is unavailable.
Add app rules and verify the route
Connect the VPN first if your client requires an active session to edit routing rules. Open the split-tunneling panel and choose the mode that matches your plan. In an include mode, add only the apps that should use the VPN. In an exclude mode, add only the apps that should bypass it. Avoid switching modes while leaving an old list in place until you understand whether the client preserves or reinterprets those entries.
Use the client’s app picker when available. If you need to browse for an executable, select the actual program file rather than a shortcut. A shortcut may start a launcher, which then starts a separate application process; the rule may need to cover the program that makes the network connection. For software that updates itself or launches helper processes, test the main app and any required companion components rather than adding a broad folder or unrelated system process.
After saving a rule, follow the client’s instruction to reconnect or restart the app. Some clients apply changes immediately; others need a new VPN session or a fresh application process. Test a specific action that generates network traffic, not merely whether the app window opens. A signed-in page can remain visible from a previous session, for example, even when new requests are not using the route you intended.
Verify the result from more than one angle. Check the VPN client’s traffic or rule status if it provides one, and use a reputable IP-checking service in the selected app’s browser when appropriate. Then compare with a second app that should use the opposite route. The visible country or city reported by an IP database is an estimate, and different services can label the same address differently; focus on whether the route is clearly VPN-based or direct, not on a precise city label.
For a browser test, use a clean session or a new tab and load a fresh page after the rule is active. For an application with a built-in network test, run that test after reconnecting. If the app is already open, fully exit it and start it again so that existing connections do not mislead you. Repeat the check after toggling the VPN off and on, because some clients reapply rules only when the tunnel reconnects.
If your client does not support application rules but you use Windows’ built-in VPN connection, its split-tunnel controls are generally based on destination routes. For example, an administrator may configure which network prefixes go through the VPN; that does not identify traffic by the app that created it. Do not add route commands copied from an unrelated setup. Confirm the connection name, required network ranges, and administrative instructions first, particularly on a managed work device.
When selecting a VPN service or reviewing its Windows setup information, look for a clear explanation of app routing, connection behavior, and supported client modes. The X1VPN home page is one place to review the service’s general platform and connection information; the actual availability of a particular split-tunneling control depends on the Windows client and its current settings.
Troubleshoot apps that ignore or lose their rules
If an app appears to ignore a rule, first confirm that the rule uses the right mode. In include mode, an app omitted from the list may remain direct; in exclude mode, an app omitted from the list may still use the VPN. This simple reversal is a common source of confusion. Read the client’s wording again and test with one clearly identifiable app before changing several entries.
Next, check whether the selected executable is the process that makes the connection. Some programs have a launcher, a background service, and a separate interface process. A rule for the interface alone may not cover network requests made by a helper. Add only the specific related executable that the client identifies or that the software documentation supports. Avoid assigning broad system processes to a route without understanding the effect, because doing so can alter connectivity for unrelated Windows functions.
Consider whether the app is using an existing connection. A browser tab, download, voice session, or background sync task may have opened before the rule changed. Close the app completely, verify it is no longer running in the notification area or background process list, and reopen it. If the client requires a reconnect, disconnect and reconnect the VPN after saving the rule.
If the app loses access only when the VPN is disconnected, the client may be blocking traffic outside the tunnel through a kill switch or leak-protection setting. That behavior can be intentional: it prevents selected traffic from falling back to a direct connection. Review the client’s documentation and choose a safe failure policy. Do not turn off a protection control without understanding whether doing so could expose traffic you meant to keep on the VPN.
DNS and IPv6 can also make route checks appear inconsistent. An app may use a different DNS resolver from the one you expect, or use an IPv6 path that is not handled the same way as IPv4. Check the VPN client’s DNS and IPv6 options, Windows network status, and any warnings in the client log. Avoid interpreting a single lookup result as definitive proof; compare the app’s behavior with the client’s route status and repeat the test using a fresh request.
When a route becomes unreliable, isolate the cause systematically. Temporarily remove the app rule, reconnect, and check whether the app works through the default VPN behavior. Then restore the rule and test again. If the problem appears only with one network, compare Wi-Fi with another trusted connection if available. If all apps fail, investigate the VPN connection or local network before editing individual rules. If only one app fails, review its process, proxy support, firewall permissions, and any network settings it manages itself.
- ✅ Confirm include versus exclude mode before editing the app list.
- ✅ Restart the affected app and reconnect the VPN when the client requires it.
- ✅ Check for helper processes, background services, and existing sessions.
- ✅ Review DNS, IPv6, firewall, and kill-switch behavior if route checks disagree.
- ❌ Run two VPN clients or competing proxy managers while diagnosing a routing issue.
- ❌ Add broad Windows processes to a rule list as a trial-and-error shortcut.
Restore the default setup safely
To undo split tunneling, return to the client’s routing panel and disable the feature or clear the app list, following the client’s own instructions. Check whether the default mode sends all traffic through the VPN, sends traffic directly, or follows another system-wide setting. Do not assume that an empty list means “all traffic through the VPN”; clients can interpret an empty list differently depending on the selected mode.
Save the change, reconnect if prompted, and close and reopen the apps you used for testing. Verify that the VPN status and application behavior now match the intended default. If you configured Windows destination routes for a built-in VPN, remove only the routes you added and only after confirming that they are not required by your organization or another network configuration. On a managed device, ask the administrator before changing work VPN routes.
If you changed Windows proxy settings while experimenting, restore the previous values rather than leaving an unrelated local proxy address configured. Also review startup behavior, firewall exceptions, and any client-specific routing profiles you created. Keep a short note of the working setup so you can restore it later without guessing.
A careful rollback is especially important when the VPN client has a kill switch. If disabling the tunnel leaves selected apps without connectivity, reconnect first and inspect the client’s failure policy instead of repeatedly changing Windows network settings. Once the normal connection is restored, test the browser and the apps you rely on, then keep only the rules that have a clear purpose.
FAQ
Does Windows built-in VPN provide app-by-app split tunneling?
Windows VPN split-tunnel configuration is commonly based on destination routes or network prefixes rather than a simple per-app list. App-by-app routing usually depends on the VPN client or another supported routing feature. Check the documentation for the specific connection type and client you use.
Why does a selected browser still show my normal connection?
Check that the browser is in the correct include or exclude list, that the rule targets the executable actually making requests, and that the browser was restarted after the change. Also confirm whether the client uses an app tunnel, a system proxy, or destination routes; those methods do not behave identically.
Should I use include mode or exclude mode?
Use include mode when only a small, known set of apps should use the VPN and the client supports that behavior. Use exclude mode when most traffic should use the VPN and only specific apps should bypass it. Choose based on the client’s documented failure behavior as well as the list you need to maintain.
Can split tunneling guarantee that an app never connects directly?
No routing option should be treated as a guarantee without testing its behavior and understanding what happens when the tunnel drops. Review the client’s kill-switch and fallback settings, check DNS and IPv6 handling, and verify the selected app after connection changes. For sensitive work, follow your organization’s security policy.