Windows Split Tunneling Rules Guide: Route Apps Smarter

Windows split tunneling lets you decide which traffic uses a VPN route and which traffic keeps using the ordinary network connection. Instead of placing every application behind the same tunnel, you can send a selected browser, work tool, or domain through the VPN while allowing local services, regional websites, games, printers, and other everyday traffic to connect directly. This can reduce unnecessary routing, prevent local resources from becoming inaccessible, and make it easier to use different network paths for different tasks.

The difficult part is not turning on a switch. The difficult part is understanding what the rule actually matches, which traffic-handling mode is active, which rule has priority, and whether DNS requests follow the same decision as the application connection. A rule that appears correct may have no effect if the application does not use the Windows system proxy, if the client is running in TUN mode, or if the destination is reached through a different domain than expected.

This guide explains how to design Windows split tunneling rules, how to choose between application-based and domain-based matching, how to control priority, and how to test changes without guessing. The examples apply broadly to compatible Windows clients, including official clients and configuration clients such as Clash Verge or sing-box. Exact menu names vary, so focus on the traffic model rather than copying one client’s labels literally.

How Windows split tunneling works

A split tunneling decision is made somewhere between the application and the destination service. Depending on the client, traffic may first enter a local HTTP or SOCKS proxy, a system proxy, or a virtual network interface created by TUN mode. The client then evaluates rules and chooses a direct connection, a proxy group, or a specific route. The selected route can use protocols such as Shadowsocks, VMess, Trojan, Hysteria2, or WireGuard, but the protocol itself does not decide which Windows application should be routed. The routing rules do that job.

Windows application
→ System proxy, local proxy, or TUN interface
→ Rule matching
→ Direct connection or selected proxy group
→ DNS resolution and destination connection
→ Response returns to the application

There are two common matching dimensions. The first is the application itself. An application rule may identify an executable file such as a browser or terminal program. The second is the destination. A domain rule may match a full hostname, a group of subdomains, a suffix, an IP range, or a category supplied by a rule set. Application matching answers “which program is sending the request?” Domain matching answers “where is the request going?” Combining both can provide useful control, but it also makes troubleshooting more complex.

Windows clients generally expose three broad operating modes. In system proxy mode, the client writes proxy information to Windows settings. Applications that respect those settings can use the local proxy, while applications that ignore them may continue to connect directly. In a local proxy mode without system-wide activation, only applications manually configured to use the proxy are affected. In TUN mode, the client creates a virtual interface and captures a wider range of traffic, including applications that do not understand HTTP or SOCKS proxy settings. TUN mode can be more comprehensive, but it requires greater care with administrator permissions, DNS, local networks, and exclusions.

Direct and proxy are different decisions

A “direct” rule normally means that the client does not send the request through the selected VPN route. It does not necessarily mean that the request bypasses every local security product, DNS filter, or corporate gateway. Likewise, a “proxy” rule does not guarantee that every connection made by the application will be captured. Background services, separate helper processes, child processes, and hard-coded network stacks may follow different paths.

For example, a desktop editor may open its main interface through one executable while an update helper, extension host, or authentication component uses another executable. An application rule that names only the visible program may therefore produce incomplete results. Domain rules can cover the missing destinations, but they may also affect unrelated applications that use the same domain. The right choice depends on whether your priority is application isolation or destination consistency.

Choose the right rule matching method

Use application rules when the requirement is centered on a Windows program. A typical example is sending one browser through the VPN while leaving another browser direct. Application rules are also useful for a command-line tool, a development environment, or a specific client that must use one route independently of the websites opened elsewhere.

Use domain rules when the destination matters more than the program. This is useful when several applications must reach the same service through one route, or when one application needs a mixture of direct and proxied destinations. Domain rules are usually easier to maintain when the service changes its desktop application, helper process, or browser integration, although a service may use multiple hostnames that must be identified carefully.

Application rules and Windows processes

When creating an application rule, select the executable that owns the network connection rather than an icon or shortcut. A shortcut may launch a different file, and a store-installed application may use a packaged process that is not obvious from its visible name. If the rule appears ineffective, open Windows Task Manager while the application is active and inspect the process tree. Look for browser helpers, update services, login agents, and extension processes that may be making separate requests.

