Android VPN Split Tunneling: Set App Rules The Right Way

Android VPN split tunneling lets you choose which apps use a VPN connection and which connect through the device’s regular network. It can be useful when a browser needs a VPN route but a banking app, local streaming service, or smart-home app works better with a direct connection. The key is to understand what your client means by “include” and “exclude,” apply one small rule change at a time, and test the affected apps rather than assuming the setting worked.

Split tunneling is an app-routing choice, not a second VPN connection. Apps excluded from the tunnel generally use the network path available outside it, while included apps send traffic through the selected VPN route. Exact behavior depends on the Android version, VPN client, configuration, and any restrictions imposed by the app itself. A connected indicator alone does not confirm that a particular app used the route you intended.

What split tunneling controls on Android

An Android VPN client typically creates a system-managed VPN interface and asks Android to direct traffic through it. When the client offers per-app rules, it uses Android’s VPN capabilities to select applications. Depending on the client, you may see a list of installed apps, a mode for choosing apps that use the VPN, or a mode for choosing apps that bypass it. The labels and available options differ, so read the mode description before selecting anything.

In an “include selected apps” mode, only the apps you choose are intended to use the VPN; other apps ordinarily use the regular network. In an “exclude selected apps” mode, apps you choose are intended to bypass the VPN and the remaining traffic uses it. These modes can produce opposite results from the same list of checked apps. Do not infer the meaning from a checkbox alone: check whether the screen says “use VPN for selected apps,” “bypass VPN for selected apps,” or something similar.

Per-app selection is also different from choosing a proxy mode inside a browser or app. A browser’s built-in proxy setting may affect only that browser, while Android’s VPN rule is applied by the VPN client at the device networking layer. An application can still use its own proxy, a separate account-specific connection, or a different networking method. Those app-level settings can make its observed route differ from what you expected from the VPN list.

Android generally permits one active VPN service per user or profile at a time. Starting another VPN client may disconnect or replace the first, so do not try to combine two consumer VPN apps to create separate routes for different apps. Work profiles, managed devices, and enterprise policies can add their own controls, but their behavior is determined by the administrator and device configuration.

Choose a policy before changing app rules

Start with the smallest policy that solves the actual problem. If just one app needs to connect directly, an exclude-selected policy may be easier to maintain than selecting every app that should use the VPN. If only a few apps need the VPN, an include-selected policy may be clearer. Neither approach is universally safer or more reliable; the right choice depends on how many apps you need to route and how the client handles apps installed later.

Write down the intended behavior in plain language before opening the settings. For example: “The work browser should use the VPN; the local payment app should connect directly.” That statement is more useful than “turn on split tunneling,” because it gives you something concrete to test. Also decide what should happen to newly installed apps. Some clients leave them outside the VPN in include mode; others may provide a default or prompt. Review the app’s explanation rather than assuming new apps inherit a particular rule.

• ✅ Use include mode when a small, clearly defined set of apps needs the VPN route.
• ✅ Use exclude mode when a small, clearly defined set of apps needs a direct connection.
• ✅ Keep a note of each app’s intended route so you can restore the previous behavior.
• ❌ Do not select apps based only on their icons or names; check the publisher and package if duplicates appear.
• ❌ Do not change several routing, DNS, and protocol settings at once, because that makes failures harder to isolate.

Think about the data handled by direct-connection apps. An excluded app does not receive the VPN route merely because the VPN remains connected for other apps. Its traffic may use your Wi-Fi or mobile carrier connection, subject to the app’s own encryption and network behavior. A VPN does not replace the app’s account security, and a direct route may reveal a different public network address to the service.

If you are comparing VPN clients or checking how subscription-based configuration works, the LQVPN site provides the service’s general starting point. Client-specific split-tunneling controls still need to be checked in the Android app you actually use; a website description cannot confirm the options on your device.

Configure and test app rules

Use this sequence as a general procedure. Menu names vary between Android releases and client versions, so treat the wording as a guide rather than an exact path. Before you start, note the current rule mode and selected apps. If the client offers a configuration export or profile backup, use it before making a change that would be difficult to recreate.

1. Connect to a known route. Open the VPN client, select the route you intend to use, and connect. If the connection does not establish, fix that first; split-tunnel rules cannot be meaningfully tested while the tunnel itself is disconnected.
2. Find the per-app controls. Look in the client’s settings for app routing, split tunneling, per-app proxy, or a similarly named option. Confirm that the feature applies to applications on this Android device rather than to a different profile or a manually configured proxy.
3. Read the selection mode. Determine whether selected apps go through the VPN or bypass it. If the client offers both modes, choose the one that matches your written routing plan. Do not switch modes and keep the same selections without reconsidering what those selections mean.
4. Change one rule. Select one test app first. Save or apply the setting, then reconnect if the client asks you to. Some clients apply changes immediately; others rebuild the VPN configuration or require a connection restart.
5. Test the app while connected. Open the chosen app and perform the specific action that was failing, such as signing in, loading a page, or reaching a local device. A home screen that opens from cache is not enough to prove that a fresh network request succeeded.
6. Compare the route where practical. If the app exposes a network diagnostic or public-address check, compare the result with the expected VPN or direct route. A browser-based address check only reports the browser’s path; it does not prove that another app used the same route.
7. Test both connection states. Check the app with the VPN connected and, when appropriate, with it disconnected. This helps distinguish a split-tunnel rule problem from an app outage, account restriction, weak Wi-Fi signal, or general mobile-network issue.
8. Expand gradually. Once the first app behaves as expected, add the remaining apps in small groups and test them. If behavior changes, remove the most recent rules and repeat the check to identify the cause.

