Android split tunneling lets you choose which apps send traffic through a VPN connection and which apps use the device’s ordinary network connection. It can be useful when a work app needs a private connection while a local banking app, casting app, or game works better without one. The exact controls vary by VPN client: some let you include selected apps, others let you exclude selected apps, and some do not offer app-level routing at all.
The important point is that split tunneling is a routing rule, not a separate VPN connection for each app. Android and the VPN client determine which traffic uses the active VPN interface. Before changing rules, decide which apps need the VPN, check how your client expresses that choice, and test the result instead of assuming that a saved list is already taking effect.
What Android split tunneling does—and what it does not
With app-based split tunneling, the client associates traffic with installed apps and applies a route to each app. In an include mode, the apps you select use the VPN while apps not selected generally use the direct connection. In an exclude mode, selected apps bypass the VPN while other traffic generally uses it. The wording and default behavior differ between clients, so read the mode description carefully before saving.
“Direct” means the app’s traffic is not sent through that VPN tunnel. It does not mean the traffic is private or encrypted by the VPN. The app still uses whatever protection its own connection provides, such as HTTPS, but your network operator may see connection information that would otherwise be carried through the VPN. A bypassed app may also present the public IP address provided by the current Wi-Fi or mobile network.
App-level rules are not the same as routing a specific website, IP address, or domain. A selected app may contact many services in the background, and the VPN client may route that app as a whole. If you need fine-grained domain rules, check whether the client supports them and understand how they interact with app selection. Do not assume that a browser rule applies to every app that opens a web page.
Android clients commonly implement VPN connections through the system’s VPN framework. That does not guarantee that every client exposes the same split-tunneling controls, or that every protocol and configuration supports them in the same way. Check the app’s own documentation and settings. For VPNBX setup basics, see the getting started guide; available controls depend on the client and configuration you use.
Think in terms of two separate questions: “Which apps should use the tunnel?” and “Does this client actually support that rule?” Choosing the right apps cannot compensate for a client that does not provide app-based routing.
Choose apps and a routing mode before changing settings
Start with the task rather than turning apps on or off at random. Write down the apps that must use the VPN, the apps that must remain direct, and the reason for each choice. This short inventory makes it easier to select the right mode and later diagnose unexpected results. Consider background activity too: messaging, cloud storage, and account apps may connect even when you are not actively using them.
Include selected apps
Choose an include mode when only a small, known group of apps needs the VPN and most other apps should remain direct. For example, you might include a browser used for a particular work task while leaving a local device-control app outside the tunnel. In this mode, an app missing from the selected list may not use the VPN at all, even while the VPN indicator is visible.
Exclude selected apps
Choose an exclude mode when most traffic should use the VPN and only a few apps need a direct connection. This may suit an app that depends on local network discovery or a service that behaves differently when its connection exits through a VPN. Be deliberate: every excluded app bypasses the VPN, including its background requests, unless the client describes a narrower rule.
Do not select a mode just because its label sounds more secure. The practical difference is which side of the list receives the VPN route. If the client says “bypass selected apps,” selected apps are the direct exceptions. If it says “VPN only for selected apps,” selected apps are the tunnel exceptions. Confirm the description on the settings screen and, if possible, test with one non-sensitive app before applying a long list.
- ✅ Use include mode when a few specific apps need the tunnel and the rest should stay direct.
- ✅ Use exclude mode when most apps should use the tunnel and only a few should bypass it.
- ✅ Keep a note of the reason for each exception so you can review it later.
- ❌ Do not treat “VPN connected” as proof that every app is using the VPN.
- ❌ Do not bypass an app without considering the network and privacy consequences of a direct connection.
Set up app rules on Android
Menu names vary by Android version, phone manufacturer, and VPN client. The steps below describe the general flow rather than a guaranteed path through every app. If a control is missing, first check that you are using a client version and connection profile that support app-based split tunneling. Android’s system settings and the client’s own settings may expose different controls.
- Connect the VPN once. Open the client, import or select a supported configuration, and establish a connection. If Android displays a permission prompt to set up a VPN connection, review it and approve it only for the VPN client you intend to use.
- Open the routing controls. In the VPN app, look for a setting named split tunneling, per-app settings, app routing, or a similar term. The control is often under connection, advanced, or traffic settings, but its location is client-specific.
- Choose the mode. Select whether the listed apps should use the VPN or bypass it. Read any explanatory text on the screen. If the app offers a separate option for system apps, decide whether you need it; changing system-app routing can affect services that are not visible in the regular app list.
- Select only the apps you intend to route. Search the installed-app list, select the intended packages, and check for similarly named apps, cloned apps, or work-profile versions. A work profile may have a separate copy of an app, and the VPN client may display it as a distinct entry or handle it differently.
- Save the rule and reconnect if requested. Some clients apply changes immediately; others require you to disconnect and reconnect before the new routing takes effect. Follow the app’s prompt rather than assuming the list is active as soon as you leave the screen.
- Test each side of the rule. Open one app intended to use the VPN and one intended to bypass it. Check the exit IP or region using a trustworthy IP-checking method, and compare the results with your expected routes. Do not test only from the browser if the rule concerns a different app.
For a clean test, close the selected apps fully before reconnecting, then reopen them. Some apps keep existing network sessions alive, so a connection established before a rule change may continue until the app reconnects. If you are troubleshooting, change one rule at a time and record the original setting so you can restore it.
Also check Android’s VPN options if the client relies on them. “Always-on VPN” and “Block connections without VPN” are system-level controls, not synonyms for split tunneling. Depending on Android and the client, a block-without-VPN option may prevent traffic that the client intended to bypass from connecting. If direct exceptions stop working after enabling such a control, review both the client’s routing instructions and Android’s VPN settings before removing the exception.
Verify that each app follows the intended route
Use separate checks for an app routed through the VPN and an app meant to bypass it. For the first, check the public exit IP while that app is active, using a built-in diagnostic page or a reputable IP-checking service that the app can open. For the second, compare its observed network location with the direct connection you expect. A VPN status icon confirms that a VPN connection exists; it does not identify the route used by a particular app.
Make sure the check is performed from the app under test. An IP page opened in a browser tells you how that browser’s traffic is routed, not necessarily how a messaging app or game is routed. If the app has no way to display network information, use its normal connection behavior as a practical test, but do not treat successful loading alone as proof of a particular exit IP.
DNS behavior deserves separate attention. A client may handle DNS queries through its tunnel, apply app routing to DNS, or use another implementation-specific method. The visible IP result from a website does not by itself confirm how every DNS request is handled. If DNS privacy is important, consult the client’s documentation and use a DNS test compatible with its design. Avoid drawing conclusions from a test run while another VPN, private DNS configuration, or filtering app is active.
For a useful test sequence, keep the network stable and change just one factor at a time: first test with split tunneling disabled, then enable the intended mode, reconnect, and retest the same apps. Repeat on Wi-Fi and mobile data only if the behavior differs between those networks. Record whether the app was newly launched and whether Android showed the VPN as connected; those details help distinguish a routing issue from a stale app session or a dropped connection.
Results can also be affected by app accounts, cached content, location permissions, and the service’s own regional checks. If an app shows the expected exit IP but still behaves differently, the route may be working while the service applies another condition. Conversely, an app opening normally does not prove it used the VPN: it may simply have connected directly.
Troubleshoot rules that do not take effect
The selected app still appears to use the wrong route: Recheck whether the list means “include” or “exclude,” then confirm that the correct app entry is selected. Disconnect and reconnect, fully close the app, and test again. If the phone has a work profile or cloned-app feature, check whether you selected the copy you actually opened.
Excluded apps cannot connect: Check whether Android is blocking connections without a VPN, whether the client has a kill switch, and whether the exclusion mode is supported by the active configuration. A block policy can intentionally prevent direct traffic. Do not disable a security control blindly; first decide whether direct access is required and understand what protection the change removes.
Included apps have no network access: Confirm that the VPN itself is connected and that the selected app is not also subject to a conflicting restriction. Review the client’s connection log if available, but avoid sharing logs publicly without checking for account identifiers, addresses, or other sensitive details. Temporarily remove one app rule at a time to identify whether a specific entry causes the issue.
The setting works until the phone restarts: Open the client after reboot and verify its connection state, Android’s always-on options, and any battery or background restrictions. Manufacturer power-management features can pause apps or delay reconnection. If the client offers a documented background-connection setting, use its instructions rather than relying on a generic battery setting that may not exist on your device.
The client offers no app list: Check the client’s documentation or support materials for per-app routing. Android does not provide one universal user-facing split-tunneling screen that can control every VPN app in the same way. If the feature is unavailable, do not assume that a third-party firewall or another VPN app can be combined safely with the existing VPN. Android generally allows only one active VPN service at a time, and competing network tools can conflict.
Finally, review your rules after installing, removing, or cloning apps. An app update may change what you see in the list, and a newly installed app will not necessarily inherit an exception you created for a different app. Keep the configuration as small as practical: fewer exceptions are easier to audit, test, and troubleshoot.