Windows VPN Split Tunneling: Route Apps With This Setup Guide

Windows VPN split tunneling lets you decide which traffic enters the VPN tunnel and which uses your ordinary internet connection. With app-based routing, for example, a browser can use the VPN while a video-call app connects directly. The important distinction is that not every feature called “split tunneling” works the same way: some clients select traffic by application, while Windows’ built-in VPN options primarily route by destination network. Choosing the right method—and checking the actual path afterward—prevents a common surprise: a rule that appears enabled but does not affect the traffic you meant to control.

This guide explains how to plan app-based routing, configure it in a compatible Windows client, and verify the result. It also covers Windows’ native route-based option, which can be useful when you need to send traffic for particular networks through a VPN. Menu names differ between clients and versions, so use the steps as a decision process rather than expecting every client to have an identical screen.

How Windows split tunneling works

A VPN client creates a tunnel and changes how some or all traffic leaves your computer. Split tunneling adds a selection rule: matching traffic follows the tunnel, while other traffic follows a different path. The result depends on how the client identifies that traffic. It may match an application executable, a destination IP range, a domain name, or a combination of rules. A rule only helps if it matches the traffic as the client actually sees it.

For app-based routing, a client generally offers one of two policies. An inclusion policy sends only selected applications through the VPN, leaving other applications outside it. An exclusion policy sends applications through the VPN by default, except those specifically allowed to connect directly. Inclusion can be easier to reason about when only a few programs need the tunnel. Exclusion can suit a workflow where most traffic should remain protected, but a few local or bandwidth-sensitive programs should bypass it. Check the client’s wording carefully: “bypass,” “exclude,” and “route selected apps” can describe different defaults.

Windows’ built-in VPN configuration is different. Its split-tunnel setting allows routes to determine which destination networks use the VPN connection. That can be useful for a work network or a known private subnet, but it does not by itself provide a simple list of desktop applications to include or exclude. Per-app behavior usually depends on the VPN client’s own routing implementation, or on a more advanced Windows networking setup. Do not assume that turning on a native split-tunnel option means Windows will offer an app picker.

Another distinction is whether the client tunnels traffic at the network layer or routes selected applications through a local proxy. A network-level client may use a virtual adapter and system routing rules. A proxy-based setup may require an application to support proxy settings, or may depend on the client redirecting that application’s traffic. This affects DNS handling, applications that launch helper processes, and programs that do not use standard Windows networking APIs. A configuration that works for one browser is not proof that every application will follow the same rule.

Plan the routing policy before changing settings

Write down what should use the VPN and what should connect directly before opening the client. Include the application’s exact purpose, whether it launches helper processes, and whether it needs to reach devices on your local network. For example, you may want a browser to use the VPN while a printer utility, local file-sharing app, or meeting tool connects directly. These are examples, not universal recommendations: a work or school policy may require all relevant traffic to use an approved connection.

Choose an inclusion or exclusion policy based on the number of exceptions and the consequence of a missed rule. With inclusion, an unlisted application typically remains outside the tunnel; this can be clearer when only a small set of apps needs VPN routing. With exclusion, unlisted applications may use the tunnel by default, but an incorrectly selected exception can send traffic directly. Read the client’s description and test its behavior rather than inferring the default from the label alone.

• ✅ Record the application’s executable name and install location before adding a rule.
• ✅ Decide whether the rule should include selected apps or exclude selected apps from the tunnel.
• ✅ Check whether local printers, file servers, casting devices, or other LAN resources must remain reachable.
• ✅ Keep work, school, and managed-device policies in mind before bypassing their required VPN route.
• ❌ Do not assume a rule for a launcher automatically covers the application it starts.
• ❌ Avoid enabling multiple VPN or proxy clients at once while testing; they can compete for routes.

Application identity deserves particular attention. A desktop program may use one executable for its main window and separate processes for updates, media playback, or authentication. A browser may also use child processes. If the client matches only the executable you selected, related traffic might not follow the same route. When a client offers a process-based rule, identify which process generates the connection you are testing. If it offers domain or destination rules instead, consider that a program can contact multiple services rather than a single host.

Finally, save the current configuration or note the settings you plan to change. Start with one routing policy and a small number of applications. A short, reversible test is easier to diagnose than a large rule set with several overlapping exceptions.

Configure app-based routing in a VPN client

The exact controls depend on the Windows client and its version. Look in settings sections named Split tunneling, App routing, Per-app VPN, Bypass list, or similar. Some clients show the feature only after a connection profile has been selected; others place it under advanced network settings. If you cannot find an app list, check the client’s own documentation or help panel before changing Windows routes. The feature may be unavailable in that client, or it may use destination rules rather than executable rules.

1. Update and inspect the client. Use the client’s supported release and check whether it offers application-based routing on Windows. If the client was imported from a subscription, confirm that you are editing the active profile rather than an unused configuration.
2. Disconnect before editing if the client requires it. Some clients apply routing changes immediately; others require a reconnect. Follow the prompt, and avoid changing rules while another VPN client is active.
3. Select the policy mode. Choose whether listed applications use the tunnel or bypass it. Read the explanatory text beside the control, because the client’s default mode determines what happens to every application not listed.
4. Add the application. Select it from the client’s application picker where possible. If you browse for an executable, choose the actual program file rather than a shortcut, installer, or launcher unless the client specifically directs you to select the launcher.
5. Apply the change and reconnect if needed. Confirm that the client reports the rule as active. If the application was already open, close it fully and start it again so that new connections are created under the changed policy.
6. Test one application at a time. Keep the VPN connected, check the selected application, and then check an application that should follow the opposite route. This helps reveal a reversed policy or an overly broad rule.

