Windows VPN Split Tunneling: Route Apps With Custom Rules

Windows VPN split tunneling lets you choose which apps use a VPN route and which connect through your regular network. It can be useful when a browser should use a selected VPN location while a local printer, work app, or game needs a direct connection. The exact controls depend on the VPN client: some offer app inclusion and exclusion lists, while others provide domain- or IP-based routing rules instead. Before changing anything, identify which mode the client supports and decide what “direct” means in that client. It may mean traffic bypasses the VPN tunnel, not that the connection is protected by another service.

This guide explains how to set up app-based routing, verify the result, and undo a rule if it causes trouble. Client menus and feature names can differ by version, so treat the steps as a method rather than a promise that every Windows client has the same buttons. If you use the official app, start with its own routing controls. Compatible clients such as Clash Verge or sing-box may use different rule models and may not offer the same app-level controls as a VPN’s official client.

Understand app-based split tunneling

Split tunneling divides traffic according to a rule instead of sending every connection through the same route. In app-based routing, the rule is associated with a program, such as a browser or a desktop chat client. In destination-based routing, it is associated with a domain, IP address, or network range. These are different approaches: a browser might use the VPN for one destination and connect directly to another, while an app-based rule may send all of that program’s traffic through one route.

Clients commonly present one of two app-level modes:

• Route only selected apps through the VPN: Apps on the inclusion list use the VPN; other apps generally use the ordinary network connection.
• Exclude selected apps from the VPN: The default is to route apps through the VPN, while apps on the exclusion list generally connect directly.

Those descriptions explain the intended policy, not every detail of how a client implements it. Some clients apply rules to a process, some to a Windows application package, and some to traffic captured by a local proxy. A service running in the background, a helper process, or a child process may not follow the same rule as the visible app. If a client uses proxy settings rather than a system-wide tunnel, a program that ignores those settings may not be routed by the rule at all.

App rules also do not automatically determine how every name lookup is handled. DNS may be sent through the VPN, handled by the client, or resolved using a setting in Windows or the app itself. A browser’s Secure DNS setting can use a separate resolver path. If your goal is to control both app traffic and name lookups, check the client’s DNS options and test them separately.

Choose a rule mode and plan the change

Start with a short list of apps and the route each one needs. Keep the first test simple: choose one app, one route, and one result you can verify. Avoid adding several unrelated exclusions at once. If the outcome changes unexpectedly, a single change is much easier to trace than a collection of edits.

• ✅ Use an inclusion list when only a few apps should use the VPN and the rest should stay on the ordinary connection.
• ✅ Use an exclusion list when most apps should use the VPN but a specific local or work app needs a direct route.
• ✅ Check whether the app launches helper processes or uses a separate background service.
• ✅ Record the current mode and rules before editing, so you can restore them if needed.
• ❌ Don’t assume that adding a browser executable covers every browser profile, updater, or helper process.

Consider the consequences of a direct route before excluding an app. Its traffic may use the network connection provided by your internet provider, office, or public Wi-Fi. If the app handles sensitive information, make sure that direct access is appropriate for your network and privacy requirements. A VPN exclusion is a routing choice; it is not an additional encryption layer.

Also review the client’s kill switch or network-lock setting. Depending on the implementation, it may block all non-VPN traffic, including traffic from excluded apps. In another client, exclusions may be allowed while the kill switch is active. Do not assume either behavior: check the client’s documentation or test with non-sensitive traffic. A conflict between the two settings can look like a broken app rule even when the rule itself is correct.

For an initial baseline, note which network is active, whether the VPN is connected, and how the selected app behaves before you edit the rule. Then connect to the VPN and repeat the same check after changing only one setting. This gives you a meaningful comparison without relying on memory or changing the network at the same time.

Configure app rules in a Windows VPN client

In the client, look for a setting named Split tunneling, App routing, Per-app settings, or a similar term. Read the mode description before adding an app: in an inclusion mode, adding an app means “send this app through the VPN”; in an exclusion mode, it means “let this app bypass the VPN.” Confusing these two meanings is a common reason a rule appears to do the opposite of what you intended.

1. Connect to the route you intend to use, or follow the client’s instructions if it requires the VPN to be disconnected while editing.
2. Open the app-routing controls and select the intended mode: selected apps through the VPN, or selected apps outside it.
3. Add the target app using the client’s app picker when available. If it asks for a program file, verify that you selected the actual executable rather than an installer, shortcut, or updater.
4. Save or apply the rule. If the client requests a reconnect or app restart, do that before testing.
5. Close and reopen the target app, then test a specific action that creates a fresh network connection.

For a conventional desktop program, the executable may be inside its installation folder. Avoid guessing a path based on the Start menu shortcut: a shortcut is not necessarily the process the client needs to identify. When there are several similarly named files, use Windows Task Manager to confirm the process name while the app is running, then match it to the client’s picker or instructions. Do not add unknown system processes simply because their names look related.

Store apps and packaged applications can be more complicated. Windows may identify them by package rather than by a familiar executable path, and a client’s app picker may or may not support that form. Some applications also delegate network activity to a shared Windows service. If the app cannot be selected or the rule has no visible effect, check the VPN client’s support information for packaged-app and service limitations instead of adding broad system processes at random.

