Android VPN Split Tunneling: Route Apps With Custom Rules

What Android VPN split tunneling changes

Android VPN split tunneling lets you choose which apps send network traffic through a VPN and which use the device’s regular connection. Without app-specific rules, a VPN profile generally handles traffic according to its default routing settings. With split tunneling, you can, for example, send a work app through the VPN while leaving a local banking app outside it. The exact behavior depends on the Android VPN client and its configuration.

Think of a rule as a choice about an app’s network path, not a switch that guarantees the app will work. An app sent through the VPN still depends on its own account, service availability, DNS behavior, and the selected route. An app excluded from the VPN may connect directly through the Wi-Fi or mobile network, which can expose the network’s normal public egress address to that app. Consider this difference before excluding apps that handle sensitive information.

Clients commonly offer one of two approaches: include only selected apps in the VPN, or send all apps through the VPN except those you exclude. The labels vary—look for terms such as “per-app VPN,” “app filter,” “bypass,” or “split tunneling”—and some clients may not provide app-level rules at all. Do not assume that a setting in Android’s system menus is the same as a split-tunneling feature in your VPN client.

Per-app routing can be useful when a local device or service behaves differently behind a VPN, when only particular work tools need the VPN, or when you want to compare an app’s direct and VPN connections. It is less suitable as a set-and-forget fix for every connection problem. If the issue is a wrong account, an app restriction, or a DNS configuration, changing the route may not solve it.

Choose a mode and define the app scope

Before editing a rule, write down the outcome you want. “Keep one app outside the VPN” is more precise than “make the phone faster,” and “send this work app through the VPN” is easier to verify than a broad list of exceptions. Start with the smallest useful set of apps. A shorter list makes it easier to understand which connection path is responsible if a service stops working.

In an include-only mode, the apps you select use the VPN and other apps may use the ordinary network. In an exclude mode, the VPN handles traffic by default and selected apps bypass it. These descriptions explain the intent, but the client’s own wording and documentation determine the actual behavior. Check whether the choice applies to all profiles or only the profile currently selected, and whether a profile change replaces or preserves its app list.

Make a deliberate decision about browsers, messaging tools, cloud storage, and apps that hand work to another app. A browser may open a link in a separate application; a file manager may call a cloud-storage app; a work app may rely on a browser for sign-in. If only one of those apps follows the VPN rule, the complete task may use more than one network path. When you are comparing VPN options and client platforms, the VPNGrow home page is a starting point for reviewing the service context; it does not determine how a particular Android client implements app rules.

• ✅ Prefer an allowlist when only a small, known group of apps should use the VPN.
• ✅ Prefer an exclusion list when most apps should use the VPN and only a few need direct access.
• ✅ Include companion apps when a task moves between apps, and test the whole task rather than just its first screen.
• ❌ Do not exclude an app simply because it shows an error; first identify whether the error is actually caused by its network route.
• ❌ Do not treat an excluded app as protected by the VPN. It may connect over the ordinary network instead.

Also check Android’s always-on VPN and lockdown settings. On devices where lockdown blocks connections outside the VPN, an app configured to bypass the VPN may have no usable network access while lockdown is active. The names and location of these system controls vary by Android version and device manufacturer. If a client offers to manage an always-on or lockdown option, read the prompt before accepting it; system-level behavior can affect more than the selected app.

For managed devices, a work profile, device administrator, or organization policy may restrict VPN settings. Some apps may also use more than one package or rely on background components. If the client’s app list is unclear, do not guess by selecting similarly named entries. Confirm the package or app identity in Android settings, and consult the client’s documentation for limitations on work profiles or cloned apps.

Configure per-app rules step by step

Menu names differ across VPN clients, Android releases, and device manufacturers, so use the following sequence rather than expecting an identical screen. Make one change at a time and keep a note of the original mode and selected apps. That gives you a straightforward way back if a sign-in, notification, or local service stops working.

1. Connect using the normal profile first. Confirm that the VPN connects and that the target app can perform its usual task before changing app rules. If it already fails, record the error and troubleshoot the basic connection separately.
2. Open the active profile’s settings. In the VPN client, look for per-app routing, split tunneling, app selection, or bypass settings. Verify that you are editing the profile you actually use; some clients keep separate rule sets for different profiles.
3. Select the routing mode. Choose whether selected apps should use the VPN or selected apps should bypass it. Read any description beside the control, because “selected apps” can mean different things in include and exclude modes.
4. Pick only the apps needed for the test. Search by the app’s displayed name and check each selection carefully. If the client lists system apps or duplicate entries, leave unfamiliar entries unchanged until you know what they do.
5. Save or apply the rule, then reconnect if prompted. Some clients apply changes immediately; others require you to reconnect the VPN. Follow the client’s prompt and wait for the connection status to settle before testing.
6. Test one app and one task. Open the chosen app and perform a normal, low-risk action. Then test an app that should use the opposite path. This helps catch a reversed include/exclude choice before you add more rules.
7. Record the working setup. Note the profile, routing mode, selected apps, and any relevant Android lockdown setting. A short record is useful after a client update or profile change.

