Android VPN split tunneling lets you choose which apps send traffic through a VPN connection and which use the device’s regular network. It is useful when one app needs a different network path from the rest of the phone—for example, when you want a work app to use the VPN but a local banking app or smart-home app to connect directly. The exact controls depend on the VPN client: some offer an app list with include or exclude rules, while others provide only domain-based or global routing.
The key is to distinguish an app rule from a connection status. Seeing “Connected” confirms that the VPN client has established a tunnel, but it does not prove that every app is using that tunnel. Before changing settings, decide which apps should use the VPN, check how your client defines its rules, and verify the route for each app afterward. If a rule has the opposite effect from what you expected, the client may use a different inclusion or exclusion model—not necessarily have a broken connection.
How split tunneling works on Android
An Android VPN client typically uses Android’s VPN service interface to create a virtual network connection for the device. The client then applies routing rules to decide which traffic enters that connection. In an app-based setup, the rule is associated with an installed app, usually identified by its Android package rather than by the name of a website the app visits.
There are two common ways to define the app list. With an include selected apps rule, only the apps you select are intended to use the VPN; other apps use the regular network. With an exclude selected apps rule, most apps use the VPN except for the apps you select. Clients may describe these choices as “include,” “exclude,” “bypass,” “use VPN for selected apps,” or “route selected apps through proxy.” Read the explanatory text in the client before saving: “bypass” normally means avoiding the VPN, but labels and defaults are not identical across products.
App-based routing is different from domain-based rules. An app rule selects traffic by the app that created it, while a domain rule matches a destination such as a website or service. A browser can contact many different domains, and a single domain may be used by several apps. If you need to control only one website, a domain rule may be more appropriate where the client supports it. If your goal is to route all traffic from a particular app consistently, an app rule is generally easier to maintain.
| Rule type | What you select | Useful when | What to verify |
|---|---|---|---|
| Include apps | Apps that should use the VPN | Only a small set of apps needs the VPN route | Unselected apps may connect directly |
| Exclude or bypass apps | Apps that should avoid the VPN | Most apps should use the VPN, with a few exceptions | Selected apps should use the local network path |
| Domain or destination rules | Domains, IP addresses, or rule groups | Only certain destinations need a particular route | One app may use multiple destinations |
| Global routing | No per-app exception list | You want a simple baseline for troubleshooting | Most or all eligible traffic follows the client’s global route |
Android normally allows one active VPN service at a time. Starting another VPN app, a work-profile VPN, or a security app that creates its own VPN connection can replace or conflict with the existing connection. This is separate from split tunneling: an app can be correctly selected in a rule list and still fail to follow the expected route because another service, a profile policy, or an operating-system restriction is involved.
Prepare your app rules before editing
Start with a short list of apps and the route each one needs. Avoid selecting apps at random and then trying to infer what the settings mean from a connection failure. For each app, write down whether it should use the VPN or connect directly, and note why. This makes it easier to test one change at a time and to restore the original behavior if another app depends on the same network path.
- ✅ Decide which specific apps need the VPN route and which should connect directly.
- ✅ Check whether the client describes its setting as include, exclude, bypass, or direct.
- ✅ Confirm that the target app appears in the installed-app list and select the intended package.
- ✅ Note the current mode and rule list before editing, so you can undo the change.
- ❌ Do not assume that a browser rule controls every app that opens web links.
- ❌ Do not run multiple VPN clients at once while testing app routing.
Pay attention to duplicate-looking entries. Android may show a consumer version of an app separately from a work-profile copy, or list a browser and its companion app as different entries. The profile matters: selecting an app in the personal profile does not necessarily select its work-profile counterpart. If an app is missing, check that it is installed in the profile where you are configuring the VPN and that the client has permission to read the app list.
Also review the VPN client’s existing routing mode. Some clients combine app selection with a global, rule-based, or direct mode. In a rule-based mode, an app selection may be one layer among domain, IP, and network rules. In a global mode, the client may send most traffic through the VPN unless an explicit bypass applies. An app list cannot be understood in isolation if another rule has higher priority.
Think through any local services that the app uses. A direct connection can be necessary for access to a local printer, casting device, company network, or home automation service. Conversely, an app that connects to several third-party endpoints may not work as expected if only some destinations are routed through the VPN. When the client supports more than one kind of rule, use the narrowest rule that matches your goal and check how rule priority is applied.
Configure per-app routing in the VPN client
The wording differs between clients, so use the following workflow as a guide rather than assuming every menu has the same name. Update the client using its normal distribution channel if the app list or VPN settings do not appear. Then open the client and locate a section such as Settings, Routing, Split tunneling, App rules, or Per-app proxy.
- Connect only the client you intend to test. Disconnect another VPN app or proxy service first. If Android shows a system prompt asking to allow a VPN connection, review the app name and approve only the client you intended to use.
- Find the app-routing controls. Open the client’s settings and look for its app selection or split-tunneling feature. If you cannot find it, check the client’s built-in help or documentation; the feature may be unavailable in that app, disabled in the current mode, or named differently.
- Choose the rule model. Decide whether the selected apps should use the VPN or bypass it. Read any description next to the option, especially if the client uses terms such as “proxy,” “direct,” or “exclude.” Do not infer the meaning from a checkbox alone.
- Select the intended apps. Use the app list to mark only the entries from your preparation list. Check for personal and work-profile copies, and verify the selected names before leaving the screen.
- Save and reconnect if required. Some clients apply changes immediately; others require you to save, restart the tunnel, or reconnect to the selected route. Follow the app’s own instruction and wait for its connection status to settle.
- Test both sides of the rule. Check an app expected to use the VPN and an app expected to connect directly. A single successful test does not confirm that the other side of the rule is correct.
If the interface provides a separate “bypass local network” option, do not confuse it with per-app bypass. A local-network exception can affect access to private addresses or nearby devices, while an app exception usually concerns traffic generated by a selected app. These controls can coexist, and their effects may overlap. Change one at a time, test, and keep a note of what you changed.
For clients that import a subscription, importing server configuration and choosing app rules are separate tasks. A subscription typically supplies connection information such as routes, groups, and protocol settings; it does not automatically mean your preferred app list has been configured. After importing or updating a subscription, revisit the routing settings and confirm whether the client retained your local app rules.
Do not assume that every Android-compatible client exposes per-app controls or that the same control works identically across clients. Android clients based on different routing engines can present different rule formats and capabilities. Desktop applications such as Clash Verge are not Android phone clients, and a configuration concept available on desktop may not map directly to the Android interface. Use the client’s Android-specific documentation when the setting is unclear.
Verify which route each app uses
Test with one app at a time. First confirm the VPN client shows an established connection, then open an app that should use the VPN and check a trustworthy network or account signal relevant to that app. If the app exposes connection details, compare them with the expected route. A browser-based IP check can be useful for browser traffic, but it only tests that browser; it does not prove that a separate messaging, streaming, or banking app uses the same route.
For an app expected to connect directly, check a function that depends on the local network or the service’s normal access path. Do not rely only on the app loading its home screen: cached content can appear even when a new request is not following the expected route. Refresh the relevant page or perform a new request, then compare behavior with the VPN disconnected. If the app handles sensitive data, avoid entering credentials into unofficial test pages or sharing screenshots that reveal account information.
Change only one variable between tests. Keep the same network, selected route, and app version while testing the routing rule. If you change the server, protocol, DNS mode, and app list at the same time, a successful result will not tell you which change mattered. A concise record of the mode, selected apps, route, and observed result is enough to make a later comparison useful.
| Expected behavior | Practical check | If the result differs |
|---|---|---|
| Selected app uses VPN | Open the app and make a fresh network request while the VPN is connected | Check include/exclude semantics, rule priority, and whether the right profile was selected |
| Selected app connects directly | Test a fresh request and compare with the app’s behavior when the VPN is disconnected | Check whether the client’s bypass list applies to the active mode |
| Other apps keep their expected route | Test at least one app outside the selected list | Review whether the rule model applies to selected apps or to all traffic by default |
Remember that applications may use background services, embedded browsers, or companion processes. A notification might be delivered by a shared system component rather than by the app screen you are looking at. App routing is a useful control, but it does not always give you a simple, visible mapping from every background request to one app icon. When a result is inconsistent, compare a fresh foreground request and review the client’s diagnostics, if available.
Fix common split-tunneling conflicts
A selected app cannot connect
First determine whether the app is supposed to use the VPN or bypass it. Recheck the selected mode and confirm that the rule is active for the current connection. If the app should use the VPN, try temporarily removing its exception or testing the client’s default routing mode. If it should connect directly, confirm that the client supports direct routing for apps in the mode you selected. Then reconnect and test again. This separates a rule problem from a general VPN or local-network problem.
The rule seems to do the opposite
Look for a distinction between “apps included in VPN” and “apps excluded from VPN.” In one mode, ticking an app sends it through the VPN; in another, ticking it bypasses the tunnel. Also check for a global setting or a higher-priority rule that overrides the app list. If you are uncertain, remove all app selections, connect in the client’s default mode, and test the basic connection before rebuilding the list carefully.
A local device or work app stops working
Check whether the app needs access to a private network, local device, or managed work profile. A work profile may be governed by organization policy, and its VPN behavior can differ from the personal profile. A smart-home, casting, or printer app may need local-network access even when its internet traffic uses the VPN. Review both the app rules and any separate local-network option; do not assume that excluding an app is the only way to restore local discovery.
The connection drops after switching apps or networks
Check Android’s VPN settings for an always-on VPN or a “block connections without VPN” option. These system controls can prevent direct traffic or enforce a particular VPN service, which may conflict with an app’s intended bypass behavior. Also disconnect other VPN-based tools, including another proxy client or an app that filters traffic through a local VPN. Reconnect the chosen client after resolving the conflict, then repeat the app tests.
Battery optimization and background restrictions can also affect a client that is expected to maintain a connection, although they do not change the meaning of an app rule. If routing works in the foreground but stops after the screen is locked, review the client’s Android-specific background guidance and the device manufacturer’s battery settings. Change only the settings the client requires, and keep normal device security protections enabled wherever possible.
Reset or rebuild your app rules
If the configuration has become difficult to understand, take a reversible approach. Record or capture the current mode and app selections for your own reference, disconnect the VPN, and clear only the app rules first. Reconnect using the client’s default routing behavior and test a small number of apps. If the default behavior works, add the intended selections back in small groups, checking the result after each change. This makes it easier to identify a particular app, profile, or rule that causes the conflict.
If the client offers a “reset routing” or “restore defaults” option, read its confirmation carefully. It may reset more than the app list, including domain rules, DNS preferences, or other local settings. Avoid deleting the subscription or account configuration unless there is a separate reason to do so; server configuration and locally maintained app rules are different parts of the setup. After a client update, check whether the app list was preserved and whether the rule labels or defaults changed.
When contacting support, provide the Android version, VPN client name and version, active routing mode, whether the rule is include or exclude, and the affected app’s profile. Describe what you expected and what happened, and include whether the issue occurs with the VPN disconnected. Do not send a subscription URL, password, authentication token, or unredacted diagnostic file: subscription links can contain account-specific access information and should be treated as credentials.
Frequently asked questions
Can Android set split tunneling without a VPN client?
Android’s system VPN settings manage connections and certain system-level policies, but per-app routing controls are generally provided by the VPN client or by a managed-device configuration. The exact options vary by Android version, device, and profile. If you do not see an app list in system settings, check the VPN client’s routing options rather than assuming your phone has a universal split-tunneling menu.
Can I route only one app through the VPN?
Often, if the Android client supports an include-selected-apps mode. Select the intended app, confirm that the rule means “use VPN,” reconnect if required, and test a fresh request. Other apps may continue to use the regular network, subject to the client’s default mode and any system policy.
Does selecting a browser cover every website and linked app?
It applies to traffic attributed to that browser, not automatically to every app opened from a link. A browser may launch a separate app, and apps may contact multiple domains or use background components. Test the actual app and destination behavior you care about instead of treating one browser check as proof for the entire device.
Why does a bypassed app still appear unable to connect?
Check whether the list is an include list rather than an exclude list, whether the current mode honors app exceptions, and whether Android is enforcing an always-on VPN or blocking traffic without a VPN. Also check for another active VPN-based app and any work-profile restrictions. Reconnect after correcting the rule, then verify with a fresh request.