If split tunneling is not working, first confirm that your current VPN client, operating system, and connection mode actually support it. Then identify whether your rule means “only these apps use the VPN” or “these apps bypass the VPN,” rebuild the connection, and test two known apps against a clean baseline.

Do not start by changing DNS, protocols, and firewall rules together. A split-tunnel diagnosis works only when you can say which application should use which path and how you verified the result.

Key Takeaways

A missing split-tunnel feature is a capability limit, not a broken rule.

Inclusion and exclusion modes produce opposite results from the same app list.

Per-app lists often bind to an installed application identity, not a window title or website.

Reconnect the VPN after changing rules so the client can build a new tunnel and routes.

Work and school policy takes priority; do not bypass managed routes or traffic filters.

What does it mean when split tunneling is not working?

Split tunneling sends selected traffic through the VPN while other traffic uses the ordinary network path. On Android, a VPN app can build either an allowed-app list or a disallowed-app list, but not both; if neither list exists, the system sends all traffic through the VPN. The lists must be set before the connection is established.［1］［2］

Windows describes the same routing choice at the network level: a split tunnel specifies routes that use the VPN, while other traffic uses the physical interface; a forced tunnel sends traffic through the VPN by default.［3］ Windows profile options can also define split-tunnel routes, forced-tunnel behavior, and related policy.［4］

That creates several different failure reports:

Symptom	Question to answer first
An excluded app still shows the VPN IP	Is the rule exclusion mode, and is this the correct app identity?
An included app uses the direct IP	Did the rule apply before the current tunnel was established?
A website differs between two browsers	Are the browser processes, proxies, and DNS paths actually the same?
Local resources stop working	Is a route or local-network exception missing?
The setting is absent	Does this client and platform support split tunneling at all?
Rules revert after reconnecting	Is the profile managed or synchronized from another source?

How do you troubleshoot split-tunnel rules?

1. Confirm capability before diagnosing configuration

Check the current official documentation for the exact VPN client, operating system, and connection mode. A feature available on Android may not exist on iOS; a provider app may behave differently from a Windows built-in profile; and an organization-managed tunnel may expose no user-editable rule.

If the feature is not documented or the control is absent, stop calling it a malfunction. Do not install an unofficial client or import an unknown profile to add bypass behavior. Ask the provider or administrator which platforms and modes are supported.

2. Identify inclusion or exclusion mode

Write the desired policy as one sentence: “Only App A should use the VPN,” or “App B should bypass the VPN while everything else uses it.” Then compare that sentence with the UI description. Labels such as include, protect, route through VPN, exclude, bypass, or do not use VPN are not interchangeable.

Start with one test app in the list. Remove duplicate or contradictory rules. If the client supports both app and destination rules, test one type at a time. A domain rule can affect several applications, while an application rule can affect many destinations.

3. Build three controlled baselines

Choose two applications and one neutral test destination that you are authorized to use. Record results in three states:

State	App expected through VPN	App expected direct
VPN off	Direct baseline	Direct baseline
VPN on, no split rule	Full-tunnel baseline	Full-tunnel baseline
VPN on, split rule active	VPN path	Direct path

Check the public IP or approved destination behavior from inside each application where possible. A browser result does not prove the route used by a desktop client. Keep the device, account, network, destination, and time window fixed. If the full-tunnel baseline already fails, solve that connection problem before testing split tunneling.

4. Verify the installed application identity

Per-app VPN rules commonly attach to a package, bundle, executable, or managed-app identity. Android explicitly requires the package to be installed when it is added to an allowed or disallowed list.［2］ An app update, alternate edition, helper process, web wrapper, or store-versus-direct installation can therefore make a rule point at the wrong identity.

Remove the old entry and select the currently installed app through the VPN client's supported picker. Do not type or copy an executable path unless official guidance requires it. For software with helper processes, ask the vendor which component owns network traffic rather than adding every process blindly.

5. Rebuild the tunnel after every rule change

Save the rule, disconnect once, wait for the system to show a stable disconnected state, and reconnect. Android's developer documentation says per-app lists are set before the VPN connection is established; changing them requires a new VPN connection.［1］

Retest only the two chosen applications. If the client is stuck on teardown, use recovering a VPN stuck during disconnect before continuing. Do not combine a stale tunnel, a changed rule, and a changed test destination in one result.

6. Separate routes, DNS, proxy, and address families

Routing decides which interface receives a packet, but name resolution and proxies can alter what destination the application uses. An excluded app may still use DNS supplied by the VPN. A browser may use its own encrypted DNS or proxy. IPv4 and IPv6 may also follow different route sets.