Be cautious with broad process rules. Routing every process belonging to a vendor or every executable in a large directory can unintentionally include update tools, telemetry components, local helpers, or unrelated applications. A narrow rule is easier to audit. If a client supports process-name matching, confirm whether it matches the executable name, the full path, or a process group. These are not interchangeable behaviors.

Domain rules and DNS behavior

Domain matching normally occurs after the client has identified a hostname, but the exact sequence depends on the client and its DNS mode. Some clients resolve a hostname locally before selecting a route. Others send the DNS request to a remote resolver or use fake-IP mapping so that the rule engine can preserve the hostname during matching. If an application connects directly to an IP address, a domain rule may not match at all.

Do not assume that the visible website domain is the only required domain. A service may use separate hostnames for authentication, APIs, images, downloads, content delivery, analytics, and real-time connections. Start with the smallest known set, test the actual workflow, and add only the domains that are necessary. A broad suffix rule may solve one login problem while also routing unrelated subdomains through the VPN.

DNS leaks and DNS mismatches can create confusing results. The application may use a proxied connection while the hostname was resolved through the direct network, or the DNS query may follow a different policy from the final connection. When a domain rule seems inconsistent, inspect the client’s DNS mode, IPv4 and IPv6 handling, and whether the application uses its own encrypted DNS service.

Set rule priority and the default policy

Rule order is one of the most important parts of split tunneling. Many rule engines evaluate entries from top to bottom and stop at the first match. Others use a more specific-match system, but you should not assume that specificity wins unless the client documents that behavior. A broad rule placed above a narrow exception can make the exception unreachable.

A practical rule structure usually begins with explicit exceptions, continues with specific application or domain matches, and ends with a default policy. The default policy might be direct, a selected proxy group, or another defined action. The important point is that every unmatched request has a predictable destination. An unclear default policy makes it difficult to tell whether a connection followed a deliberate rule or simply fell through the list.

1. Local network and private address exceptions
2. Explicit direct domains or applications
3. Specific VPN domains or applications
4. Required IP or address-family exceptions
5. Final default policy

There is no universal order for every client. If your primary goal is to route one application through the VPN, you may place local network exclusions first and the application rule next. If your primary goal is destination-based routing, specific domain rules may come before broader domain categories. Read the client’s rule syntax and inspect its generated configuration after editing, especially when using imported subscriptions or external rule sets.

Avoid conflicting rules

Conflicts often appear when a broad domain suffix includes a direct exception, when an application rule disagrees with a domain rule, or when an external rule set is loaded above a local override. Write down the intended result before changing the configuration. For example: “This browser should use the VPN for selected domains, but local printer addresses must remain direct.” That statement can be translated into explicit rules and tested one decision at a time.

Keep rule names descriptive. Names such as “Browser VPN,” “Local direct,” or “Work API” are easier to audit than labels based only on dates or route names. Avoid changing multiple groups at once. If you edit the rule order, the default policy, DNS mode, and TUN setting together, a successful result will not tell you which change fixed the problem.

• ✅ Put narrow exceptions before broad matching rules when the client uses first-match evaluation.
• ✅ Keep a clear final policy for traffic that matches nothing else.
• ✅ Confirm whether imported rule sets appear before or after local rules.
• ❌ Do not assume a domain suffix rule covers direct-IP connections.
• ❌ Do not place two clients in control of the Windows system proxy at the same time.

Hands-on Windows setup and testing

Begin by recording the current client state. Note the active mode, selected route group, system proxy status, TUN status, DNS mode, and any custom rules. If the client supports exporting or copying its configuration, save a backup before making changes. This gives you a known rollback point and prevents a temporary experiment from becoming a permanent configuration that no one understands later.

1. Choose one test application. Use an application whose traffic you can identify clearly, such as a browser or terminal tool. Close unrelated programs where possible so that background connections do not confuse the result.
2. Choose one test destination. Select a domain that should use the VPN and another destination that should remain direct. Do not begin with a large rule set or many categories.
3. Confirm the operating mode. Check whether the client uses system proxy, manual proxy settings, or TUN. If system proxy mode is active, verify that Windows proxy settings show the expected local endpoint.
4. Add the narrowest rule. Start with one application or one domain. Assign it to the intended proxy group or direct policy, then move it to the correct priority position.
5. Restart the relevant connection. Existing TCP, QUIC, WebSocket, or application sessions may remain on the old path. Close and reopen the application, or disconnect and reconnect the client before judging the new rule.
6. Test both positive and negative cases. Confirm that the selected traffic uses the intended route and that an unrelated destination follows the default policy.
7. Check logs. Use the client’s connection or rule-match log to see the matched hostname, process, action, and selected group. A log entry is more useful than guessing from the page result alone.

