Android VPN split tunneling lets you choose which apps send traffic through a VPN and which connect directly through your normal internet connection. It can be useful when one app needs a VPN route while another depends on your local network, location services, or a connection that does not work well through the tunnel. The setting is usually managed inside the VPN client, not in Android’s general network settings, and its exact name and behavior vary by app.
Before changing anything, decide what you want to achieve. A rule that routes only selected apps through the VPN is different from a rule that sends every app through the VPN except selected ones. Both approaches can be described as split tunneling, but the result is different. Check the active mode, confirm which apps the rule applies to, and test the behavior rather than relying on the rule list alone.
Android VPN Split Tunneling: Set App Rules With This Guide
What split tunneling changes on Android
When an Android VPN app connects, it can create a system VPN interface and direct some or all app traffic into it. Split tunneling adds app-selection rules to that route. Depending on the client, you may see choices such as “include selected apps,” “exclude selected apps,” “VPN for selected apps,” or “bypass VPN for selected apps.” Read the description carefully: selecting an app in an include list usually means it uses the VPN, while selecting an app in an exclude list usually means it does not.
The rule normally concerns network traffic generated by an app package. It does not necessarily cover every action that appears to belong to that app. For example, an app may open a web page in a browser, use a separate authentication app, or rely on a background component that is treated as another package. If the browser is not routed through the VPN, a link opened from a VPN-routed app may make its connection outside the tunnel. Conversely, a browser routed through the VPN does not automatically mean every app linked to it uses the same route.
App rules also do not change what a service can infer from an account, device settings, or information you provide. They control a network path; they are not a general privacy switch. If an app connects directly, your network provider can see that connection’s destination information, subject to the protections used by the app and the network. If it connects through the VPN, the route changes, but the app still receives information needed to provide its service.
- ✅ Use an include list when only a small set of apps needs the VPN route.
- ✅ Use an exclude list when most apps should use the VPN and only a few need direct access.
- ✅ Check the rule’s mode before saving; the same selected app can have the opposite result in the other mode.
- ❌ Do not assume that selecting an app also selects its browser, companion app, or work-profile copy.
Android allows a VPN client to manage a system VPN connection, so only one VPN connection can generally control that system interface at a time. Running two VPN clients together, or combining a VPN with another app that also creates a local VPN, can cause connection conflicts. If a split-tunnel rule appears ineffective, first confirm that the intended VPN client is the one currently connected.
Check the VPN client and Android settings
Start by opening the VPN client and looking for a setting named “Split tunneling,” “App routing,” “Per-app settings,” or similar. It may be on the connection screen, in the selected server or profile, or under the app’s general settings. Some clients offer separate include and exclude modes; others provide only one mode or do not expose per-app rules at all. If you cannot find the option, check the client’s own help information and confirm that the installed version and platform support the feature. Android’s system VPN framework makes app-level routing possible, but it does not guarantee that every VPN app offers a user-facing control for it.
Android menu names and locations vary by manufacturer and version. The system settings can help you inspect the current VPN connection, but they may not provide the app-selection controls you need. On some devices, Android settings also include options such as “Always-on VPN” or “Block connections without VPN.” These affect what happens when the VPN disconnects; they are separate from an app-routing list. If blocking is enabled, an app that is supposed to connect directly may still be unable to reach the internet while the VPN is disconnected. Review these controls before deciding that a split-tunnel rule is broken.
Check which copy of an app you are selecting. A personal-profile app and a work-profile app may appear as separate entries, and a cloned or duplicated app may have a separate package identity. Some launchers also show shortcuts that are not the actual networked app. If an app is missing from the list, open it once, return to the VPN client, and check again. If the client offers a refresh or rescan option, use it. Avoid selecting a similarly named system component unless the client’s instructions explain why it is required.
For users comparing client features, VPN62 is a starting point for checking the available service information; confirm the split-tunneling controls in the specific Android client you plan to use. The client determines whether app rules are available and how they are presented, so a service description alone cannot establish the behavior of a particular installation.
Set app rules step by step
Use the following process as a practical checklist. The labels may differ between clients, but the order helps avoid changing several variables at once. Before you begin, note whether you want selected apps to use the VPN or selected apps to bypass it.
- Connect once without changing the rules. Open the VPN client, connect to the route you intend to use, and confirm that ordinary browsing works. This gives you a baseline. If the connection already fails, resolve that first rather than troubleshooting split tunneling and the base connection at the same time.
- Open the app-routing controls. Find the client’s split-tunneling or per-app routing page. If the client asks you to choose a mode, read the wording and select either “route selected apps through VPN” or “exclude selected apps from VPN,” according to your goal.
- Choose a small test set. Start with one app that should use the VPN and, if necessary, one app that should connect directly. Keeping the first test simple makes it easier to identify whether the mode is reversed or an app is missing from the list.
- Save and reconnect if prompted. Some clients apply changes immediately; others require you to disconnect and reconnect, restart the app, or approve an Android VPN connection request. Follow the client’s prompt. Do not assume a saved list has taken effect until you test it.
- Test each app separately. Close the app completely, reopen it, and perform an ordinary network action. Test the VPN-routed app and the direct-routed app separately. A home screen loading is not enough if the action you need is a login, upload, call, or media session.
- Add the remaining apps gradually. Once the first rule behaves as expected, add other apps in small groups. If a new group causes trouble, remove that group and retest. This makes the cause easier to isolate than changing a long list at once.
Keep a simple note of the mode and the intended route for each test app. For example, write “include mode: browser and work app use VPN; maps app connects directly.” This avoids confusion when returning to the settings later, especially if the client labels the selected apps without clearly repeating what selection means. If you use a work profile, record which profile’s copy you selected.
After changing rules, test both foreground and background behavior. An app may appear to work while open but fail to refresh notifications or synchronize after you leave it. Android battery optimization, background-data restrictions, and the app’s own settings can affect those tasks independently of VPN routing. Check them only after confirming that the basic app route is correct, and change one setting at a time.
Verify each app’s route
Verification should answer two separate questions: does the app connect, and does it connect through the route you intended? A successful page load answers only the first question. Use a connection or IP-checking page inside the app’s own browser when testing the browser, and compare the result with the expected VPN or direct connection. Avoid treating an app’s location display as definitive proof: cached data, account settings, GPS access, or platform-specific signals can affect what it shows.
For apps without a built-in browser, test a normal function that requires an internet connection. Send a message, load new content, synchronize a file, or sign in again if that is safe for your account. If the app has an internal web view, it may use the same app package and rule, but an external browser opened from a link may follow that browser’s own rule. Test the actual workflow you care about, including any handoff between apps.
Check behavior after reconnecting the VPN and after briefly switching networks, such as moving between Wi-Fi and mobile data. A rule can appear correct during one session but behave differently after a reconnect if the client has not reapplied its settings. Do not use a single successful test as a guarantee for every network, app update, or account state. Recheck the important apps after changing the VPN client, updating Android, or installing a new copy of an app.
Be especially careful when testing sensitive tasks. If an app is supposed to bypass the VPN, verify that the direct connection is intentional and acceptable for that use. If an app is supposed to use the VPN, check that it does not open a separate browser or helper app that follows a different rule. Split tunneling is useful precisely because routes can differ, so a single device-wide check cannot establish what every app is doing.
Troubleshoot problems and reset the rules
If a selected app has no internet access, first confirm the mode and selection logic. In include mode, an app not on the list may be expected to use the direct connection; in exclude mode, an app not on the list may be expected to use the VPN. Next, confirm that the list contains the correct app or profile copy, that the VPN remains connected, and that the client indicates the setting is active. Disconnect and reconnect if the client requires it.
If only one service fails, distinguish a routing problem from an app or service problem. Test another network action in the same app, then compare with another app using the same intended route. If all apps on the VPN route fail, investigate the VPN connection or selected route. If only one app fails, temporarily remove its rule or switch its routing mode for a controlled test. Restore the original setting afterward so you do not accidentally leave traffic on an unintended path.
If a direct-routed app cannot connect, look at Always-on VPN and block-without-VPN settings, as well as the client’s own kill-switch or network-lock controls. These may intentionally prevent direct traffic when the VPN is unavailable. Also check whether the app depends on a browser, login helper, or work-profile service that has a different route. If changing the VPN rule does not alter the result, the app may be using a separate component or the client may not support that type of per-app exception.
To reset split tunneling, return to the same settings page and clear the selected-app list, then choose the client’s default or all-apps behavior if it provides one. Some clients use a toggle to disable split tunneling; others require removing each selection. Read the confirmation carefully, because disabling the feature may send all apps through the VPN, while clearing an include list may send no apps through it. After resetting, reconnect if requested and test a browser plus the app that previously had a special rule.
If the client still behaves unexpectedly, record the Android version, VPN client version, connection mode, rule mode, and affected app profile before contacting support. Describe what you expected and what happened, including whether the failure occurs on Wi-Fi, mobile data, or both. Avoid sharing passwords, private account details, or a subscription link in a public troubleshooting post; subscription links can grant access to account configuration and should be treated as confidential.
- ✅ Change one rule at a time and repeat the same test after each change.
- ✅ Recheck work-profile, cloned-app, browser, and helper-app behavior separately.
- ✅ Review always-on and block-without-VPN controls before testing direct-routed apps.
- ❌ Do not run multiple VPN-style apps at once while diagnosing Android routing.
- ❌ Do not leave a temporary bypass rule enabled if the app should use the VPN.