Android VPN Split Tunneling: Set App Rules With Ease

Android VPN split tunneling lets you decide which apps use a VPN connection and which connect directly. It is useful when, for example, you want a browser to use a selected VPN route while a local banking app or a work app stays on its normal connection. The exact controls depend on the VPN client: some let you choose apps inside or outside the tunnel, while others do not offer app-based rules at all.

The important part is to confirm the rule’s meaning before connecting. “Include selected apps” and “exclude selected apps” sound similar, but they produce opposite results. Android settings, client labels, and menu locations can also differ by app version and device manufacturer. This guide explains the common approaches, a careful setup process, and ways to diagnose unexpected routing without discarding your original configuration.

How Android app-based split tunneling works

On Android, a VPN app normally requests permission to create a system VPN connection. When the connection is active, Android displays a VPN indicator and routes traffic according to the VPN app’s configuration. If the client supports app-based split tunneling, it can apply a rule to selected apps: their traffic either goes through the VPN connection or bypasses it and uses the device’s ordinary network path.

This is different from a website or domain rule. An app-based rule selects an installed Android app, not a particular account, website, browser tab, or type of content. If you put a browser on the VPN list, its connections generally follow that app rule; the client may not be able to distinguish one site from another inside the browser. Conversely, selecting a messaging app does not necessarily control a separate browser or helper app that the service uses for sign-in.

Clients commonly present one of two rule strategies. With an inclusion list, only the selected apps use the VPN and other apps connect directly. With an exclusion list, most apps use the VPN while selected apps bypass it. These options are alternatives, not two names for the same setting. Read the screen’s description carefully and note whether the client says “use VPN for selected apps,” “bypass VPN for selected apps,” or similar.

Android generally has one active VPN connection at a time. Starting another VPN app may disconnect or replace the existing connection, so running two VPN clients in an attempt to assign different apps to each one is not a reliable split-tunneling method. Other network tools, such as a work profile, device management software, or a private DNS configuration, can also affect what you observe.

App rules are also separate from route selection and protocol choice. A selected app may enter the VPN, but the client still determines the available server, connection mode, DNS behavior, and other routing details. If an app continues to fail, changing the app list alone may not address a server-side restriction, an account-region setting, or a conflict with another network policy.

Choose which apps use the VPN

Start from the task you want to accomplish rather than adding every installed app. If only a small number of apps need the VPN, an inclusion list can be easier to review: choose those apps, then check that ordinary local services remain accessible. If most apps should use the VPN and only a few need a direct connection, an exclusion list may be simpler. The right choice depends on the client’s actual behavior and your daily app use.

• Choose inclusion rules when you want a limited set of apps to use the VPN and prefer other apps to remain direct by default.
• Choose exclusion rules when you want most apps to use the VPN but need specific apps to bypass it.
• Check the consequences of a direct route before excluding a work, payment, or personal app. A direct connection uses the network you are currently on, which may be public Wi-Fi or a mobile network.
• Check related apps separately. A service may use a main app, a browser for authentication, or another installed component. A rule for one app does not automatically guarantee that associated traffic follows the same route.

Do not treat “direct” as synonymous with “more private” or “more secure.” A bypassed app no longer uses the VPN tunnel, but it still uses its normal connection and the protections provided by that network and the app itself. Likewise, putting an app on the VPN list does not guarantee that every feature will work: the app may reject a route, rely on a region or account setting, or use a connection path affected by Android or the device manufacturer.

Before changing a rule, record the current mode and selected apps. A short note or screenshot gives you a way back if a menu label is unclear or a test produces an unexpected result. If you are comparing client options or need to check which official client is available for your device, the VPN72 home page is a sensible starting point; confirm feature availability in the client you actually install rather than assuming that all clients expose identical controls.

Set up and test the app rules

Menu names vary, so treat these as functional steps rather than a promise that every Android client uses the same labels. Depending on the app, the controls may appear under Settings, Connection, VPN settings, Split tunneling, Per-app settings, or an advanced section. If you cannot find them, check the client’s help text and version first. Do not substitute a similarly named system setting without confirming that it controls the VPN client’s app list.