Record whether the failure concerns the public IP, name lookup, access to a local address, or connection to a specific service. On Windows, compare the intended split or forced-tunnel policy with the actual profile rather than deleting routes manually.［3］［4］ On a personal device, temporarily remove only a test proxy you configured yourself; on a managed device, ask the administrator.

7. Check competing network controls and policy

Another VPN, firewall, endpoint-security agent, parental-control filter, DNS filter, or browser extension can own part of the path. Disable only a control you recognize, one at a time, and restore it after the test. Never disable organization-required protection or remove device management.

In AethoVPN, the documented routing control is Global mode rather than a per-app list: with Global mode on, every app's traffic goes through the tunnel; with it off, traffic to websites in your own region skips AethoVPN, which helps when local sites, especially government sites that reject foreign IP addresses, fail to open or slow down.［5］ Run your matrix twice, once in each state, and record which apps and sites change path. That switch is not an app-by-app rule, so an app you need excluded still requires a platform or administrator control; if the matrix fails even for the local-site case, send support the mode, app identity, platform, client version, test states and timestamps. Download the current client for your platform before repeating the test.

How can you tell which layer failed?

Use the smallest observation that distinguishes the layers:

Capability failure: there is no documented feature for this client or mode.
Rule-model failure: the include/exclude meaning is opposite to your expectation.
Identity failure: another package or helper process owns the traffic.
Lifecycle failure: the rule changed, but the old tunnel remained active.
Route failure: the destination prefix follows the wrong interface.
Name-resolution failure: route tests by IP work, but names resolve differently.
Proxy failure: one application uses a proxy or PAC path that another ignores.
Policy failure: management restores or overrides the local rule.

This classification is more useful than saying “split VPN is broken.” It also produces a support report that another person can reproduce.

What should you not do?

Do not use split tunneling to evade employer, school, or service policy. Do not add broad route exclusions copied from a forum, and do not turn off a firewall permanently to make one test pass. A bypass rule changes which traffic receives VPN protection, so every exception should have a clear purpose and owner.

Do not trust a single IP-check tab that was already open. Browsers cache connections and may use different DNS or proxy paths. Start a fresh test session and compare the result with the application that is actually in the rule.

Summary

Confirm that split tunneling exists for the exact client and platform.
Translate the UI into one explicit include or exclude policy.
Compare VPN-off, full-tunnel, and split-tunnel baselines with two fixed apps.
Reselect the current installed app identity and reconnect after every change.
Diagnose route, DNS, proxy, IPv4/IPv6, and managed policy as separate layers.

FAQ

Why does an excluded app still use the VPN IP?

The rule may be in inclusion mode, attached to the wrong app identity, or waiting for a new tunnel. Confirm the rule direction, reselect the installed app, disconnect fully, and reconnect before testing again.

Why is the split tunneling option missing?

The current provider client, operating system, protocol mode, or managed profile may not support user-controlled split tunneling. Confirm current official support rather than treating the missing control as a defect.

Do I need to reconnect after changing split-tunnel rules?

Yes, that is the safest assumption. Android applies per-app lists when establishing the VPN, and many other clients also rebuild routes at connection time.

Can DNS still use the VPN for an excluded app?

Yes. Application routing, DNS resolution, and proxy behavior are related but separate layers. Test name lookup and the final connection path independently.

Why does one browser obey the rule but another does not?

They may be different installed identities or use different helper processes, DNS settings, extensions, or proxies. A website result in one browser cannot prove the route used by another application.

Is it safe to edit the Windows routing table manually?

Not as a first troubleshooting step. Compare the intended VPN profile and official route policy first. Manual changes can disappear on reconnect or interfere with organization-managed access.

What should I send to VPN support?

Send the platform and client version, confirmed feature mode, exact include/exclude rule, installed app identity, three-state test matrix, destinations, timestamps, and whether the device is managed. Remove credentials and unrelated logs.

Disclaimer: Split tunneling changes which traffic uses VPN protection. This article provides general technical information; follow current provider instructions and organization policy before changing routes or exclusions.

Sources:

Android Developers - VPN developer guide — https://developer.android.com/develop/connectivity/vpn
Android Developers - VpnService.Builder — https://developer.android.com/reference/android/net/VpnService.Builder.html
Microsoft Learn - VPN routing decisions — https://learn.microsoft.com/en-us/windows/security/operating-system-security/network-security/vpn/vpn-routing
Microsoft Learn - VPN profile options — https://learn.microsoft.com/en-us/windows/security/operating-system-security/network-security/vpn/vpn-profile-options
AethoVPN official website — https://www.aethovpn.com/en

Sources checked 6 September 2026.

Related articles:

Split Tunneling Is Not Working: What to Check