How to Set Up VPN Split Tunneling on Windows for Apps

Understand what split tunneling does on Windows

A VPN connection can route traffic for the whole device, while split tunneling applies different paths to selected traffic. In an app-based setup, the client uses its available routing mechanism to identify traffic from a Windows application and send it through the VPN or directly to the internet. A compatible proxy client may instead direct application traffic to a proxy, and its coverage can depend on system proxy settings, a virtual network interface, or other client-specific mechanisms.

Two common rule styles are an allowlist and a bypass list. With an allowlist, only the apps you select use the VPN and other traffic follows the client’s default behavior. With a bypass list, the VPN is the default and selected apps connect directly. Some clients offer both styles; others provide only one, or use different wording such as “include apps,” “exclude apps,” or “route selected applications.” Read the option’s description before changing it, because the same label can have different implications in different clients.

• ✅ Use an allowlist when you want to keep the VPN limited to a small, known set of applications.
• ✅ Use a bypass list when most traffic should use the VPN and only specific apps need a direct route.
• ❌ Don’t assume that a rule for a browser automatically covers every helper process, extension, or update service it launches.
• ❌ Don’t treat a VPN status icon as proof that a particular app used the intended route.

App rules are not the same as network-wide routing rules. Windows’ built-in VPN settings and route table can control connections by network, destination, or interface, but that does not automatically provide a general consumer-facing list of applications to include or exclude. Likewise, a proxy setting may affect only software that observes that setting. A client must explicitly support the kind of per-app routing you need.

Check client support before adding app rules

Start with the Windows client you actually use. Open its settings and look for a section named “Split tunneling,” “App routing,” “Application rules,” or something similar. Check the client’s help material for details about supported Windows versions, app types, connection modes, and whether rules take effect immediately or only after reconnecting. If the setting is absent, do not assume that a different protocol profile or a Windows route command will produce equivalent per-app control.

Official VPN clients and compatible third-party tools can expose different routing controls even when they use similar connection technology. A client may support per-app rules only in a particular mode, or its rule list may operate differently when a virtual adapter is active. Subscription import and split tunneling are separate functions: importing a configuration does not by itself create app rules, and an imported profile might not retain local rules when it is replaced or updated.

If you use a service’s Windows client, follow its setup instructions and check that the feature is supported in the current version. If you use a compatible client, confirm that it can parse the subscription format and that its routing options apply to the protocol and mode selected. Avoid copying configuration fragments from another client: similarly named settings are not necessarily interchangeable, and a syntactically valid rule may still match the wrong application.

Before editing, note the current connection mode and any existing app rules. If the client offers an export or backup function, use it. Otherwise, record the rule list so you can restore the original behavior. Close applications that are actively transferring data before changing routes, especially if their connections must remain stable. A rule change can interrupt an existing session, and the application may need to reconnect before it uses the new path.

Configure include or exclude rules

Once you have confirmed support, connect to the profile you intend to use and open the app-routing settings. The following sequence is a safe general approach; labels and restart requirements vary by client.

1. Choose the default route. Decide whether the VPN should be the default for traffic or whether only selected apps should use it. Read the client’s explanation of include and exclude behavior rather than relying on the label alone.
2. Add the application. Use the client’s app picker if available. If you must browse for a file, select the application executable that actually makes the network request. A desktop shortcut, installer, launcher, and main application can be different programs.
3. Check related processes. Some applications use a launcher to start a separate executable, or rely on a background service for sign-in, downloads, or updates. If the product documents these components, determine whether they also need a rule. Avoid adding unrelated system processes just to make the application appear connected.
4. Save and apply the change. Some clients apply rules immediately; others require you to disconnect and reconnect, restart the client, or reopen the application. Follow the client’s prompt and test with a new connection rather than assuming an existing session has moved.
5. Test one application at a time. Check the app that should use the VPN, then check one that should connect directly. This makes it easier to identify a reversed rule, an overlooked helper process, or a client mode that does not cover the traffic you expected.

For example, you might want a browser to use the VPN while a local-network management tool connects directly. Add the browser according to the client’s selected rule model, then test both applications independently. The result can differ if the browser uses a separate updater, if a web app opens an external helper, or if the client’s direct route still applies system-wide DNS or firewall handling.

Use [VPN61](../../index.html) to review the available service information, but remember that the app-routing controls themselves belong to the Windows client. Client interfaces and supported behaviors can change between releases. If you need installation or subscription-import steps, consult the Windows setup guide for the applicable workflow and then return to the client’s own routing settings.