When you use a third-party client such as a compatible Clash Verge or sing-box setup, routing may be expressed through rules, outbound groups, or process matching instead of a graphical app list. A rule can match a process name, a domain, an IP range, or another attribute, and the first matching rule may determine the route. Confirm rule order, the selected outbound, and the client’s final mode. A subscription import may refresh node and group configuration without preserving every local rule, so review the active configuration after an update rather than assuming your routing preferences were retained.

Do not copy a configuration snippet from a different client without checking its syntax and supported features. The same routing idea can have different field names or behavior across clients. Also distinguish a routing rule from a protocol choice: Shadowsocks, VMess, Trojan, Hysteria2, and WireGuard describe connection methods or implementations, not a guarantee that a specific Windows application will be included or excluded. The application-routing control and the chosen outbound need to work together.

When to use Windows’ native VPN routes

If you use a Windows VPN connection configured through the operating system and need to route particular destination networks, Windows provides a route-oriented approach. This is not an app picker. The general process is to enable split tunneling for the VPN connection and add the destination network prefixes that should use that connection. Exact availability can depend on the VPN type, connection setup, Windows edition, and whether the connection is managed by an organization.

For an administrator-managed or personally configured Windows VPN, PowerShell can expose connection settings. The following commands are illustrative: replace the example connection name and network prefix with values supplied by your network administrator or VPN documentation. Run elevated commands only when you understand the effect, and do not add guessed routes to a work connection.

Get-VpnConnection
Set-VpnConnection -Name "Your VPN connection" -SplitTunneling $true
Add-VpnConnectionRoute -ConnectionName "Your VPN connection" -DestinationPrefix "10.20.0.0/16"

In this example, the destination prefix represents a private network range, not an application. The VPN server and connection type must support the intended route, and the destination prefix must match the network you are trying to reach. A route that is too broad can send more traffic through the VPN than intended; one that is too narrow may leave required destinations unreachable. Check the connection’s existing configuration before making changes, and use the corresponding Windows command help or your administrator’s instructions to confirm parameters for your environment.

Native routing and client-level app rules can also interact. A VPN client may install routes or filters of its own, and a second client can alter the routing table or DNS behavior. If you are troubleshooting, test one routing mechanism at a time. Remove or disable a temporary rule only after noting its original value, and restore the configuration if the test does not produce the expected result.

Verify the route and troubleshoot failures

Verification should check both the application and the route it actually uses. Start with the VPN connected. Open the application that should use the tunnel and visit a reputable IP-checking page or use your provider’s IP lookup tool. Then repeat with an application that should connect directly. Compare the observed public egress with the expected policy; do not rely only on a green “connected” indicator in the VPN client. You can also test access to the specific private resource if your rule targets a private network.

For a simple check, use the site’s IP lookup page in the application you are testing. A browser check confirms that browser traffic’s apparent public egress, but it does not prove that a separate desktop application follows the same path. For that application, use its own network-dependent function, logs, or a destination you are authorized to test. Avoid publishing screenshots that expose account details, internal addresses, or subscription information.

If the result is wrong, diagnose in a consistent order:

• Confirm the active mode. Check whether the client uses an inclusion or exclusion policy and whether the selected application is on the intended list.
• Confirm the target. Verify the executable path or process name. If the application starts helper processes, test whether those processes need separate rules.
• Confirm the active profile and connection. Make sure the rule belongs to the profile currently connected, and reconnect if the client requires it to apply changes.
• Check for competing network software. Temporarily disable other VPNs, system-wide proxies, or traffic filters, then repeat the test with only one active routing setup.
• Check DNS separately. Name resolution can follow a different path from the application’s main connection. A site loading successfully does not necessarily show which DNS resolver was used.
• Check local-network and firewall behavior. A VPN kill switch, Windows Firewall rule, endpoint security product, or local-network block can prevent a direct connection even when the routing rule is correct.
• Review updates and rule order. Client updates, subscription refreshes, or broad rules may change which outbound is selected. Inspect the current configuration rather than relying on an old screenshot.

When a selected app cannot connect after being excluded from the tunnel, the problem may be the direct network path, not the VPN server. When an included app still appears to connect directly, verify that you selected the process making the request and that no higher-priority rule sends the traffic elsewhere. If the app uses a proxy setting of its own, it may not follow the system route in the way you expect.

Frequently asked questions

Does Windows have a built-in app-by-app VPN switch?

Windows’ standard VPN split-tunnel controls are primarily route-based: they select destination networks, rather than offering a universal desktop-app list. App-based routing is commonly provided by the VPN client or by a more specialized configuration. Check the feature set of the client and the VPN type you are using.

Why does my browser use the VPN but another app does not?

The browser may be the only executable covered by the rule, while the other application uses a separate process or its own proxy configuration. Some clients also support only particular routing methods. Confirm the actual process, active profile, and rule mode, then test each application separately.

Can split tunneling keep printers and local devices accessible?

Often, but it depends on the client’s local-network option, route configuration, firewall, and the way the device is discovered. Check whether the VPN has a setting such as “allow LAN access,” and test the specific printer or device after changing one setting at a time. Managed networks may impose different requirements.

Will a subscription update preserve my routing rules?

It depends on the client and how it stores local settings. Some clients keep local routing preferences separately; others regenerate or replace configuration during an update. After refreshing a subscription, inspect the active profile and verify the app routes again. Keep a private note of custom rules so you can restore them if needed.