Android VPN Split Tunneling: Set App Rules With This Guide

What split tunneling changes on Android

A VPN app on Android typically creates a virtual network interface through the operating system’s VPN framework. When per-app routing is available, the app can apply rules so that traffic from selected applications enters that interface, while other application traffic uses the normal network. The VPN app, Android version, and configuration determine how those rules are presented and applied.

There are two common approaches. An include list sends only the selected apps through the VPN; apps not on the list use the direct connection. An exclude list sends traffic from most apps through the VPN but leaves selected apps outside it. The labels vary: an app may call these options “Selected apps,” “Bypass VPN,” “Per-app proxy,” or something similar. Read the explanatory text on the screen carefully, because “selected” does not always mean the same thing across clients.

Split tunneling is a routing choice, not a separate encryption mode. An app routed through a properly established VPN tunnel sends its relevant traffic through that tunnel to the VPN exit. An excluded app normally connects over the device’s ordinary network instead. Neither path makes the destination itself trustworthy, and a direct connection does not gain the protection of the VPN tunnel.

Android usually permits one active VPN connection per user or profile at a time. Starting another VPN-based client can disconnect or replace the existing one, so do not assume that two clients can independently apply different app rules at once. A proxy client’s system-proxy mode may behave differently from its VPN or TUN mode; check which operating mode is active before diagnosing per-app routing.

Also distinguish app selection from domain selection. A per-app rule generally chooses a path based on the application that opened a connection. It does not necessarily send one website through the VPN and another website directly when both are opened in the same app. Domain rules, if offered, are a separate feature and may depend on DNS handling and the client’s routing engine.

Choose a routing approach for your apps

Start with the task rather than the longest possible list of exceptions. Decide which apps need the VPN path, which must remain direct, and whether any app should stop working if the VPN disconnects. A small, intentional rule set is easier to understand and troubleshoot than a large collection of exclusions made in response to one temporary problem.

• ✅ Use an include list when only a few apps need the VPN and the rest should stay direct.
• ✅ Use an exclude list when most apps should use the VPN and only a few need a direct connection.
• ✅ Check whether the client applies rules to app traffic, domains, or both; these are not interchangeable.
• ❌ Do not assume an app is direct merely because it is absent from a list until you confirm whether the list includes or excludes apps.
• ❌ Do not run multiple VPN-based clients at the same time and expect their app rules to combine.

Think about dependencies as well as the app’s main screen. A messaging app may use separate components for notifications, media downloads, sign-in, or links opened in a browser. Depending on Android’s package structure and the client’s rule implementation, selecting the visible app may not cover every related service or separately installed companion app. If a function stops working, test the main app and the specific function independently before adding more exceptions.

Some apps use local network discovery, communicate with devices on the same Wi-Fi network, or rely on a system component that behaves differently from the app’s main process. A VPN route can change access to local printers, casting devices, or local web interfaces. If the client offers a local-network bypass or LAN access setting, treat it as a separate routing control and enable it only when needed.

Work profiles, cloned apps, and managed devices can further complicate selection. An app installed in a work profile may appear as a separate instance from its personal-profile version. Device-management policies can also restrict VPN settings or define their own always-on behavior. If the expected app is missing from the selection list, confirm which profile it belongs to and whether the client supports that profile before changing unrelated system settings.

For example, if a browser should use a selected VPN location but a local banking app must remain on the ordinary network, an include list may be easier to audit than a long exclude list. If nearly every app should use the tunnel and only a local-network tool should remain outside, an exclude list may be simpler. The best choice is the one whose meaning you can verify later, not the one with the shortest setup screen.

Configure and test app rules step by step

Before changing settings, note the client’s current mode and rule behavior. If you use a subscription-based proxy client, confirm that the profile is imported and the client is in the operating mode that creates Android’s VPN connection. Importing a subscription alone does not mean traffic is routed; a selected profile must be started, and Android may ask you to approve the VPN connection. Menu names vary between official VPN apps and compatible clients such as Clash-based or sing-box apps, so use the client’s own description when its wording differs from these general steps.

