Android VPN split tunneling lets you choose which apps send traffic through a VPN connection and which connect directly. It is useful when some apps need a VPN route while others depend on your usual network, but it is also easy to misunderstand: an app rule is only one part of the routing path. The Android version, the client’s operating mode, and other VPN settings can all affect what happens.
This guide explains how app-based rules work, how to set them up carefully, and how to check the result. The exact labels differ between Android versions and clients, so focus on the meaning of each option rather than expecting a particular button name.
Understand what split tunneling changes
Without per-app rules, a client may route all traffic it handles through its selected server. Split tunneling changes that behavior by defining which apps are included in the VPN route or excluded from it. The terms “include” and “exclude” describe different approaches, and clients may offer one, the other, or both.
- Include selected apps: Only apps you select use the VPN route. Other apps use the device’s ordinary network, unless another system or client rule changes that behavior.
- Exclude selected apps: The VPN route applies generally, but selected apps bypass it and connect through the ordinary network.
- Route all traffic: No app-specific exception is configured. This can be a useful starting point when you want one consistent route for apps handled by the client.
These descriptions are a practical model, not a guarantee that every client implements rules identically. Some tools provide a proxy for selected apps, while others create an Android VPN connection and apply rules to traffic passing through it. A client’s rule screen may therefore control a different layer from Android’s own VPN settings. Read the client’s description before switching modes.
Also distinguish an app rule from an app’s own network behavior. A browser may use a connection established by another service, and an app may include background components or use a system service. A rule for the visible app does not necessarily tell you how every related process behaves. If a result seems inconsistent, test the app’s main function and its background behavior separately.
3
Common routing choices
2
Rule styles: include or exclude
1
VPN connection to check
The figures above describe the concepts in this guide, not performance measurements. They are a reminder to settle the routing model first, then verify which connection Android and the client actually use.
Choose app rules before changing settings
Start with the outcome you want, not with a long list of apps. For example, you might want a particular work or browsing app to use the VPN while a local device-control app connects directly. Write down which apps belong in each group and why. This makes the rule easier to review later, especially if the client presents an include list whose meaning is the opposite of an exclude list.
For a small number of exceptions, an exclude rule can be straightforward: keep the general VPN route and bypass it for the apps that must use the ordinary connection. For a small, known group that needs the VPN, an include rule may be easier to audit. Neither approach is inherently safer or faster. The right choice depends on whether you can confidently identify the apps that should follow the rule.
Before editing the list, check whether the client applies the changes immediately or requires you to reconnect. If it separates configuration selection from connection state, save the rule, disconnect, and connect again when the client instructs you to do so. Do not assume a visible checkbox has changed an already established route.
Android may also have an “Always-on VPN” setting or an option to block connections that do not use the VPN. These are system-level controls, not ordinary per-app rules. Depending on the setup, a strict block can prevent an app you intended to bypass from reaching the internet. If you rely on an exclusion, review those controls and test the result rather than disabling protections by guesswork.
Make one routing change at a time. A short, intentional app list is easier to verify than a large set of exceptions whose purpose is no longer clear.
Use the client’s own documentation for details about its mode and supported rules. VPNPJ provides Android support, but an app rule is still controlled by the client and Android permissions on your device. If you are comparing available services or setup information, VPNPJ is the site home; the routing behavior you see on the phone should still be verified in the installed client.
Set up and test the rules on Android
Use this sequence after you have decided whether to include selected apps or exclude selected apps. Names and screen layouts vary, so follow the equivalent controls in your client rather than treating these steps as a universal menu path.
- Confirm the starting connection. Open the client and make sure the intended configuration is available. Connect without changing multiple advanced options at once. If the client cannot establish its normal connection, resolve that issue before troubleshooting split tunneling.
- Open the app-routing controls. Look for wording such as per-app proxy, app routing, bypass apps, or split tunneling. Confirm whether the screen asks you to select apps that use the VPN or apps that bypass it. If the wording is unclear, consult that client’s help before proceeding.
- Select a small test group. Choose one app that should use the VPN and, if relevant, one app that should connect directly. Avoid selecting system components or unfamiliar services until you understand what they do. Some clients may show only apps they can route, rather than every item installed on Android.
- Save and apply the configuration. Save the changes, then reconnect if prompted. Check that Android still shows the expected VPN connection and that the client reports its route as active. A saved rule and an active connection are separate things.
- Test each app independently. Open the app that should use the VPN and perform a normal, safe task. Then test the app intended to bypass it. Close and reopen an app if it keeps a connection alive from before the rule changed. A single successful page load does not confirm that every request or background task follows the same route.
- Record the working state. Note the client mode and the purpose of each exception. If an update resets a profile or you later change networks, this record helps you restore the intended behavior without rebuilding the rules from memory.
For a useful test, change only one variable at a time. Keep the selected server, network, and app list stable while checking the behavior. If you change the route, switch Wi-Fi networks, and edit several app rules in one attempt, it becomes difficult to tell which change caused the result.
- ✅ Check whether the list means “use the VPN” or “bypass the VPN.”
- ✅ Reconnect if the client says a rule change needs a new session.
- ✅ Test the included app and the bypassed app separately.
- ❌ Do not treat the VPN icon alone as proof that each app uses the route you intended.
- ❌ Do not add Android system services to a rule list just because their names are unfamiliar.
This sequence provides a repeatable baseline. If an app still behaves unexpectedly, keep the baseline and move on to one targeted check instead of resetting every setting immediately.
Diagnose common routing problems
An app that should use the VPN appears to connect directly: First verify that you selected it in the correct type of list. In an exclusion-based mode, selecting an app may tell it to bypass the VPN; in an inclusion-based mode, selection may be what sends it through the VPN. Then confirm that the rule was saved and that the client reconnected after the change.
An app that should bypass the VPN has no connection: Review Android’s Always-on VPN and blocking options, as well as the client’s own mode. A system-level rule that blocks traffic outside the VPN can conflict with a bypass. Check the client’s explanation of how it handles excluded apps before turning off a security setting. If the app requires access to a local device or service, test that connection on the same Wi-Fi network without altering unrelated routing rules.
The rule works for browsing but not for another feature: Apps can make several kinds of requests, including background refreshes, media connections, and connections handled by other components. Keep the client mode unchanged and test the specific feature that fails. If only one feature is affected, note its name and timing; that information is more useful for troubleshooting than saying simply that “the app is broken.”
The list does not show the app you want: Check whether the client has refreshed its installed-app list and whether Android has finished installing or updating the app. Some tools expose only apps supported by their routing method. Avoid selecting a similarly named system package as a substitute. If the client does not offer a supported way to route the app, a different client mode may be required.
Connection behavior changes after switching networks: Wi-Fi and mobile data can have different local services, filtering, or network permissions. Confirm that Android still grants the client its VPN permission and that the client remains connected. Test the same app again before editing the app list; a network change does not necessarily mean the rule itself was erased.
Two networking apps are active: Android generally allows one active VPN-service connection at a time. A second VPN-based client may replace or interrupt the first, while a proxy tool that does not use Android’s VPN service may behave differently. Close or disconnect the other networking app and test again. Do not assume that two clients can combine their app rules into one route.
DNS and IPv6 behavior can also differ by client and network. If an app’s connection result contradicts the expected route, look for diagnostic information in the client and check its documentation for DNS, IPv6, and app-routing support. Avoid relying only on a public IP lookup: it can be a useful clue, but it does not prove that every connection made by the app followed the same path.
Reset or refine your settings safely
If the rule list has become confusing, simplify it rather than adding more exceptions. Record the current choices, remove rules that no longer have a clear purpose, and return to the client’s documented default routing mode. Reconnect and test a basic app first. Then add only the exception you need and verify it before adding another.
A reset should be targeted. If the app list is wrong, reset or clear that list if the client offers the option; avoid deleting the entire profile unless the profile itself is damaged or the client’s instructions recommend it. Removing a profile can also remove server settings or other preferences, so make sure you can restore the configuration before doing so.
After an Android update, client update, or profile change, repeat the checks that matter: confirm the active VPN connection, review whether each app is included or excluded, and test the relevant app function. If the behavior changed, compare the current settings with your saved notes. This is more reliable than repeatedly reinstalling the client or changing unrelated protocol options.
Keep a simple record with the client name, its routing mode, the apps you selected, and the reason for each exception. Do not include passwords, subscription links, or other account secrets in that note. If you need support, provide the Android version, client version, rule mode, and a concise description of what the test app did. Those details make it easier to distinguish an app-rule issue from a connection or permission issue.
Split tunneling is most manageable when each rule has a clear purpose and a test. Start with a stable connection, choose either an inclusion or exclusion approach, and verify both sides of the rule. When you cannot explain why an app is on the list, remove it, return to a known baseline, and build the configuration again deliberately.