Android VPN Split Tunneling: Set App Rules With This Guide

Android split tunneling lets you choose which apps use a VPN connection and which use the device’s regular network route. It is useful when one app needs a VPN route while another depends on a local service, a nearby device, or a connection that works better without the VPN. The exact controls vary by client and Android version, so treat this as a workflow rather than a promise that every app exposes the same switches. First confirm that the VPN connects normally; then set app rules and test them one app at a time.

A connected indicator alone does not prove that the rules work as intended. Some clients apply app selection when a connection starts, while others require you to reconnect after changing it. Android system settings such as Always-on VPN can also change what happens to excluded apps. Knowing the difference between the two routing modes will make setup easier to troubleshoot.

Understand the Two App-Routing Modes

Most per-app VPN controls offer an include mode and an exclude mode, although the labels differ. In include mode, only the apps you select are sent through the VPN; other apps use the ordinary network connection. In exclude mode, the selected apps bypass the VPN and the remaining apps use it. Read the explanatory text in the client before saving: a setting called “selected apps” is not enough to tell you which route those apps will take.

The “2” refers to the common include and exclude approaches, not two simultaneous lists. At the Android VPN API level, an application list is generally configured as an allowed list or a disallowed list for a given VPN connection; clients usually present one mode at a time. If the app offers only one mode, that may be a client or system limitation rather than a missing Android setting. Do not assume that adding an app to a list has the same effect across different clients.

App-based rules apply to application traffic, not automatically to individual websites or domains. If you need one browser to use the VPN only for certain sites, per-app selection may not provide that granularity. A browser’s own proxy support, a client’s domain rules, or a separate routing feature may be needed, depending on the product. Also consider related processes: a selected app may rely on another app or Android component for sign-in, notifications, downloads, or media playback, and those related requests may not follow the route you expect.

Choose the mode that gives you the simplest rule set. Include mode is often easier when only a few apps should use the VPN. Exclude mode can be easier when most apps should use it and only a small number need a direct route. In either case, keep a short note of the apps you selected and why; this makes future troubleshooting much less confusing.

Check Client Support and Android Settings

Before changing rules, check that your Android client has an explicit per-app or split-tunneling control. Some clients expose it in the connection profile, others place it under routing or advanced settings, and some do not provide it at all. If the option is absent, do not try to imitate it by changing unrelated Android network settings. Use the client’s own documentation or choose a compatible client that clearly supports the feature.

If you are still setting up the service, the quick-start guide covers the general client and subscription workflow. The client, subscription, and route are separate parts of the setup: installing an app does not import a configuration, and importing a configuration does not by itself select per-app rules. You can also review the VPN54 setup information from the VPN54 homepage when checking which clients and platforms are available.

On Android, a VPN app normally requests permission to create a VPN connection. Review the system prompt and confirm that it belongs to the client you intentionally opened. Android generally maintains one active VPN connection at a time, so another VPN app, a work-profile VPN, or a security app that manages a tunnel can interfere. Quit other VPN clients before testing, and check whether your employer or device administrator controls network settings.

Look for Android’s Always-on VPN and “Block connections without VPN” options if you have enabled them. Their interaction with excluded apps matters: an app that is intentionally configured to bypass the VPN may still be unable to connect if Android is set to block traffic outside the VPN. The exact behavior depends on the Android release, the client, and how the VPN profile is configured. Do not enable a blocking option until you understand its effect on apps that are meant to use a direct connection.

Set App Rules Step by Step

Use a deliberate sequence so that you can tell whether a problem comes from the VPN connection, the selected mode, or a particular app. Menu names vary between clients, so follow the meaning of each option instead of relying on a screenshot from a different app version.

1. Establish a working baseline. Connect the client with its default routing behavior. Open a browser and one other ordinary app, and confirm that both can reach the services you expect. If the connection is not working before you add app rules, fix that first; split tunneling will not repair an invalid subscription, an unavailable route, or a basic connectivity problem.
2. Open the per-app routing control. Find a setting described as split tunneling, app routing, included apps, or excluded apps. Read the short explanation on the screen and determine whether the selection means “send these apps through the VPN” or “bypass the VPN for these apps.” If the wording is unclear, pause and consult the client’s own help material.
3. Choose one mode and a small test set. Start with one app whose expected route is easy to check. For include mode, select the app that should use the VPN. For exclude mode, select the app that should use the direct route. Avoid building a long list before you have confirmed what the client does with a single selection.
4. Save the rule and reconnect if needed. Some clients apply changes immediately; others need the VPN connection to be stopped and started so Android can create the connection with the updated application list. Follow the client’s prompt. Check that the VPN indicator returns and that the client shows the intended profile as active.
5. Test the selected app and a comparison app. Open the app whose route you changed, then open an app that should follow the opposite route. Confirm each one behaves as expected. If either fails, return to the rule screen and verify the mode, selected app, and connection state before changing several settings at once.
6. Expand the list gradually. Once the first test is clear, add other apps in small groups and repeat the checks. Keep apps that depend on local devices, workplace access, or direct network discovery in mind; those may need different routing from general browsing or streaming apps.

