Android VPN Split Tunneling: Choose Which Apps Use the VPN

Android split tunneling lets you choose which apps send their traffic through a VPN connection and which apps connect directly. It is useful when one app needs a remote route but another works better with your ordinary connection, such as a local banking app, printer utility, or workplace tool. The setting is usually controlled by the VPN client, not by a universal Android switch, so the exact labels and available options depend on the client and Android version.

The important distinction is that “connected” only confirms that a VPN session is active. It does not confirm that the app you care about is using that session. To configure split tunneling reliably, decide which apps need the VPN, set the client’s routing policy, and test each app separately. Keep a note of the original setting so you can restore it if an app stops working.

Understand Android split tunneling

On Android, a VPN client generally uses the system’s VPN service to create a connection for the device. A client can then apply app-level rules so that selected applications use the tunnel, while other applications use the device’s regular network route. Depending on the client, you may see this feature described as split tunneling, per-app routing, app rules, included apps, or excluded apps.

There are two common ways to express the rule. An inclusion list means only the apps you select use the VPN; everything else is routed directly. An exclusion list means the VPN handles traffic by default, except for the apps you select. These approaches can produce different results even when the same app names appear on screen. Read the client’s description carefully and check whether the selection means “use VPN” or “bypass VPN.”

Android’s own VPN controls and a VPN client’s app-routing controls are related but not interchangeable. Android settings may show the active VPN, provide a system-level always-on option, or offer a lockdown option that blocks traffic outside the VPN. Those controls do not necessarily provide the per-app selection you want. Always-on and lockdown settings can also make direct-bypass rules behave differently or prevent bypass traffic, depending on the Android version and client implementation.

Before changing anything, identify whether your client uses an inclusion list or an exclusion list. A reversed interpretation can send the exact apps you meant to bypass through the VPN—or leave the apps you wanted protected on a direct route.

Choose apps and a routing policy

Start with the reason for using split tunneling rather than with a long list of applications. Decide which app needs the VPN route, which app needs a direct route, and what should happen to all remaining apps. This helps you choose between an inclusion list and an exclusion list without relying on assumptions about how a particular client interprets its controls.

For example, you might want a browser or media app to use the VPN while a local payment app connects directly. In another situation, you might want most apps to use the VPN and exclude only an app that depends on a local network or does not work through the remote route. These are routing choices, not guarantees that an app will work: the app can still have its own network restrictions, login requirements, or connectivity problems.

• ✅ Use an inclusion list when only a small, clearly identified group of apps needs the VPN route.
• ✅ Use an exclusion list when broad VPN routing is your intention and you have a specific reason to keep certain apps direct.
• ✅ Keep local-network tools, such as device discovery or printer apps, in mind when testing direct access.
• ❌ Do not assume an app is bypassing the VPN just because it appears in a list; confirm what the selected list means.
• ❌ Do not run multiple VPN clients at the same time and expect their app rules to combine. Android normally allows one active VPN service at a time.

Check whether the client applies its rule to the app itself or to traffic captured by the VPN interface. Some applications use companion processes, browser components, or system services for network requests. A client may show the main app in its list without making every related background request behave exactly as expected. If a specific feature fails, test the main app and the feature that depends on it rather than treating the app’s icon as proof of a complete route.

Also consider DNS and local network behavior. An app can use a different route from the one you expect if its requests are handled outside the client’s capture scope, or if a DNS request follows a different policy. Access to a printer or another device on the same Wi-Fi may be affected by full-tunnel behavior, client settings, or Android permissions. Avoid changing unrelated DNS, battery, or network settings until you have established which app and route are actually failing.

When comparing client options, VPNRQ provides the service context, while the Android client determines how its per-app controls are presented. Import the configuration using the supported client workflow, then make routing changes in that client rather than assuming a subscription profile itself contains your personal app selections.

Configure and test on Android

Menu names differ between Android releases, device manufacturers, and VPN clients. Treat the following as a safe workflow rather than a promise that every phone has identical screens. If the client offers a built-in guide, use its instructions for the specific control labels shown on your device.

1. Record the current state. Note whether the VPN is connected, which general routing mode is active, and whether Android’s always-on or lockdown option is enabled. If the client already has an app list, capture or write down the selected apps before editing it.
2. Choose a test app. Pick one app whose route you can check independently. Avoid changing many app rules at once; a single test makes it easier to identify the setting that caused a change.
3. Open the client’s app-routing controls. Look for split tunneling, per-app settings, included apps, or excluded apps. Read the explanatory text and establish whether selecting an app sends it through the VPN or bypasses the VPN.
4. Set a small rule. Select the test app according to the policy you chose. Save or apply the setting if the client requires it, then reconnect the VPN if prompted. Some clients apply changes immediately; others may need the tunnel restarted.
5. Check Android’s VPN prompt and status. Approve the system VPN connection if Android displays a permission request. Confirm that the intended client is the active VPN, especially if you previously used another VPN or a work profile.
6. Test the selected app and a comparison app. Open the selected app and perform the action that needs the route. Then test an app expected to use the other route. Use a route or network diagnostic that can distinguish the intended connection; an app loading successfully by itself does not prove which path it used.
7. Change one rule at a time. If the result is wrong, change only the relevant inclusion or exclusion and repeat the test. This avoids confusing a routing-rule issue with a separate app, account, or network problem.

