Android VPN split tunneling lets you choose which apps use a VPN connection and which connect through the device’s normal network route. It is useful when some apps need a remote VPN route while local services, banking apps, or other traffic should remain direct. The exact controls depend on the Android client: some offer an app list, some describe the options as “include” or “exclude,” and some do not support app-based routing at all.
How Android split tunneling works
On Android, a VPN client normally creates a local VPN interface and applies routing rules to traffic from the device. With app-based split tunneling, the client uses an app selection to determine which applications use that interface. The rule usually applies to an app as a whole, rather than to only one website, server, or feature inside it. If an app uses several network connections for different functions, those connections generally follow the same app-level rule.
There are two common selection models. In an inclusion model, you select the apps that should use the VPN; other apps use the regular connection. In an exclusion model, you select apps that should bypass the VPN; other apps use the VPN. The labels vary, so read the explanatory text in the client instead of inferring the behavior from a checkbox or switch. Selecting the same app in the wrong model reverses the intended result.
| Selection model | Apps you select | Apps not selected | Typical reason to use it |
|---|---|---|---|
| Include selected apps | Use the VPN route | Use the regular route | Only a small group needs the VPN |
| Exclude selected apps | Bypass the VPN | Use the VPN route | Most apps should use the VPN, with a few exceptions |
| No app-based routing option | Selection is unavailable | The client’s general routing behavior applies | Use a compatible client or another supported routing method |
App-based routing should not be confused with changing a node, choosing a protocol, or importing a subscription. A subscription provides configuration to a compatible client; a node is a remote route; and split tunneling decides which apps use the client’s VPN interface. Changing one of these settings does not automatically correct the others. If you manage a subscription with VPNRS, first make sure the client has a valid configuration, then adjust app routing in the client that is actually connected.
Android can generally have only one active VPN service handling device traffic at a time. If another VPN, firewall, ad blocker, or local filtering app also uses Android’s VPN interface, the apps may compete for control or one connection may replace the other. Close or disable the other VPN-based tool while you diagnose routing. This is different from an ordinary app that uses a proxy setting internally; such an app may have its own behavior independent of Android’s system VPN interface.
Choose the right routing model before editing the app list
Start with the outcome you want, not with the assumption that every app should be selected. If only a few apps need the VPN, inclusion can be easier to review: the list explicitly shows the apps routed through the tunnel. If most apps should use the VPN and only a few should bypass it, exclusion may be more practical. In either case, write down or remember the intended groups before changing the client. This gives you a reference when a test result seems unexpected.
- ✅ Use an inclusion model when only specific apps need the VPN route.
- ✅ Use an exclusion model when most apps should use the VPN and only selected apps should connect directly.
- ✅ Read the client’s explanation of “selected” and “not selected” before saving.
- ❌ Do not assume that selecting an app always means it bypasses the VPN.
- ❌ Do not run two Android VPN clients at once while trying to identify which routing rule is active.
Consider the consequences for each app, not just whether it opens. An app routed directly may expose the network address assigned by your internet connection to the service it contacts. An app routed through the VPN uses the VPN route for its network traffic, but this does not make the app anonymous or change the information you provide inside it. For account-sensitive apps, follow the service’s own security guidance and check whether it expects a particular region or network.
Also consider companion processes and related apps. A streaming app, for example, may rely on a separate browser or sign-in component; an app that opens a web page externally may hand that task to the browser, which follows the browser’s own routing rule. A messaging app’s notifications can also involve background services. Do not assume that selecting one app automatically selects every app it launches or every system component it depends on.
Set up app-based routing on Android
Menu names and exact controls depend on the client and Android version. The following sequence is a safe way to configure the feature without relying on a particular vendor’s interface. If you are using a third-party client such as Clash Verge on another platform or a compatible Android client such as sing-box, check that client’s own documentation: support for a subscription format does not by itself guarantee support for Android app selection.
- Confirm the active client. Open the Android client you intend to use and check that it has the current configuration or subscription. If you have imported a subscription recently, refresh it using the client’s update control before testing. Do not share the subscription URL when requesting troubleshooting help; it may grant access to account configuration.
- Find the app-routing control. Look in the connected profile, VPN settings, routing, or per-app settings. The feature may be labelled “App filter,” “Per-app VPN,” “Bypass apps,” “Allow selected apps,” or similar. If you cannot find an app list, consult the client’s instructions rather than changing unrelated DNS or proxy settings.
- Choose inclusion or exclusion. Read the on-screen description and identify what happens to selected apps and to apps left unselected. If the client presents a checkbox list without a clear explanation, test with a non-sensitive app before relying on the setting for important traffic.
- Select the intended apps. Use the installed-app list to choose only the apps in your planned group. Some clients display package names or duplicate-looking entries for apps with work profiles, cloned apps, or separate versions. Confirm which installed instance you are selecting.
- Save and reconnect if needed. Apply the change. If the client asks to restart its connection, approve the restart. Otherwise, disconnect and reconnect once so the client can apply the updated rules. Android may show a system prompt when a client first requests VPN permission; grant it only to the client you trust and intend to use.
- Test both groups. Open one app that should use the VPN and one that should connect directly. Check the route from within each app if it offers a reliable connection-status page, or use a suitable network-check page in the relevant browser. A browser test only describes the browser’s route, not every app’s route.
- Repeat after a change. If you switch the routing model, refresh the configuration, reinstall an app, or change profiles, review the app list and test again. Do not assume a previous selection remains correct after the client or installed-app list changes.
Keep the first test simple. Use an app that does not contain sensitive account activity and a second app with a clear, expected connection behavior. Change one setting at a time, save it, reconnect if necessary, and test again. If you change the node, protocol, DNS mode, and app list together, a failure becomes harder to attribute to its cause.
Verify each app’s route and interpret the result
Testing split tunneling means checking the selected app and an app outside the selection. If the client is in inclusion mode, test one included app and one excluded app. If it is in exclusion mode, test one bypassed app and one app that should remain on the VPN. This checks both sides of the policy and helps catch a reversed selection model.
Do not rely on the Android key-shaped VPN indicator as the test result. It normally indicates that an Android VPN connection is active, not that a particular app uses it. Likewise, a page loading successfully does not prove that the app used the intended route. Where available, check the app’s own connection information or use a network test initiated by that app. Compare results only after confirming which app performed the request.
When a browser is used for testing, make sure it is in the intended group. A browser may also use a proxy, secure DNS, or a separate profile that affects the observed result. A browser’s public network address can help identify its route, but it cannot establish the route taken by a game, messaging app, or another application. Test those apps independently when their route matters.
Some apps cache sessions, keep background connections open, or delay network requests until the next refresh. Fully close and reopen the app after changing routing, then try a new request. If a result remains ambiguous, temporarily use a basic test app or a browser configured with no separate proxy. Restore your normal settings after the test and avoid treating a single cached page as proof that the current policy is working.
Record the outcome in plain terms: which app should use the VPN, which should bypass it, what the client’s selection model is, and what happened after reconnecting. This short note makes it easier to distinguish a routing mistake from a node issue, a permission problem, or an app-specific connection failure.
Troubleshoot common split-tunneling problems
A selected app uses the wrong route
Recheck whether the client uses inclusion or exclusion logic. Then confirm that you changed the setting in the profile currently connected, rather than a saved profile that is inactive. Save the rule, reconnect, and reopen the app. If the selected item appears more than once, check whether you chose the normal app, a work-profile copy, or a cloned instance. Also verify that the app has not opened the request in a separate browser.
An app stops connecting after a routing change
Temporarily restore the app to the client’s default routing behavior and test it again. If it works under the default behavior, reapply the intended selection and reconnect. If it still fails, check the client’s connection state, the selected node, and the app’s own network requirements separately. An app may reject a changed network location or depend on a service that is unavailable on the chosen route; that is not necessarily evidence that the app-selection rule failed.
Rules seem to stop working in the background
Check whether Android battery optimization or the device manufacturer’s background-management controls are stopping the client. Menu paths differ by device, so use the system settings search for the client name and review battery or background activity permissions. Allowing the client to operate in the background can help maintain a connection, but it does not guarantee that every app’s own background activity will run. Test after locking the screen and returning to the app, and distinguish a disconnected client from an app that simply has no new background request to make.
Another network tool appears to interfere
Disable other VPN-based apps, local firewalls, traffic filters, or ad-blocking tools while testing. Android may allow one active VPN service to control the device route, so another tool can disconnect the client or take over the VPN interface. Once the split-tunnel behavior is understood, re-enable other tools one at a time and check whether the client remains connected. Avoid changing multiple network tools at once.
Practical conclusion: App-based routing is reliable only when the selection model is understood, the active profile is confirmed, and both selected and unselected apps are tested. If the client does not expose per-app controls, do not infer that the feature exists from subscription compatibility; use a client and Android configuration that explicitly support the behavior you need.
Keep the configuration clear and maintainable
Start with a small, purposeful app list. A long list is harder to review and more likely to contain an outdated app, a duplicate profile, or an exception whose purpose is no longer clear. When your needs change, remove obsolete selections and retest the remaining apps rather than adding exceptions indefinitely. If the client offers named profiles, use names that describe the routing purpose without putting account details or private information in the profile name.
Keep the client and its configuration source up to date, but review changes before applying them to a setup you depend on. A client update can move a setting or change the way a list is presented; a refreshed subscription can update nodes or other configuration without necessarily preserving every local preference. After an update, confirm the active profile, inspect the inclusion or exclusion mode, and run the same two-app test.
If troubleshooting requires help, describe the Android version, client name and version, routing model, whether the affected app is selected, and what happens after reconnecting. Do not post passwords, account tokens, or subscription links. A useful report separates observations from assumptions—for example, “the browser loads, but the selected app cannot connect” is more actionable than “the VPN is broken.” This method helps identify whether the issue lies with app selection, the Android VPN interface, the client configuration, or the app’s own network behavior.