For a practical example, suppose you want a browser to use the VPN while a local printer app stays on the regular network. In include mode, select the browser and leave the printer app unselected. In exclude mode, select the printer app as the one to bypass. These are opposite rule sets, so do not select both apps and assume the client will infer your intention. After saving, test the browser and printer app separately, including the local function you actually need.

Keep expectations realistic when a service uses multiple apps. A streaming app may open a browser for account authentication, or a file manager may hand a download to another app. The rule may apply to the app that initiates the request, the app that completes it, or both, depending on how the service is built. If a feature fails while the main app works, identify the app involved in that feature before changing the entire VPN profile.

Verify the Route With Repeatable Tests

Test routing in a way that separates “the VPN is connected” from “this app uses the VPN.” A client status screen can confirm that a tunnel is active, but it does not necessarily show which individual app used it. Use more than one check when possible: observe the client’s connection state, open the target app, and compare its network behavior with an app assigned to the other route.

• ✅ Confirm that the VPN client is active before testing any app rule.
• ✅ Test one selected app and one comparison app after each meaningful change.
• ✅ Reconnect if the client says rule changes take effect only on a new connection.
• ✅ Check Always-on VPN and blocking settings if an excluded app cannot connect.
• ❌ Do not treat a VPN icon or a successful browser test as proof that every app follows the same route.
• ❌ Do not change the app list, DNS options, and system VPN settings all at once; that makes the cause of a failure difficult to identify.

An IP-checking page opened in a browser can be one useful test for that browser, but it says nothing definitive about a separate app. If the browser is selected for the VPN, its result should be consistent with the VPN route; if it is excluded, it should normally use the direct route. Results can still be affected by browser proxy settings, private DNS, another active network tool, or the test page itself. Treat this as evidence about one app’s requests, not a universal test of the phone.

DNS behavior deserves particular care. Android’s Private DNS setting, a client’s DNS handling, and the app’s own networking can influence name resolution. An app may appear to connect through one route while resolving names through another path, or it may use a built-in resolver that does not follow the same behavior as a browser. If a privacy-sensitive test produces unexpected results, check the client’s DNS documentation and Android network settings instead of assuming that the app list controls every DNS request identically.

Repeat the check after switching between Wi-Fi and mobile data, after restarting the client, and after Android has stopped the app in the background. Network changes can trigger a reconnect or expose a rule that was not applied to the new session. If a problem occurs only on one network, record that condition; it helps distinguish a routing rule issue from a local Wi-Fi restriction or mobile network behavior.

Troubleshoot and Choose a Maintainable Rule Set

If a selected app cannot connect, first check whether you selected it in the intended mode. Then confirm the VPN is active, the app appears in the client’s list, and the rule was saved. If the app was excluded, inspect Android’s blocking settings and the client’s kill-switch behavior. If the app was included, try reconnecting and check whether the selected route is available for the service it needs. Do not immediately remove every rule; make one change, retest, and note the result.

If an app keeps using the unexpected route, check for a second VPN or proxy, a work profile, a cloned app, or a separate copy installed in another Android user profile. The app shown in a selection list may not be the same installation that you launch. Also check whether the client has a global mode that takes precedence over app rules. When in doubt, temporarily return to the client’s default settings and verify the baseline before rebuilding the rule set.

For intermittent failures, look at battery and background restrictions as well as routing. Android may restrict background activity, and a client that is stopped or disconnected cannot apply its VPN route. Follow the client’s guidance for keeping its service active, but do not grant unrelated permissions or disable system safeguards without a clear reason. If only one app is affected, test that app without changing the routing of every other app on the device.

Use the smallest rule set that meets your needs. A long exception list is harder to review when you install, update, or replace apps. Revisit it after major client or Android updates, because labels and available options can change. If the client does not support the exact combination you need, do not assume that two overlapping VPN apps will solve it; Android’s single active VPN behavior can make that approach unreliable.