Android VPN split tunneling lets you decide which apps use the VPN tunnel and which apps keep using the ordinary network connection. That distinction is useful when you want a browser, streaming app, or work tool to use a particular VPN route while leaving local banking, casting, printer discovery, or domestic services outside the tunnel. It can also reduce unnecessary routing overhead and make troubleshooting much easier.
The feature sounds simple, but Android VPN clients implement it in slightly different ways. Some offer an app list with VPN apps only and bypass selected apps modes; others expose the same choice as an allowlist or blocklist. A few clients also provide a separate switch for local network access. The labels are not always identical, so the important task is to understand the traffic rule behind each setting rather than relying on the wording alone.
This guide explains how per-app routing works, how to prepare an Android device, how to configure the rules in a practical order, and how to verify that the selected applications are really following the intended path. It also covers common conflicts involving Android's always-on VPN, private DNS, battery management, and applications that use more than one process.
How Android Split Tunneling Works
An Android VPN client normally creates a virtual network interface through the Android VpnService framework. When the tunnel is active, the operating system sends selected traffic to that virtual interface, and the client encrypts or forwards it according to the imported subscription and the chosen server or protocol. Without split tunneling, the default behavior is usually to send most application traffic through that interface.
Split tunneling changes the routing decision at the application level. The client checks the originating app and then applies one of two basic policies:
- Include selected apps: only the apps you add to the list use the VPN. Other apps continue through the normal Android network connection.
- Exclude selected apps: most apps use the VPN, while the apps you add to the exclusion list bypass it.
These modes are not interchangeable. If your goal is to protect only a browser and one media app, an include list is usually easier to audit. If your goal is to route almost everything through the VPN while keeping a printer, payment app, or local service outside, an exclude list may be more convenient. The wrong mode can produce the opposite result from what you intended without showing an obvious error.
2
Core policies: include selected apps or exclude selected apps
3
Main verification points: app route, IP route, and local access
1
Active VPN profile should control the routing decision
There is another important distinction: app-based split tunneling is not the same as domain-based rule routing. App-based routing asks, “Which Android application opened this connection?” Rule-based clients may instead ask, “Which domain, IP range, country group, or rule set matches this connection?” Some advanced Android clients combine both approaches, but their behavior can become difficult to predict if several rule systems are enabled at once.
Prepare the Android Device Before Changing Rules
Before editing the app list, simplify the environment. Android can maintain only one active VPN service in the normal user profile, so two VPN applications should not be running at the same time. If you have an official VPN client, Clash-style client, sing-box client, or another compatible application installed, stop the unused one and remove its VPN permission if necessary. Otherwise, you may be testing a different profile from the one you just configured.
First, import or confirm the subscription in the client. For an official Android client, this may mean signing in and selecting a server. For a compatible client, it may mean importing a subscription link, a profile file, or a supported protocol configuration. The exact interface varies, but the profile should connect successfully before you add split-tunneling rules. If the basic tunnel does not work, app-based routing will only make the problem harder to isolate.
Next, note the applications that need different treatment. Write down the purpose rather than only the app name:
- ✅ Apps that need the VPN: a browser, selected streaming app, AI tool, or remote service.
- ✅ Apps that should stay local: a printer utility, home camera, casting tool, or local file server.
- ✅ Apps that are sensitive to route changes: banking, payment, identity verification, and corporate security tools.
- ❌ Do not add every application to both the include and exclude lists unless the client explicitly documents how conflicts are resolved.
- ❌ Do not test while another VPN, proxy, or device-wide traffic filter is active.
Android's system settings also deserve attention. In Settings > Network and internet > VPN, check whether an always-on VPN is enabled. Depending on the Android version and device manufacturer, you may also see a Block connections without VPN option. These controls can be useful for preventing accidental direct traffic, but they can interfere with an include-only split-tunnel design. If only a few apps are supposed to use the VPN, blocking all non-VPN connections may cause the remaining apps to lose connectivity.
Private DNS is another variable. A private DNS provider can resolve names outside the VPN path, inside the VPN path, or through a client-specific DNS mechanism, depending on the application. If a service opens but shows the wrong region, or if a local hostname stops resolving after the tunnel starts, record the Private DNS setting before changing it. Avoid changing several DNS and VPN options at the same time; otherwise, you will not know which change fixed or caused the behavior.
Configure Per-App Routing Step by Step
The following sequence works for most Android VPN applications that provide an app-based routing screen. Menu names may differ, but the logic remains the same.
1. Choose the routing mode first
Open the client, select the active profile, and look for a section named Split tunneling, Per-app VPN, App routing, or Exclude apps. Before selecting any application, identify whether the screen is currently in include mode or exclude mode. Some clients use a switch labelled “VPN only” while others use “Bypass selected apps.” Read the description under the switch if one is available.
For a small protected set, choose include mode. Add only the applications that must use the tunnel. For a mostly protected device, choose exclude mode and add only the applications that must remain on the normal connection. Start with the smallest possible list. A short rule set is easier to test, explain, and restore than a list containing every installed application.
2. Select applications and save the profile
Open the application picker and wait for the complete list to load. Search by the package's visible application name, not by an assumed package identifier. If two apps have similar names, open them once from the launcher so you can distinguish the correct one. Add the primary app first, then add companion apps only when testing shows that they are required.
For example, a browser may hand a login flow to a separate authentication component, while a media app may launch an external player or use a download helper. Adding every related component immediately is not ideal because it expands the protected surface without proving that the extra component needs the same route. Begin with the visible application, test it, and then investigate only the missing function.
Save the rule set and reconnect the VPN. Some clients apply the change immediately; others require a disconnect and reconnect because the Android VPN interface must be rebuilt. If Android displays a VPN permission dialog, confirm that the profile you intend to use is the one being granted permission. A new permission prompt is a good reason to pause and verify the client name rather than accepting it automatically.
3. Decide how local network access should behave
Look for an option such as Allow LAN traffic, Bypass local networks, or Local network sharing. This setting is separate from the app list. An app can be excluded from the VPN and still fail to reach a local device if the client blocks private address ranges. Conversely, allowing local traffic does not mean that every application bypasses the VPN; it usually controls access to local network destinations.
If you need wireless printing, casting, file sharing, or a home control panel, enable local access only when you understand the exposure. A public Wi-Fi network may contain other devices that can attempt to reach local services. At home, the setting may be practical; on a shared network, it deserves more caution. Test the specific local service after enabling it instead of assuming that all local protocols will work equally well.
4. Reconnect and test one application at a time
Close the VPN client if it offers a stop action, reconnect the selected profile, and test one protected application first. Then test one excluded application and one local service. Do not change the server, protocol, DNS mode, and app list during the same test cycle. A controlled sequence makes it possible to identify whether the issue comes from routing, the selected endpoint, or the application itself.
| Test target | Expected path | What to check |
|---|---|---|
| Included app | VPN tunnel | Its external IP or service region should reflect the VPN route |
| Excluded app | Normal network | It should continue working without inheriting the VPN route |
| Local service | Local network path | Printer, cast target, or local hostname should remain reachable when allowed |
| Background service | Depends on the selected mode | Notifications and account sync should match the intended policy |
Verify the Result Instead of Trusting the App List
A configured list is only a plan. Verification tells you whether Android and the client actually applied it. The most useful test is to open an external IP lookup page from the protected application and then repeat the same test from the excluded application. The two results should correspond to the routes you selected. If both applications show the same result, the rule may not be active, the client may be using a global mode, or the application may be sharing traffic through another process.
Use a second test for DNS behavior. Open a service that depends on region, language, or a domain lookup from both applications. A different external IP does not always prove that DNS follows the same path. If the application reaches the expected server but displays an unexpected region, investigate the DNS mode and the app's own resolver behavior. Some applications use encrypted DNS or embedded networking libraries rather than the system resolver.
Also test after a screen lock, a network change, and a brief client restart. Android may suspend background processes to save battery, while a Wi-Fi-to-mobile-data change can cause the VPN interface to reconnect. A rule that works immediately after setup but fails after the device sleeps is usually an Android background restriction or reconnect issue, not necessarily a bad subscription.
Some applications are particularly difficult to verify. Browsers may use multiple tabs but normally share one application identity. Work profiles can separate the same app into a personal copy and a managed copy. Games, media apps, and corporate tools may start helper processes or use direct connections that do not behave like ordinary web traffic. If only one feature fails, check whether the helper application also needs to be included or excluded.
Improve Reliability and Troubleshoot Conflicts
The best split-tunnel configuration is not necessarily the one with the most entries. It is the one whose behavior remains understandable after reconnects, updates, and network changes. Keep a short note of the chosen mode, the apps in the list, the local-access setting, and the profile or server used. This makes rollback much faster when an application update changes its networking behavior.
Battery optimization is a common cause of intermittent results. Android manufacturers may stop a VPN client while it is in the background, especially when the screen is off. If the tunnel disappears after idle time, open the system battery settings for the VPN client and select the least restrictive option available. Do this carefully: allowing a client to run in the background can improve continuity, but it also increases background activity.
If notifications stop arriving, do not immediately add the entire messaging application to the VPN list. First determine which mode is active and whether the client is applying a kill switch. In include mode, a notification service may be outside the tunnel by design. In exclude mode, the notification path may be forced through a route that the service does not accept. Compare behavior with the VPN disconnected, then test with the app temporarily moved to the opposite list.
- ✅ Reconnect the VPN after changing the routing mode or profile.
- ✅ Test on both Wi-Fi and mobile data if the problem appears only on one access network.
- ✅ Check Android battery restrictions when the tunnel stops after the screen locks.
- ✅ Keep local network access separate from the per-app include or exclude decision.
- ❌ Do not run two VPN clients simultaneously and assume the last one opened controls all traffic.
- ❌ Do not enable a kill switch blindly in an include-only design; it may block apps intentionally kept outside the tunnel.
Protocol choice can also affect reliability. Android clients may support WireGuard, OpenVPN, Shadowsocks, VMess, Trojan, Hysteria2, or other protocol families depending on the provider and application. WireGuard and OpenVPN are commonly exposed by official clients, while compatible clients may support a broader set of subscription formats. Hysteria2 uses QUIC and UDP, which can behave differently from TCP-based transports on networks that restrict or deprioritize UDP. A protocol that connects successfully is not automatically the best protocol for every application or access network.
Route type matters as well. An IEPL route uses a private international circuit for its cross-border segment, while BGP relay and direct connections depend more heavily on public-network conditions. If only the included app is unstable, try another compatible server or route type before rewriting the entire app policy. If every app becomes unstable, first inspect the base VPN connection, DNS, and access network.
Restore the Default Routing Mode Safely
When split tunneling is no longer needed, restore the default routing mode deliberately. Open the same routing screen, switch back to the client's normal global mode, clear the include or exclude entries, save the profile, and reconnect. If you only disable the VPN without clearing the list, the old rule may return the next time the profile is activated.
After reconnecting, check Android's system VPN page. If you enabled always-on VPN, local network access, or a block-without-VPN option during testing, decide whether each setting should remain. A restored routing mode combined with an old block rule can make ordinary applications appear offline. Similarly, removing the client while its always-on entry remains in Android settings can create confusing connection prompts.
For a complete reset, use this order:
- Disconnect the active VPN profile.
- Restore global routing or remove the per-app rules.
- Save the profile and reconnect once.
- Review Android's always-on and block-without-VPN settings.
- Test a normal browser, a local service, and an application that previously used the VPN.
If you are changing from an official Android client to a compatible client such as Clash Verge on another platform, sing-box, or Shadowrocket on iOS, do not assume that the same app rules will transfer directly. Android package names, rule syntax, DNS handling, and VPN permissions differ by client. Import the subscription according to the target client's supported format, then rebuild the routing policy in that client's own terminology. The general concepts remain the same, but the implementation is not identical.
Frequently Asked Questions
Should I use include mode or exclude mode?
Use include mode when only a small number of applications need the VPN. It is easier to audit because everything else remains outside the tunnel by default. Use exclude mode when most applications should use the VPN and only a few local or sensitive apps need a direct connection. If you are unsure, start with include mode and add apps gradually.
Why does an excluded app still show VPN behavior?
Confirm that the client is really in exclude mode and reconnect after saving the list. Then check whether an always-on VPN, a kill switch, or another VPN application is active. The app may also be using a helper process, an embedded DNS resolver, or a work-profile copy that is not covered by the rule you edited.
Why can I reach the internet but not my printer or casting device?
Internet routing and local network routing are separate decisions. Look for the client's LAN or local-network access option and enable it only when appropriate for the network you trust. Also confirm that the phone and the local device are on the same network and that the device's discovery protocol is not blocked by the router.
Do I need to change the protocol when configuring split tunneling?
Not usually. Configure and verify the app rules using the current working profile first. Change the protocol only when the base connection is unstable, a particular network handles UDP poorly, or the selected client does not support the imported profile correctly. Changing the protocol and routing rules at the same time makes troubleshooting less reliable.
Android split tunneling works best when treated as a small routing policy rather than a collection of random checkboxes. Choose the mode before choosing apps, separate local-access settings from VPN selection, reconnect after meaningful changes, and verify the result with the actual applications and services you use. If you need help importing a compatible profile or reviewing the Android client workflow, the setup guide provides the next starting point.