1. Check the starting state. Connect to your usual network and note which apps currently work. Disconnect any other VPN client before testing. If your device is managed by an employer or school, check whether its network policy restricts changing VPN settings.
2. Open the split-tunneling controls. In the VPN client, find the app-selection screen. Read the explanatory text and identify whether the list means “send selected apps through VPN” or “let selected apps bypass VPN.” If the interface offers a mode selector, choose one mode deliberately rather than assuming the default.
3. Select only the apps needed for the first test. Keep the initial list small so you can tell which rule is responsible for a change. Use the app’s visible name and icon to avoid selecting a similarly named app. If a desired app is absent, check whether the client filters system apps or whether the app has been installed in a separate work profile.
4. Save or apply the list. Some clients apply changes immediately; others require you to confirm, reconnect, or restart the VPN session. Follow the client’s prompt. If Android asks for VPN permission, approve it only for the client you intend to use.
5. Connect and test one app from each group. Open an app that should use the VPN and verify that it can complete a normal task. Then test an app that should bypass it. A screen loading is useful evidence, but it does not by itself prove which route the app used.
6. Change one thing at a time. If a test fails, first confirm the active rule mode and connection status. Then adjust one app or setting, reconnect if required, and repeat the same test. Avoid resetting the whole client before checking the saved list.

For a more useful test, compare a consistent task before and after connecting: sign in, refresh a page, send a message, or load a service you already use. If the client provides a route or connection diagnostic, use it alongside the app test. A general IP-check page opened in a browser only reports the browser’s route; it does not demonstrate that a separate app is using the same route.

Also distinguish app-rule failure from service failure. If the selected app cannot connect, temporarily switch its rule to the opposite group or test a different known-working app, then restore the original choice. If the app works only when direct, the issue may involve the selected route, the app’s network requirements, or a separate policy. If it fails both ways, the split-tunneling rule may not be the cause.

Understand Android settings and client differences

Android versions and manufacturer interfaces do not present VPN controls in exactly the same place. A client may provide its own app list, while Android’s system settings show only whether a VPN is connected, which app owns it, and options such as always-on VPN or blocking connections without a VPN. These system-level options are not necessarily the same as the client’s split-tunneling list.

Always-on VPN and lockdown behavior deserve particular care. When a device is configured to block connections that do not use the VPN, an app intended to bypass the tunnel may be blocked rather than allowed to connect directly. The exact interaction depends on Android version, client implementation, and device policy. If you enable lockdown, verify that the apps you expect to access the direct network still work; do not assume an exclusion rule overrides a system-wide block.

Work profiles can also complicate selection. Android may show personal and work copies of an app separately, and an organization may manage network access within the work profile. A personal copy’s rule may not apply to its work-profile counterpart. Similarly, app cloning, private spaces, and manufacturer-specific dual-app features can create a separate instance that the VPN client lists under a different name or does not support.

Battery and background restrictions can make the behavior seem inconsistent. If an app is paused or prevented from running in the background, it may not reconnect promptly after a VPN rule changes. Test while the app is open, check the device’s battery and background settings if necessary, and then repeat after reconnecting. Avoid changing unrelated battery settings as a first step, because that can obscure the cause.

Some clients apply app rules only when a new VPN session starts, while others update the active session. If you edit the list and see no change, disconnect and reconnect once, then repeat the test. If the controls are missing entirely, the client may not support app-based rules on that Android version. A desktop client’s split-tunneling features do not establish that its Android counterpart offers the same controls.

Troubleshoot unexpected routing safely

When traffic appears to take the wrong path, work from the simplest explanations to the more complex ones. First check that the intended VPN client is connected and that Android’s VPN indicator belongs to that client. Next reopen the app list and verify both the selected apps and the inclusion or exclusion mode. A correct list interpreted in the opposite mode can produce the exact opposite of the intended result.

• ✅ Confirm which VPN client currently owns the Android connection.
• ✅ Recheck the rule mode, selected app, and whether changes require reconnecting.
• ✅ Test the same app after reconnecting, then compare it with one app in the other rule group.
• ✅ Check work-profile copies, always-on settings, lockdown, and device-management restrictions when relevant.
• ❌ Do not run a second VPN client to try to divide apps between two active tunnels.
• ❌ Do not delete the app list or reset network settings before saving your current configuration.

If a browser appears to bypass the VPN, make sure you are testing the browser you selected and not a separate browser instance or work-profile copy. If a service opens but a particular feature does not, the app may use another component, or the service may apply its own account, region, or security checks. Test a simple connection separately from sign-in, media playback, uploads, or other features that may use different endpoints.

For an app that loses connectivity only when included, reconnect and try a different VPN route if your client offers one. Keep the app rule unchanged during that comparison so you can isolate the cause. If the problem persists across routes but disappears when the app is direct, note the app name, Android version, client version, rule mode, and whether lockdown is enabled before consulting the client’s support resources. Do not share account credentials or sensitive traffic details.

If an excluded app still seems to use the VPN, check whether the client interprets the list as an inclusion list, whether the app is using a separate profile, and whether the test is actually being performed in that app. Then disconnect and reconnect as the client requires. If you cannot determine the rule’s effect, revert to the recorded original configuration and test with one app at a time instead of making several changes together.