1. Choose one client and connect it. Close or disconnect other VPN-based apps first. Open the client you intend to use, select the correct profile or configuration, and start its VPN mode. Approve Android’s connection request if it appears. Confirm that the client reports an active connection before editing app rules.
2. Open the per-app routing screen. Look in the client’s settings for app routing, split tunneling, included applications, or bypassed applications. Some clients place this under routing or VPN settings rather than on the main connection screen. Read whether the current mode is an include list or an exclude list.
3. Set the smallest useful rule. Select one test app first, then apply the change using the client’s save, confirm, or reconnect control. If the interface says that rules take effect only after reconnecting, stop the VPN and start it again. Avoid changing DNS, protocol, and routing mode simultaneously; changing one variable at a time makes the result easier to interpret.
4. Test both paths. Open the selected app and perform the action that matters, such as loading a page or refreshing content. Then test an app that should take the other path. A connection indicator confirms that the VPN service is active, but it does not prove that a particular app followed the intended route. Where possible, compare a destination or service that can show the apparent connection location, while remembering that cached content, account settings, and the destination’s own policies may affect what you see.
5. Check supporting behavior. Test sign-in, notifications, downloads, and any local-network feature that you rely on. If one fails, temporarily return that app to the default route and repeat the same action. This helps separate an app-specific issue from a DNS, profile, network, or service problem.
6. Record the working setup. Note the include/exclude mode and the apps you selected. If the client can export or back up its configuration, follow its documented method and protect the file as you would any connection configuration. Do not post screenshots that expose account details or subscription information.

As you refine the setup, VPNUPS can be a starting point for checking the service’s available platforms and general connection information; app-by-app behavior still needs to be confirmed in the Android client you actually use. Keep a simple record of which apps are intended to use each path, especially if you switch between profiles or update the client.

When a rule seems ineffective, repeat the test after reconnecting and make sure Android has not switched to another VPN app. Then verify that the application is selected under the correct list type, that the intended profile is active, and that you are testing a new connection rather than content already cached by the app. If the outcome remains unclear, restore the default routing behavior before trying a different client setting.

Android settings and common conflicts

Android’s system VPN settings can affect what happens when a connection drops. Depending on the device and Android version, settings such as Always-on VPN or “Block connections without VPN” (sometimes called lockdown) may be available for the selected VPN app. Always-on behavior can cause Android to restart the VPN service; lockdown can prevent traffic from using a direct route when the VPN is unavailable. That may conflict with an expectation that excluded apps will continue using the ordinary network.

Before enabling lockdown, confirm how it interacts with the client’s app exclusions. If an excluded app cannot connect, temporarily disable the restrictive setting only if it is appropriate for your security needs, then test again. Do not assume the device will automatically fall back to a direct connection: the operating-system setting, client behavior, and app rule can all affect the outcome. On a managed device, an administrator may control these options, so a setting that appears unavailable may be policy-enforced.

Battery optimization and background restrictions can also interrupt a VPN app, especially when Android limits background activity. If the connection drops while the screen is off, first check the client’s connection log and Android’s battery settings for that app. Changing battery restrictions may improve background continuity on some devices, but it does not fix an incorrect app list or prove that traffic used the intended route. Device manufacturers may add their own power-management controls, so consult the device’s settings rather than applying a universal menu path.

DNS is another reason a rule can appear inconsistent. Some clients route DNS through the VPN, while others provide separate DNS options or use system resolution in certain modes. A domain resolving through one path does not by itself establish that the app’s full connection followed the same route. When troubleshooting, avoid changing DNS and app selection at once. First confirm the app’s route, then inspect the client’s DNS settings if name resolution remains the problem.

Updates can alter package names, permissions, available modes, or the client’s settings layout. A system update or a newly installed work profile can also change which apps are shown. After a significant update, review the selection screen and retest the apps that matter rather than assuming that every prior rule remains effective. If the client cannot display an app or apply rules on your device, use its documented support guidance and restore a known working configuration instead of stacking undocumented workarounds.

Troubleshoot without losing track of the route

When an app stops connecting after a routing change, begin with reversible checks. Confirm that the selected profile is active, the device has working internet access, and the app is assigned to the intended include or exclude list. Reconnect the VPN after editing rules if the client requires it. Then test the same app on the same network, so a Wi-Fi-to-mobile switch does not introduce another variable.

If only one app fails, return that app to the default route and test again. If several apps fail, temporarily disable per-app rules and reconnect. A successful test with rules disabled points toward the rule configuration or an interaction with Android’s VPN settings; it does not automatically identify the exact cause. Check client logs if available, but do not share logs publicly without reviewing them for account identifiers, server details, or other sensitive information.

If the device loses internet access, disconnect the VPN from the client and check Android’s always-on or lockdown settings. On a device where direct access is acceptable, restoring the previous system setting can help recover connectivity. If the VPN service will not disconnect normally, use Android’s VPN settings to stop that connection, then reopen one client at a time. Avoid resetting all network settings as an early troubleshooting step because that can remove saved Wi-Fi and other network configuration.

Once connectivity returns, rebuild the rule set gradually: establish a working baseline, add one app, reconnect, and test; then continue only if the result is clear. Keep an untouched default configuration if the client supports profiles. This makes rollback straightforward and prevents a temporary exception from becoming a permanent, unexplained rule.