Android VPN split tunneling lets you choose which apps send traffic through a VPN and which use the device’s ordinary network connection. It is useful when some apps need a different route, but it can also make troubleshooting harder: a connected VPN does not mean every app uses it, and an app excluded from the tunnel may still make network requests in the background. The exact controls depend on the Android client, so treat the steps below as a practical workflow rather than assuming every app has the same menu names.
Understand the two kinds of app rules
Most split-tunneling interfaces offer one of two approaches. An “include selected apps” rule sends only the apps you select through the VPN. A “bypass selected apps” rule sends most eligible app traffic through the VPN but excludes the apps you select. Some clients describe these choices as “only allow selected apps,” “include apps,” “exclude apps,” or “bypass.” Read the sentence shown beside the selection before saving; the same app list can produce opposite results depending on the chosen mode.
Think of the setting as a routing decision for app traffic, not as a switch that changes an app’s account, region, or content. The VPN client handles traffic according to its own capabilities and the Android VPN interface. An app outside the tunnel generally uses the network connection that Android would otherwise use. An app inside it sends eligible traffic through the selected VPN route. Neither choice guarantees that an app will work: its own network requirements, DNS behavior, login state, and service policies still matter.
Split tunneling is also separate from a proxy-mode setting such as rule-based or global routing. Those settings decide how a client handles traffic within its supported routing system; app rules decide which Android apps are included or excluded from the VPN tunnel. A subscription import supplies connection configuration, but it does not automatically determine which apps use the tunnel. Check that the selected client actually provides app-level routing before looking for this control.
- ✅ Choose “include” when only a defined group of apps should use the VPN.
- ✅ Choose “bypass” when most apps should use the VPN and only a small group should connect directly.
- ✅ Read the client’s explanation of the rule before selecting apps; labels differ between clients.
- ❌ Don’t assume that a successful VPN connection means every installed app is routed through it.
Availability and behavior vary across Android clients. An official client may expose app selection in its VPN settings, while a compatible third-party client may organize routing under a different configuration screen or may not offer the same control at all. Keep the client’s current documentation nearby, and avoid copying configuration snippets intended for a different app. Android’s system VPN settings can help you inspect the active VPN, but app-level rules are usually configured in the client that created the connection.
Prepare before changing app rules
Start by deciding what result you want for each app. For example, you might want a browser and a media app to use the VPN while a local-network utility connects directly. Write down those intended outcomes in plain language. This prevents a common mistake: choosing an include list when you meant to create a bypass list, then interpreting the resulting traffic as a connection fault.
Next, confirm that the VPN itself works without split tunneling. Connect using the client’s recommended configuration, open an app or website you can reliably reach, and note whether the connection succeeds. If the base connection is not working, changing app rules adds another variable without fixing the original problem. Check the client’s connection status and route selection first, then test the app rules separately.
Identify the exact Android app entry you need. Some services use more than one app, and a feature that appears inside one app may be provided by a separate companion app, browser, or system component. Android may also show multiple entries with similar names. Select the package that corresponds to the traffic you intend to route, and avoid selecting system components unless the client’s instructions explain their effect.
Consider whether the app uses background services. A messaging app, for instance, can make network requests when its main screen is closed. A download or synchronization app may keep working in the background. When you test a rule, check the app’s relevant function rather than relying only on whether its home screen opens. Also note whether Android is using Wi-Fi or mobile data, because changing networks can affect the result independently of the VPN rule.
Finally, review any existing Android VPN controls. Android generally allows one active VPN connection at a time through its system VPN interface. If another VPN app or work profile is already managing a VPN, it may prevent the client you intended to test from taking control. A system “always-on VPN” or a setting that blocks connections outside the VPN can also change what happens to excluded apps. Understand these controls before treating an app’s inability to connect directly as a split-tunneling failure.
Set and test the app rules
Use this sequence after confirming that the client supports Android app-level split tunneling. Menu names vary, so follow the closest equivalent in your client rather than expecting an exact label.
- Connect the VPN. Open the client and establish a normal connection using the configuration you intend to use. If the client requires permission to create a VPN connection, approve the Android system prompt and confirm that Android shows the expected VPN as active.
- Open the app-routing controls. Look for a section called split tunneling, app routing, per-app proxy, or a similar term. If you cannot find one, check the client’s help information before concluding that the feature is hidden in Android settings.
- Select the rule mode. Choose whether the list represents apps to include or apps to bypass. Pause and read the client’s explanatory text. If your goal is for only a few apps to use the VPN, an include mode may be simpler to reason about. If most apps should use it, a bypass mode may require fewer selections.
- Pick a small test group. Select one app whose expected route is clear, then save or apply the rule. Starting with a small group makes it easier to identify whether the list means “through VPN” or “outside VPN.” Expand the selection only after the first test behaves as expected.
- Reconnect if the client requests it. Some clients apply changes immediately; others need the tunnel to reconnect or the app to restart. Follow the on-screen instruction. If the client shows the new list but traffic still behaves as before, reconnect once before changing additional settings.
- Test both sides of the rule. Open the selected app and perform the specific network action you care about. Then test an app that should follow the opposite route. For example, if one app is included, test it alongside an app that is not included. A single successful page load cannot confirm that both sides of the rule are correct.
- Check the active network path. Where possible, use a trustworthy connection-check service or the client’s own diagnostic information to compare the app’s apparent network route before and after changing the rule. Results can be affected by cached content and app-specific network behavior, so repeat the test after closing and reopening the app.
For a routine setup, keep the rule list readable and change one thing at a time. If your client offers separate controls for app inclusion and route selection, configure the route first, then add app rules. When evaluating a client or its instructions, start from the VPNSR home page and follow the appropriate client guidance rather than assuming every Android app has identical controls.
It can help to record the intended state in a short note: “browser through VPN; local utility direct,” for example. This is more useful than remembering only that you changed a toggle. If the result changes after an app update, Android setting change, or client update, you can compare the current configuration with the result you meant to achieve.
Verify what each app is doing
Use more than the VPN status icon to verify routing. That icon usually indicates that Android has an active VPN connection; it does not tell you which individual apps are included. Instead, check the client’s app list, its connection or traffic details if available, and the behavior of the app you are testing. These sources answer different questions: the app list shows the configured rule, diagnostics may show traffic observed by the client, and the app test shows whether the function you care about works.
Test the same action with a consistent setup. Keep the selected VPN route and network connection unchanged while checking the app. If you switch from Wi-Fi to mobile data, change server, or alter a system proxy at the same time, you will not know which change affected the outcome. Close and reopen the test app when needed, because some apps retain existing network connections instead of immediately opening a new one after a routing change.
Check both foreground and background behavior if it matters to your use. A video or web page loading in the foreground does not prove that notifications, uploads, or synchronization use the same path. Likewise, a notification arriving does not necessarily prove that the app’s main content is reachable. Some apps contact different services for sign-in, media, notifications, and updates, and a rule may not resolve every service dependency in the way you expect.
DNS and IPv6 can complicate interpretation. A client may handle DNS requests, IPv6 traffic, or app-specific connections differently depending on its implementation and configuration. If an app appears to use an unexpected route, check the client’s documentation for its DNS and IPv6 behavior rather than assuming the app list controls every networking detail. Avoid changing several DNS, protocol, and routing options together; isolate one setting, test, and keep a note of the original value so you can restore it.
Also distinguish direct routing from a failed connection. An excluded app may have a working direct route but still fail because of its own service, a local network restriction, or an account issue. Conversely, an app may appear to work while using cached data and never making a fresh request. Retry with a new request, compare another app using the intended route, and review any client diagnostics before concluding that the rule is wrong.
Fix common routing mix-ups
The wrong apps use the VPN. Reopen the split-tunneling page and confirm whether the list means included apps or bypassed apps. Then check that the intended app entries are selected and that the change was saved. If the client offers separate profiles or configurations, verify that you edited the profile currently connected rather than an inactive one.
An excluded app cannot connect. Check whether Android is set to block connections outside the VPN or whether an always-on VPN policy is active. Such a setting may conflict with the expectation that a bypassed app will connect directly. Review the client and Android instructions before disabling a protection setting; if you are using a managed work profile or a device policy, an administrator may control those options.
The app works until the VPN reconnects. Confirm that the app rule remains saved and applies to the active configuration. Some clients keep rules per profile, so switching profiles can change the effective list. Apply the rule again only after checking which profile is active; repeatedly toggling options without identifying the current profile can make the configuration harder to understand.
The rule seems inconsistent after an update. Check whether the client’s layout or feature behavior changed, and confirm the selected app entries still correspond to the installed apps. An Android or app update can also affect background activity or permissions. Test with the current configuration and current app behavior before restoring an old configuration file that may no longer match the client.
A second VPN app will not connect. Check Android’s active VPN status and close or disconnect the other VPN client before testing. Android’s single active VPN connection model means that two conventional VPN apps generally cannot both control the device VPN interface at once. A proxy setting inside a particular app is a different mechanism, so do not assume that enabling it will coexist with the system VPN in the way you want.
Only one function inside an app behaves differently. The app may use multiple components or network services. Verify which package the client rule applies to, then consult the app and VPN client documentation. Avoid routing broad system components through or around the VPN as a guess; doing so can affect unrelated functions and make the cause difficult to identify.
- ✅ Change one setting at a time and note the result before proceeding.
- ✅ Reconnect or restart the affected app when the client says a rule needs to be reapplied.
- ✅ Check active profiles, Android VPN status, and any always-on or block-outside-VPN control.
- ❌ Don’t run multiple VPN clients simultaneously to test whether their app rules can be combined.
- ❌ Don’t share a subscription URL or a screenshot that exposes account or configuration details while asking for help.
Keep the configuration clear and secure
Use the smallest rule set that achieves your goal. A long list of exceptions is harder to review after changing phones, replacing a client, or reinstalling an app. If your preference changes, remove obsolete entries and retest the apps that matter rather than layering new rules on top of old ones. Keep a brief record of whether the list is an include list or a bypass list, because that distinction is easy to forget when revisiting the settings later.
Review the consequences of direct routing. An app excluded from the VPN uses a direct network path where Android and the client permit it. That may be appropriate for an app that must reach a local device, but it also means the app is not receiving the VPN’s network path. Do not use bypass rules for apps that you specifically want protected by the VPN. If your client offers a setting to block traffic outside the tunnel, understand how it interacts with excluded apps before enabling it.
Protect account and configuration details during troubleshooting. Subscription URLs and imported configuration files can contain access credentials or other sensitive information. Share only the non-sensitive details needed to explain the issue, such as the client name, Android network type, rule mode, and the general behavior observed. Do not post a complete subscription link, password, or unredacted configuration in a public forum.
Finally, treat split tunneling as a routing tool rather than a guarantee of compatibility or privacy. The best setup is the one you can explain and verify: you know which apps are meant to use the VPN, you have tested an app from each side of the rule, and you understand the Android settings that may override your expectations. If the behavior remains unclear, return to a simple configuration, confirm the base VPN connection, and add app rules gradually.