For a useful comparison, keep the test conditions as consistent as possible: use the same Wi-Fi or mobile connection, the same app, and the same requested destination. First test with the VPN disconnected, then test with the VPN connected and the app rule enabled. If the client provides connection details or rule-match information, check whether the app’s traffic matched the expected route. Avoid relying only on a speed test, because its result may reflect the test server, the local network, or an app’s own behavior rather than the per-app rule.

After the test works, add other apps gradually and verify each one. This is especially helpful when some apps need local access while others need a remote route. If you make a broad change and immediately test many services, a failure can be difficult to trace back to a particular app selection or system option.

Verify the route and protect local access

Verification should answer two separate questions: is the VPN connected, and is the particular app using the route you intended? Android’s VPN indicator or the client’s connected status answers only the first question. A successful web page, login, or media stream is also not conclusive by itself, because the service may work through either route.

Use several independent clues where possible. Check the VPN client’s status and any available rule-match details. For an app expected to use the VPN, compare its connection behavior with the VPN disconnected and connected. For an app expected to bypass the VPN, check whether it can reach the local service or endpoint that motivated the exception. If the app offers an account, region, or network diagnostic, use that information as supporting evidence, not as the sole test.

Local network access deserves a separate check. With the VPN active, try the exact local task you care about, such as finding a printer or controlling a device on the same Wi-Fi. If it fails, first confirm that the app is assigned to the intended route. Then check whether the client has a setting for local-network access or LAN traffic. The label and behavior vary by client, so do not copy a setting name from instructions for a different application.

Android may also restrict background activity. Battery optimization, data-saver behavior, work profiles, and manufacturer-specific power management can affect whether an app stays connected or receives background updates. These symptoms can look like a routing failure even when the rule is correct. Test the app in the foreground first. If only background activity fails, investigate the device’s background restrictions separately and change only the relevant permission or battery setting.

Be cautious with always-on VPN and lockdown. Always-on can make Android attempt to reconnect the VPN automatically. Lockdown can block traffic that does not use the VPN. If your goal depends on selected apps connecting directly, a system setting that blocks non-VPN traffic may conflict with that goal. Do not disable protective controls without understanding the consequence; instead, check the client and Android documentation to see whether the desired app-level policy is compatible with those controls.

Troubleshoot and reset app rules

If an app cannot connect after you enable split tunneling, first identify which route it should use. A mismatched inclusion or exclusion list is a common source of confusion. Remove the app from the current list or switch the policy only after checking the client’s wording, then reconnect and test again. If you are unsure what changed, restore the original list rather than making several speculative adjustments.

When a VPN-routed app fails

Confirm that the VPN is connected and that the app is selected for the VPN route. Check whether the client requires you to apply the setting or reconnect after editing it. If the app still fails, test it with the VPN disconnected to distinguish a general app or network issue from a route-specific one. You can also try a different supported connection profile or location if the service provides options, but change one factor at a time so the test remains informative.

When a direct app still uses the VPN

Confirm that the client uses an exclusion list and that the app appears in the bypass group. Check whether Android’s lockdown option blocks direct traffic, and whether the client’s mode captures traffic more broadly than expected. Force-closing and reopening the app can help it establish a fresh connection after a rule change; do not assume that an already-open connection will immediately follow a new route. If the client offers a reconnect control, use it before repeating the test.

Restore a known-good configuration

To reset safely, return to the client’s split-tunneling screen and remove the experimental selections or use its reset option if available. Restore the previous routing mode, reconnect the VPN, and test a familiar app. If the original state is unknown, temporarily turn off split tunneling and verify ordinary VPN operation before adding a small number of rules again. Check Android’s always-on and lockdown settings separately so that restoring the client list does not leave an unexpected system-level restriction in place.

If the problem persists, collect useful details before contacting support: Android version, device model, client name and version, whether the issue happens on Wi-Fi or mobile data, the selected routing mode, and the affected app. Do not send passwords, private account data, or subscription links in a public post. A clear description of the intended route and the observed result is more useful than simply reporting that “the VPN is slow” or “the app is blocked.”

• ✅ Save or record the working app list before testing a new rule.
• ✅ Reconnect the tunnel when the client requires it, then retest the same app and task.
• ✅ Separate routing problems from Android background restrictions and general network failures.
• ❌ Do not clear all client data as a first troubleshooting step; you may remove useful configuration and diagnostics.
• ❌ Do not leave an experimental rule enabled if you cannot explain which apps it affects.

Split tunneling is most predictable when the policy is simple, the app list is short, and each route is verified with a real task. Begin with one app, confirm whether it uses the VPN or connects directly, and then expand the configuration only when you have a clear reason. If an app’s behavior changes after an Android or client update, review the rule and test again rather than assuming the previous selection still produces the same result.