Windows Split Tunneling Guide: Set App Rules in 2026

Windows split tunneling lets you decide which applications use a VPN tunnel and which applications continue through the ordinary network connection. This is useful when one program needs a remote region, private route, or protected connection while another depends on a local service, nearby device, corporate network, or lower-overhead direct path. The important detail is that split tunneling is an application-routing policy, not simply a switch that makes the VPN “faster.”

In 2026, Windows VPN clients may implement split tunneling in different ways. Some offer an allowlist for apps that must use the tunnel, while others provide an exclusion list for apps that should bypass it. A few clients expose domain, process, or route rules in addition to application rules. The names of the controls vary, but the troubleshooting principles remain similar: decide the traffic policy first, add rules carefully, verify the effective route, and test DNS as well as the visible IP address.

What Windows split tunneling actually controls

A full-tunnel VPN normally changes the default route so that most system traffic enters the encrypted interface. This is simple to understand: browsers, launchers, update tools, messaging apps, and background services generally follow the same tunnel unless the client or operating system has a more specific route. With split tunneling, the client creates exceptions or application-specific decisions. The result is that two applications running at the same time can use different network paths.

There are two common policy models. An include mode, sometimes called an allowlist mode, sends only selected applications through the VPN. Everything else uses the direct connection. This is usually the safer starting point when only one or two programs need the tunnel. An exclude mode, sometimes called a bypass list, sends general traffic through the VPN except for the applications you explicitly exempt. This is convenient when most of your work should use the VPN and only a small group of local-dependent applications should remain direct.

The distinction matters because a rule can be technically correct but produce the opposite result from what you intended. If you add a streaming application to an allowlist, it may be the only app that uses the VPN. If you add the same application to a bypass list, it may be the only app that avoids the VPN. Always read the policy label and the client’s summary before connecting.

Application matching can also happen at different layers. A client may match the executable file, the process name, the package identity of a Microsoft Store application, or traffic created by a service. A launcher may start a second executable, and a browser may delegate media or authentication work to another process. Therefore, selecting the visible application icon does not guarantee that every related connection follows the same rule.

Choose the right routing policy before adding apps

Start by writing down the behavior you want in plain language. For example: “The work application uses the VPN, while the local printer utility and home media server stay direct.” This sentence is more useful than immediately clicking through a settings panel because it tells you whether an include or exclude policy is appropriate.

• ✅ Use include mode when only a small number of applications need the VPN.
• ✅ Use exclude mode when nearly all ordinary traffic should remain protected by the VPN.
• ✅ Identify launchers, helper processes, and background services before testing.
• ❌ Do not assume that a browser rule covers every separate browser profile or child process.
• ❌ Do not run two VPN clients with competing split-tunnel rules at the same time.

Include mode is often easier to audit. If the selected application works through the tunnel and the unselected applications remain direct, you can inspect a relatively small rule set. It also reduces the chance that an unrelated background service unexpectedly enters the VPN. The trade-off is that new helper processes may not be included automatically.

Exclude mode can be more convenient for a household or workstation where most traffic should use one general policy. However, it requires a more complete bypass list. Local discovery, printer software, video-conferencing tools, game launchers, and enterprise security agents may use several processes or service components. If one is missed, an application can appear partly functional while a particular feature fails.

Do not confuse split tunneling with protocol selection. Shadowsocks, VMess, Trojan, VLESS, Hysteria2, TUIC, and WireGuard describe how a connection is established or transported; split tunneling describes which traffic is sent through that connection. A client can expose one or more of these protocols while implementing application rules separately. Choosing a different protocol does not automatically create correct app exclusions.

Prepare the Windows client and add application rules

Before changing routing, update the VPN client through its normal official distribution channel and confirm that it supports application-based split tunneling rather than only manual route exclusions. The Windows built-in VPN panel can manage certain VPN connections and routes, but it does not provide the same application-rule workflow as a dedicated client. If the client has a subscription import function, import the current configuration first, then configure split tunneling in the client’s own settings.

The exact labels differ, but the workflow usually looks like this:

1. Open the Windows VPN client and connect to the intended profile or node.
2. Find a section named Split tunneling, App routing, Application rules, Per-app VPN, or a similar name.
3. Choose whether the policy is an include list or an exclude list.
4. Use the application picker to select the actual executable or package rather than a shortcut whenever possible.
5. Save the policy and reconnect the VPN if the client requests a restart.
6. Test one application at a time before adding a large group of rules.

When selecting a desktop application, check its installation path and executable name. A shortcut on the Start menu may point to a launcher rather than the program that creates the relevant network sessions. Some applications install a separate updater, crash reporter, web helper, or service. You do not necessarily need to route every helper through the VPN, but you should know which component handles sign-in, content delivery, media, or real-time traffic.

Microsoft Store applications can behave differently from traditional desktop programs. A client may show them by package name instead of a normal executable path, and some versions of Windows restrict how third-party software identifies their traffic. If the application picker does not list the program, look for a package-based option or consult the client’s built-in help. Avoid manually guessing protected system paths unless you understand how the client stores those rules.

After saving the rule, disconnect and reconnect rather than assuming that an existing connection has reloaded every policy. Some clients apply changes immediately, while others keep established sockets on the old route. Reopening the application is also useful because an already-running process may retain connections created before the rule changed.