Windows also has a built-in VPN setting called split tunneling for some Windows VPN connections. It changes whether traffic is routed through that particular Windows VPN connection by default; it is not a universal per-app control for every third-party VPN client. PowerShell commands such as Get-VpnConnection and Get-NetRoute can help inspect Windows VPN or route configuration, but their output does not by itself prove how a third-party client handles each app. Avoid editing route tables or running commands from an unfamiliar guide unless you understand how to reverse the change.

Third-party proxy clients may offer a different model. For example, a rule-based client can decide how to handle traffic based on destinations or other supported rule inputs rather than simply assigning all traffic from one Windows app to a route. Read the client’s own documentation and confirm whether it captures system traffic, requires an app-specific proxy setting, or uses a local proxy. Do not copy rules between clients on the assumption that their rule engines behave identically.

Verify the rule with the app, IP, and DNS

A “Connected” status tells you that the client reports an active connection; it does not confirm that a particular app followed the route you intended. Test from the app itself and compare the result with a known baseline. Use the same computer and network for both checks, and avoid changing browser proxy extensions, DNS settings, or other VPN software during the test.

• Test an app expected to use the VPN: Open an IP lookup page in that app and note the reported public IP and approximate region. Compare it with the result when the VPN is disconnected. A changed result supports the conclusion that this request used a different exit, but it does not establish how every app is routed.
• Test an app expected to bypass the VPN: Repeat the same check inside the excluded app. If the client permits direct access, its request may use the public exit associated with your ordinary connection. An unchanged result is not conclusive by itself if the lookup service or network has not changed.
• Check the app’s actual task: Some services behave differently from an IP lookup page. Test the website, work resource, game service, or other destination you need, and confirm that the app remains functional after it opens a fresh connection.
• Check DNS separately: Use a DNS test page in the same browser and compare results before and after the rule change. Browser Secure DNS and client DNS controls may affect the result, so interpret the displayed resolver together with the app’s exit IP and the client’s DNS settings.

Use fresh connections when testing. A browser tab or app may reuse an existing connection, keep a cached DNS answer, or stay signed in through a session that was established before the rule changed. Fully close and reopen the app when appropriate, then repeat the check. If Windows has switched between Wi-Fi and Ethernet, or a proxy setting changed, return to a consistent network before drawing a conclusion.

Windows routing tools can provide additional context. ipconfig shows network adapter configuration, while route print displays route-table information. These commands are useful for spotting obvious interface or route changes, but they may not show the full policy used by a VPN client that filters or redirects traffic internally. Treat them as diagnostic evidence, not a substitute for testing the target app. If you share diagnostic output with support, remove public IPs, device names, usernames, and other information you do not want to disclose.

Troubleshoot or restore the default setup

If the rule does not work, first confirm its direction. Check whether the client is in inclusion or exclusion mode, whether the intended app appears in the right list, and whether the rule was saved. Then restart the app and, if required, reconnect the VPN. A rule may not affect connections that were already open when you edited it.

If only part of an app behaves differently, check for helper processes, a separate updater, a background service, or an embedded browser component. Also check whether the app has its own proxy configuration. A system proxy, a browser extension, or a second network tool can alter the path independently of the VPN rule. Disable competing proxy tools only when you know how to restore their settings, and change one item at a time.

If an excluded app cannot connect, review the kill switch and network-lock options, the app’s own proxy settings, and any local network policy. If an app expected to use the VPN appears to connect directly, confirm that the client captures that app’s traffic and that its rule applies to the running process. Do not solve uncertainty by excluding broad Windows components: that can affect traffic beyond the app you meant to change.

To restore the usual default, remove the test rule or return the client to its prior mode, then reconnect if the client asks. If you no longer know the original state, turn off split tunneling or use the client’s documented default/reset control. Restart the affected app and verify the result again. Avoid deleting Windows routes or resetting network adapters as a first response; those changes can disrupt other connections and may require separate recovery steps.

For a guided setup of the VPN client, see the quick-start guide. If the client’s controls or connection behavior remain unclear, check its help information before making system-level changes.

Frequently asked questions

Can I route only one Windows app through the VPN?

Yes, if your VPN client supports an inclusion list or an equivalent app-specific rule. Select the intended mode, add the app through the client’s supported picker, and test it from inside that app. Some clients route traffic by process, while others rely on a proxy or destination rules, so support can vary for packaged apps and background services.

Does an excluded app become unprotected?

An excluded app may use the ordinary network connection instead of the VPN route. That does not necessarily mean its traffic is unencrypted at the application level, but it does mean you should not assume the VPN is protecting that connection. Check the app’s own security and the network you are using before allowing direct access.

Why does my rule seem to affect only part of an app?

The app may use more than one process, a background service, or a helper program for network requests. Existing connections and cached lookups can also make a new rule appear inconsistent. Restart the app, confirm the process or package the client supports, and test a fresh connection before changing additional rules.

How do I undo split tunneling?

Remove the test rules or restore the mode you recorded before editing. If you did not record it, turn off split tunneling or use the VPN client’s documented reset/default option, then reconnect if requested. Verify the target app’s route afterward rather than assuming that a setting change took effect immediately.