Do not use an app’s loading screen alone as proof that a rule works. A page may be cached, an account may already have an active session, or the app may not make a network request until you refresh or start a new task. Where the app provides a connection or account status page, use it alongside a fresh request. A network-check tool can offer another clue, but a result from one browser does not prove that every other app follows the same route.

If the VPN client supports importing a profile or subscription, treat app-routing rules as client-side settings unless the provider explicitly documents otherwise. A profile update, reinstall, or switch to another compatible client may not preserve local app selections. Recheck the rules after such a change instead of assuming that the same subscription automatically recreates them.

Verify both paths without confusing the results

Testing should answer two separate questions: does the intended app connect, and does it use the intended route? Start with the VPN connected and make a fresh request in an app that should use it. Then check an app meant to bypass it. If your test relies on a public IP or region display, run it inside the app or browser whose path you are checking; a result from one app cannot establish the route used by another.

For a clearer comparison, keep the VPN profile and network constant while testing the selected rule. Avoid changing the Wi-Fi network, mobile data, DNS settings, and app list together. If several variables change at once, a successful or failed request will not show which change mattered. You can temporarily turn the VPN off as a baseline only when appropriate, then reconnect before checking the final configuration.

• App should use the VPN: confirm the VPN client is connected, reopen the app or start a fresh request, and check the route from within that app where possible.
• App should bypass the VPN: confirm the client still shows a VPN connection for other traffic, then make a fresh request in the excluded app and check its network result separately.
• App hands off to another app: test the complete flow, such as opening a link or completing sign-in, and verify the companion app’s rule too.
• Background behavior matters: check whether notifications or background sync work after the change, because a foreground screen alone does not test those tasks.

Remember that DNS handling can complicate interpretation. A VPN client may route an app’s traffic through the tunnel while applying DNS settings at a different scope, or an excluded app may use the device’s ordinary DNS path. Do not infer DNS privacy from a successful page load. If your concern is DNS, check the client’s documented DNS behavior and test with a method that reports DNS resolution rather than relying only on a page’s displayed location.

Repeat the check after changing profiles, switching between Wi-Fi and mobile data, or updating the VPN client. Android may pause or restart network connections during these transitions, and some apps keep existing sessions open. A fresh request is more informative than an old connection that began before the rule changed. Keep notes about what you changed and what you observed; do not claim a route is verified merely because the app opened once.

Troubleshoot failures and restore the default setup

If an app loses access after you add a rule, first determine whether it was included or excluded and whether that choice matches the mode. A selection that means “use the VPN” in one mode may mean “bypass the VPN” in another. Return to the active profile, inspect the mode label, and temporarily remove the new exception. Reconnect if required, then retry the app before making another change.

If the app works with the VPN off but not through the VPN, check the selected profile and route before changing several settings at once. If it works through the VPN but not when excluded, check Android’s always-on and lockdown configuration, then confirm that the device has ordinary network access. Neither result proves a service is universally reachable or blocked; it only narrows down the conditions of your test.

Other common causes include an outdated client, a profile that did not save, a work-profile copy of the app, or a related app that is missing from the rule. Force-closing and reopening the affected app can help it establish a new connection after a route change. If the problem remains, restore the original rule, capture the client version, Android version, active profile, and the steps that reproduce the issue, then contact the client’s support channel. Avoid sharing passwords, authentication tokens, or subscription links in screenshots or public messages.

To return to a simple default, disable the app filter or choose the client’s documented default mode, clear only the custom app selections you added, and reconnect. If you changed Android’s always-on or lockdown setting, restore that separately to the state you recorded. Then test a normal app connection and confirm that the VPN client reports the expected connection state. Reinstalling the client is usually a less precise first step because it may remove local profiles or other settings without identifying the cause.

• ✅ Keep a copy of the original mode and app selections before experimenting.
• ✅ Change one rule, reconnect when prompted, and test immediately.
• ✅ Review companion apps and work-profile copies if only part of a task fails.
• ❌ Do not leave an app excluded just to silence an error without considering its direct-connection consequences.
• ❌ Do not assume a client update preserved every local rule; inspect the active profile again.

A practical rule set should be understandable later, not just functional today. Use clear, limited exceptions; document why each one exists; and remove a rule when the need disappears. If you cannot tell which app is using which path, return to the default configuration and test again with fewer variables. That approach makes per-app routing easier to maintain while reducing the chance that a troubleshooting shortcut quietly changes how an app connects.