Verify both the route and DNS behavior

A visible change in public IP address proves only that one request reached a particular exit point. It does not prove that every connection from the application followed the intended tunnel, and it does not prove that excluded applications used the direct route. Verification should therefore combine application behavior, route information, DNS behavior, and a comparison between included and excluded programs.

Windows provides useful diagnostic commands in PowerShell. Get-NetIPConfiguration can show active interfaces and gateway information, while Get-NetRoute can display routing entries and interface indexes. These commands do not automatically explain every client’s internal policy, but they help you see whether a virtual adapter and route table entry appeared after connection. Run them once before connecting and again after connecting so that you can compare the state.

Get-NetIPConfiguration
Get-NetRoute -AddressFamily IPv4
Get-NetRoute -AddressFamily IPv6

For an application test, begin with a program that clearly should use the VPN and another that clearly should bypass it. Open them separately after the tunnel is active. Check the external address using a trusted service you already use, inspect whether the application reaches its expected account or region, and observe whether local resources such as printers or network shares remain available. The test should represent the actual task, not only a browser page.

DNS deserves separate attention. A browser or application may use the VPN for its main connection while resolving names through a direct resolver, a cached answer, DNS-over-HTTPS, or an internal application resolver. Depending on your privacy and access requirements, that may be acceptable or may create an inconsistent result. Check the VPN client’s DNS mode, Windows adapter DNS settings, browser secure-DNS settings, and any application-specific resolver options.

IPv6 is another frequent source of confusion. If the VPN policy covers IPv4 but the application prefers IPv6, the application may use a different route from the one you expected. This does not mean IPv6 should always be disabled; it means that the client’s IPv6 handling must match your policy. A well-designed client should document whether it tunnels, blocks, or bypasses IPv6 traffic.

Troubleshoot common split-tunneling failures

The most common mistake is selecting a shortcut or launcher while the important traffic is created by another process. Open Windows Task Manager while the application is running and note the process names, but do not delete or alter system processes merely because their names look unfamiliar. The client’s own connection log, if available, may identify which process was matched by a rule.

Another problem is stale connections. A browser can keep a connection alive after you change the VPN policy, and a launcher can keep a background service active for a long time. Close the application completely, exit its tray component if necessary, reconnect the VPN, and launch it again. If the problem disappears after a clean restart, the rule may have been correct but was not applied to existing sockets.

Local network access can also be controlled by a separate setting such as Allow LAN traffic, Local network access, or Bypass private networks. This setting is not identical to an app rule. An application may be excluded from the VPN but still unable to reach a local device if the client blocks private-network traffic. Conversely, enabling local access can expose more local routes than you intended, so use it only when needed.

Security software may add another layer. Windows Firewall, endpoint protection, parental-control tools, and enterprise network agents can inspect the virtual adapter or block unfamiliar routes. If the VPN connects but only one application fails, compare the firewall profile and permissions before changing several VPN settings at once. Avoid creating broad firewall exceptions as a quick fix; identify the specific executable and network requirement first.

UDP-based traffic requires careful testing. A browser may use TCP for one function and QUIC or another UDP transport for another. Hysteria2 and TUIC also depend on UDP-related behavior, while WireGuard uses UDP for its tunnel transport. If an application works when media or real-time traffic falls back to TCP but fails when UDP is active, the issue may involve the local network, firewall, protocol support, or the client’s split-tunnel implementation rather than the selected app rule alone.

• ✅ Confirm the policy mode before reviewing individual entries.
• ✅ Reopen the target app after every meaningful routing change.
• ✅ Test IPv4 and IPv6 behavior when the result is inconsistent.
• ✅ Check whether DNS, UDP, and child processes are handled by the same policy.
• ❌ Do not change protocol, node, DNS, firewall, and Windows routes simultaneously.

Maintain split-tunnel rules safely

Application updates can change executable paths, package identifiers, helper processes, or network architecture. A rule that worked last month may stop matching after an update even though the application name looks unchanged. Review the rule when an application suddenly uses the wrong route, especially after reinstalling it or moving it to another drive.

Keep the rule list short and descriptive. If the client allows comments or labels, record the purpose of each entry, such as “work app through VPN” or “local printer direct.” Avoid adding entire installation folders unless the client explicitly documents folder-based matching. Broad folder rules can capture unrelated programs and make later troubleshooting difficult.

When importing a new subscription configuration, check whether the client preserves local application rules. Some clients store routing policies separately from node profiles, while others associate them with a particular profile. After an import or profile replacement, verify the policy again instead of assuming that the old behavior remains unchanged.

For a shared Windows computer, remember that application rules may apply per user, per profile, or system-wide depending on the client’s privilege level. A rule created by an administrator may not behave identically in another user session. Confirm the scope before relying on split tunneling for work, privacy, or access control.

VPNLP supports Windows alongside macOS, iOS, Android, and Linux. If you use the same subscription on multiple platforms, do not expect a Windows process rule to transfer to a mobile operating system. Import the subscription through the supported client on each device and configure the platform-specific routing controls separately. The service supports unlimited simultaneous devices, but each operating system still applies its own networking limitations.

Split tunneling FAQ