For each test, record the app, rule mode, connection state, network type, and observed result. This lightweight record is especially useful when a client update changes labels or resets preferences. It also prevents a common troubleshooting loop: repeatedly switching the same checkbox without knowing which state was active during the last test.

Be cautious when testing sensitive apps. A payment or banking app may apply its own security checks and reject a connection for reasons unrelated to the VPN route. If it fails, first verify the rule, then test the app’s normal connection requirements. Do not disable account protections or share credentials with anyone offering to “fix” the routing.

Verify DNS, Android settings, and app behavior

App selection controls which applications the client intends to route through the VPN, but it does not explain every network request. DNS resolution, IPv6 handling, private DNS, background services, and app-specific networking can affect what you observe. The client may route DNS differently from ordinary app traffic, and the test site or diagnostic tool may use a method that does not match the app you are investigating. Treat a single successful address check as one piece of evidence, not a full audit of every connection.

Android’s system VPN options may include “Always-on VPN” and a setting to block connections without the VPN. These options are designed around system-level VPN behavior, not as replacements for per-app routing controls. If blocking connections without a VPN is enabled, an app that you intended to exclude may be unable to connect directly, depending on the client and Android configuration. Review those settings if an excluded app has no connectivity, and understand the security trade-off before disabling a restriction.

Private DNS can also affect troubleshooting. Android’s Private DNS setting is separate from a client’s per-app list; changing it may alter name resolution across the device and make a previously working route appear broken. Unless DNS is the issue you are testing, leave it unchanged while checking app rules. If you do need to diagnose DNS, change one setting at a time and restore the original value if the test does not help.

Applications may use background components or companion services that do not appear under the name you expect. A browser, for example, can include separate components for downloads, media playback, or account services; some may share a package while others may be separate. A system app can also have network activity even when its visible interface is closed. If a rule list contains unfamiliar entries, avoid excluding broad system components without understanding what depends on them.

Network changes matter. Wi-Fi and mobile data can have different DNS behavior, local-network access, and carrier restrictions. Repeat a relevant test on the network where the problem occurs, but keep the VPN route and app rules otherwise unchanged. If the issue appears only on one network, that is useful evidence; it does not by itself prove that the app rule is incorrect.

These figures describe a cautious testing sequence, not a performance guarantee. The purpose is to make the result attributable: establish the tunnel, change one app rule, and compare the app’s behavior across connected and disconnected states. If you change the route, DNS, and selection mode together, it becomes much harder to know which change affected the result.

Troubleshoot or undo a rule safely

If an app stops connecting after a routing change, first return to the client and confirm the active mode. A checked app can mean “included” in one mode and “excluded” in another. Then remove only the latest rule or restore the app’s previous selection, apply the change, and reconnect if requested. Test the app again before changing additional settings.

If the app still fails, temporarily disable split tunneling or restore the client’s previous app-routing configuration. This is a diagnostic step, not necessarily the final setup: it can show whether the problem is associated with per-app selection. If the app works with the feature off, rebuild the rules gradually. If it still fails, investigate the VPN connection, chosen route, app service, account status, and local network separately.

• Check that the VPN client is the only active VPN service and that Android has not disconnected it.
• Confirm that the app is not selected in the opposite mode from the one you intended.
• Close and reopen the affected app after applying a rule; some apps keep existing network sessions alive.
• Check Always-on VPN and blocking settings if direct-route apps cannot connect.
• Restore any DNS or protocol settings changed during troubleshooting before testing the rule again.
• If a client update reset the configuration, recreate the policy from your written routing plan rather than relying on memory.

When you no longer need a special route, remove the app from the include or exclude list, restore the intended default mode, and reconnect if the client requires it. Verify both the previously affected app and one app that should continue using the VPN. This final check can catch an accidental mode reversal that would otherwise affect more applications than the one you were trying to fix.

Split tunneling is most predictable when the policy stays simple and each exception has a clear reason. Start with one app, verify its route using an app-specific test, and keep system-wide DNS and VPN restrictions unchanged unless they are directly relevant. If a rule causes unexpected behavior, undo that rule first; changing several unrelated controls at once usually makes diagnosis slower.