Keep the rule list narrow and understandable. If you add a broad launcher rule and several overlapping child-process rules, it may become difficult to tell which one determines the route. Prefer a small set of clearly named applications, and remove old entries when you uninstall or replace software. When a rule has an option to choose direct or VPN routing explicitly, verify which action is selected before saving. For a ready-made option, see VPN61.

Verify that each app uses the expected route

Verify behavior from the applications, not only from the client’s connection display. For an app intended to use the VPN, open a service that reports the public IP address or region and compare the result with the app’s expected path. For an app intended to bypass the VPN, check that it reaches the required local or direct service. Do not use one browser tab to infer the route for every application: separate apps can use different network stacks, and a browser can create more than one process.

Use a consistent test: keep the same network connection, selected VPN profile, and application settings while comparing the expected behavior. If the client provides per-app connection logs or route diagnostics, use them to see whether it recognized the executable and applied the rule. Avoid treating a location lookup alone as a full security test; it may not reveal how every request, DNS query, or background connection was handled.

Also consider what should happen if the VPN disconnects. Some clients can block traffic that would otherwise go directly when the tunnel is unavailable; others may let traffic follow the regular connection. Check whether a kill switch or network lock is enabled and how it interacts with bypass rules. A direct-route application may intentionally remain outside the tunnel, while a VPN-only application may stop working if the client blocks its fallback path. Test this behavior only in a controlled way and avoid relying on an unverified assumption for sensitive activity.

The figures above describe a simple testing method, not performance measurements. Your client may present additional modes, and the right configuration depends on what the application needs. Keep a short note of the intended route for each rule so that you can compare the client’s settings with the test results after a software update.

Troubleshoot rules that stop working

If an application takes the wrong route, first confirm that the rule has not been reversed. Check whether the client is in allowlist or bypass-list mode, then verify that the selected executable is the one currently running. An app update can change its installation location or executable name, and a launcher may start a different process from the one you added. Remove obsolete entries only after noting their current settings, then add the correct application and reconnect if the client requires it.

If the rule appears correct but has no effect, check the client mode and network adapter state. Some routing features work only with a particular tunnel or proxy mode. Another VPN, proxy utility, firewall, endpoint-security product, or virtual network adapter may also change how traffic is handled. Close competing network tools before testing, but do not disable security software broadly. If an interaction is suspected, use the product’s supported diagnostic steps or consult its documentation.

When a browser reaches the expected route but a download, sign-in, or update does not, identify which process performs that task. A browser can hand a download to another program; an application can use a service or helper process for authentication. Check whether the client supports rules for those components and whether adding them is appropriate. If a service runs under a shared system process, avoid applying a broad rule without understanding which other traffic may be affected.

DNS behavior can also make a result seem inconsistent. A client may handle DNS separately from application routing, cache previous lookups, or send name-resolution requests through a route that differs from the app’s connection. Restart the affected app and retest after changing the profile. If the discrepancy remains, consult the client’s DNS and leak-protection documentation rather than changing unrelated Windows adapter values at random.

If rules stop working after a subscription refresh or client update, review the active profile and local routing settings. A refreshed configuration may replace or reset some client options, depending on the product. Reapply the rules only after confirming the selected profile and mode, then repeat the per-app checks. Keep the client and subscription configuration separate in your troubleshooting notes: one provides connection settings, while the other controls how Windows applications use those settings.

• ✅ Confirm the active profile, rule mode, and selected executable.
• ✅ Restart or reconnect only when the client indicates that changes need to be reapplied.
• ✅ Check for helper processes, client updates, and competing network tools.
• ❌ Don’t change system routes or DNS values as a guess when the client lacks documented per-app support.

Frequently asked questions

Can Windows’ built-in VPN settings route only selected apps?

Windows’ built-in consumer VPN interface is not a general substitute for a client’s app-based split-tunneling feature. Windows networking can support other routing arrangements in particular environments, but they require different configuration and do not automatically give you a reliable per-application include or exclude list. Check the VPN client’s documentation for the feature you need.

What if the application does not appear in the client’s picker?

Check whether the client lets you browse to an executable and confirm the installed app’s actual path. If the app uses a launcher or helper process, the network traffic may come from a different executable. Do not select a similarly named file without confirming its publisher and role. If the client cannot add the application or document its routing behavior, the feature may not support that app type.

Can one application use both direct and VPN routes?

Some applications make separate connections for different features, and a client may apply rules at the process level rather than understand the purpose of each request. That can make traffic appear to use more than one path. Whether that is configurable depends on the client’s routing model; app-based rules do not necessarily provide control over individual domains or requests.

Does importing a subscription enable split tunneling?

Not necessarily. A subscription typically supplies connection configuration, while split tunneling is a client feature that determines how selected app traffic is routed. Import the configuration using the client’s supported method, then check and test app rules separately.