For a basic verification, compare the client’s connection log with Windows tools such as Task Manager, Resource Monitor, or the command line. Resource Monitor can help identify which process owns an active connection. Windows commands such as nslookup can show which resolver answered a query, although they may not represent an application’s private DNS behavior. If the client provides a traffic log, prefer it for determining the final rule decision.

Test more than a web page. Open a new session, sign in if the workflow requires authentication, load a resource from the destination, and try a background action such as an update check only if it is safe to do so. Browser caching can make a broken route look healthy, while an already established connection can make a changed rule appear ineffective. Testing a fresh session reduces both problems.

Test direct, local, and VPN paths

A good test matrix contains at least three paths: a destination that should use the VPN, a destination that should remain direct, and a local resource such as a private address, network printer, or home service. If the VPN destination works but local resources fail, inspect private-address exclusions, local DNS, and TUN settings. If both destinations use the VPN, inspect the default policy and rule priority. If neither destination follows the expected rule, verify that the application is entering the client at all.

Also test after switching networks. Home broadband, office networks, public Wi-Fi, and mobile hotspots can differ in DNS responses, IPv6 availability, UDP handling, and firewall behavior. A configuration that works on one network may need a different mode or a narrower exclusion on another. This is not proof that the rule is wrong; it means that the complete traffic path has changed.

Troubleshoot and roll back safely

When a rule does not work, reduce the problem to stages. First ask whether the client is connected to a usable route. Then ask whether the application traffic reaches the client. Next check which rule matched, which action was selected, and whether DNS followed the intended path. Finally check the destination service itself. This order prevents you from rewriting rules when the actual failure is an invalid subscription, a disconnected route, or an application that bypasses the configured proxy.

If only one application fails, inspect its proxy support, helper processes, certificate behavior, and private DNS settings. Some applications use their own network stack and ignore Windows proxy settings. Others require TUN mode to capture traffic that is not HTTP or SOCKS-aware. If the application works in TUN mode but not system proxy mode, the difference is probably traffic capture rather than the domain rule itself.

If only one domain fails, look for redirects, alternate hostnames, content delivery domains, IPv6 addresses, and direct-IP connections. Avoid immediately replacing a narrow rule with a global proxy policy. A broader policy can hide the missing dependency while creating new problems for unrelated traffic.

If local services stop working, check whether private address ranges, local hostnames, multicast discovery, or the local DNS server are being sent into the VPN. Some TUN implementations also require explicit bypass settings for local networks. Restore the client’s original mode temporarily and test again. This comparison helps separate a rule error from a TUN or DNS integration issue.

Rollback should be deliberate. Disable the newest rule first, restore the previous default policy, and return system proxy and TUN settings to their earlier state if they were changed during the experiment. Then close the affected applications and reconnect the client. If the problem remains, use the saved configuration rather than deleting random entries. Keep one clean baseline configuration and make future changes in small, documented steps.

A maintainable rule design

The best Windows split tunneling configuration is not the one with the most entries. It is the one whose decisions can be explained. Start with a clear default policy, add local-network protection, then add only the applications and domains that have a real routing requirement. Keep direct exceptions visible, avoid duplicate entries, and review imported rule sets when they change.

Use application matching for stable program-level requirements, domain matching for services shared by multiple programs, and IP matching only when you understand the cost of changing addresses or shared infrastructure. Keep DNS behavior consistent with the routing decision, and test fresh connections after every meaningful change. When a service depends on several domains, document those dependencies rather than hiding them inside an overly broad suffix.

Finally, separate configuration problems from route-quality problems. A correctly matched rule can still use a route that is unsuitable for a particular task, while a good route cannot fix a request that never enters the client. Confirm the match first, confirm the selected action second, and evaluate the route only after those two facts are known.

With that workflow, split tunneling becomes a controlled Windows routing policy rather than a collection of trial-and-error switches. You can send selected applications or destinations through the VPN, keep unrelated traffic direct, preserve access to local resources, and return to a known-good state whenever an experiment produces an unexpected result.