Android VPN split tunneling lets you choose which apps send traffic through a VPN and which use your regular internet connection. It can be useful when one app needs a VPN route but another works better with your local network, or when you want to keep a banking or local-network app outside the tunnel. The exact controls depend on the VPN client: some offer an app list with include or exclude rules, while others do not provide app-based routing at all. This guide explains how to check for the feature, set it up carefully, verify the result, and reverse a rule if an app stops connecting.
Split tunneling is a routing choice, not a guarantee that an app will work or that every part of its traffic will follow the same path. Android versions, client implementations, DNS handling, and app behavior can all affect the result. Treat the setting as something to test with the apps and networks you actually use, rather than as a universal switch that changes every connection in the same way.
Understand the two rule modes
Most app-based split-tunneling interfaces use one of two models. In an include-list model, only the apps you select use the VPN; apps not selected use the regular connection. In an exclude-list model, apps you select bypass the VPN, while other apps continue to use it. The labels differ between clients, so read the explanatory text on the settings screen before changing anything. “Selected apps use VPN” and “Selected apps bypass VPN” describe opposite behavior, even if both screens show a list of app names.
Some Android VPN clients implement these rules inside the client, using Android’s VPN service, while others expose a per-app setting through their own configuration. Do not assume that Android’s system settings contain a universal split-tunneling menu. If you cannot find an app list in the VPN client, check its help documentation or the configuration options available for your connection. A client may support VPN connections without supporting app-by-app routing.
App selection also has practical limits. An app may rely on a separate companion app, a system component, or a browser opened through another app. A rule for one visible app does not necessarily describe every related connection. Likewise, a selected app may use more than one network-related component, and its behavior can depend on how the client handles DNS and IPv6. When a service behaves unexpectedly, test the rule rather than assuming the app list tells the whole story.
2
Common rule modes: include or exclude apps
5
Checks in the verification routine below
Choosing a mode starts with your goal. If only a small number of apps need the VPN, an include list can be easier to review. If most apps should use the VPN and only a few need a direct route, an exclude list may be more convenient. Neither approach is inherently safer or more reliable: the important point is to understand what happens to apps you have not selected and to revisit the list when you install, remove, or replace apps.
Decide which apps should use the VPN
Start by grouping apps according to the connection they need, not by guessing based on their names. A browser or media app might benefit from using the VPN for a particular task, while a service tied to your local network may need a direct connection to discover a printer, cast to a nearby device, or reach a home device. A banking app may have its own security checks and regional requirements; routing it through a VPN can lead to additional verification or a login warning. Those outcomes are determined by the app and its provider, so do not treat a routing rule as a way to bypass account policies.
Write down the intended behavior before opening the settings. For example, note which apps should use the tunnel, which should bypass it, and which should remain unchanged until tested. This small planning step makes the list easier to audit later. If the client supports only an include list, remember that unselected apps may go direct; if it supports only an exclude list, unselected apps may use the VPN. Check what happens to newly installed apps rather than assuming they inherit the behavior you prefer.
Be cautious with apps that handle sensitive data or device management. A work profile, parental-control tool, security app, or device administrator may apply network policies that interact with a VPN. If the phone is managed by an employer or school, follow its instructions before changing routing. Split tunneling can also change which network sees an app’s traffic: an app routed through the VPN uses the VPN path, while an app excluded from it uses the ordinary network path, subject to the client’s implementation and the app’s own networking behavior.
To compare your options, begin with VPNPen and review the service information relevant to your setup, then confirm that the Android client and the specific configuration you use actually expose per-app rules. A service listing, protocol name, or subscription alone does not establish that a particular client has split tunneling. If the control is missing, do not substitute a second VPN app or an unrelated firewall without understanding how it will affect Android’s active VPN connection.
- ✅ Use an include list when you want to name the small set of apps that should use the VPN.
- ✅ Use an exclude list when you want most apps to use the VPN and only specific apps to bypass it.
- ✅ Check whether local-network discovery, casting, or work-profile policies matter for the apps you select.
- ❌ Do not assume that a VPN subscription or Android version guarantees app-based routing in every client.
- ❌ Do not change several network controls at once; it becomes harder to identify which setting caused a problem.
Set up and test app rules
The following procedure is deliberately client-neutral because Android VPN apps use different menus and labels. Keep the current rule state in mind before editing, and make one change at a time. If the client offers a backup, profile export, or reset option, understand what it stores before using it. Avoid sharing configuration files that may contain account credentials, tokens, or subscription details.
- Check the active connection. Open the VPN client and confirm which profile or server configuration is selected. If another VPN, firewall, DNS changer, or network-filtering app is active, pause and identify how it is controlling traffic. Android generally routes VPN traffic through an active VPN service, so running multiple tunnel apps at the same time can create conflicts or prevent the expected connection from starting.
- Find the app-routing control. Look in the client’s connection, routing, or advanced settings for wording such as per-app VPN, split tunneling, excluded apps, or apps that use the VPN. Read any description shown on screen. If the client does not list apps or explain its rule behavior, consult its documentation instead of guessing at an Android-wide setting.
- Choose the rule model and select apps. Decide whether the selected apps should use the VPN or bypass it. Add only the apps needed for the test. If an app is shown more than once because of a work profile or another Android user, select the correct instance. Review the names carefully; similar icons or duplicate entries can make it easy to choose the wrong app.
- Save the change and reconnect if required. Some clients apply rules immediately; others require you to disconnect and reconnect. Follow the client’s prompt, then wait for the connection state to settle. If Android asks to approve a VPN connection, confirm that the request comes from the client you intended to use. Do not interpret a persistent notification by itself as proof that a particular app is routed correctly.
- Test one selected app and one unselected app. Open the selected app and confirm that its expected function works. Then test an app that should use the other route. Where appropriate, compare an app’s connection or account behavior with the VPN disconnected, but avoid repeatedly changing regions during a sensitive login. A successful page load alone may not prove which path carried the traffic; use the client’s own diagnostics or a trustworthy network-check method where available.
For a useful test, use the same Wi-Fi or mobile network, the same app account, and the same task before and after the change. Note whether the VPN is connected, which rule mode is active, and which app was selected. If your client provides per-app logs or connection details, consult them without posting private identifiers publicly. Testing a single variable at a time helps distinguish a routing problem from a temporary service outage, weak Wi-Fi, an account restriction, or an app update.
Also test the behavior you care about rather than relying only on a generic IP display. If the goal is local-device discovery, try the actual printer or casting workflow. If the goal is access through the VPN, test the specific service while keeping its terms and account requirements in mind. A route check can help explain the connection path, but it cannot promise that an external website will accept a login or provide a particular feature.
Verify the result and protect against misconfiguration
After saving the list, confirm five things: the selected rule mode, the exact apps in the list, the VPN’s connection state, the behavior of a selected app, and the behavior of an app that was not selected. Check these points again after changing profiles or updating the client, because an interface change or profile switch may alter which rules apply. If the client has a status page, use it as supporting evidence, not as a substitute for testing the app itself.
Android’s “always-on VPN” and “block connections without VPN” options are separate from an app list. They can affect whether traffic is allowed when the VPN is disconnected, and their behavior may interact with a client’s bypass rules. If you enable a block-without-VPN option, an app intended to use the regular network may be unable to connect, depending on Android’s and the client’s handling of exclusions. Before enabling system-level lockdown controls, read the warnings and make sure you understand how to restore access if the VPN fails.
DNS is another reason results may not match expectations. Some clients route DNS requests according to the VPN connection, while others may apply per-app or system-level handling differently. An app can also use its own encrypted DNS or networking stack. Therefore, a rule that appears to route an app through the VPN does not, by itself, prove that every lookup or related service follows an identical path. Use the client’s documented behavior and test the specific issue you are troubleshooting.
For privacy, think about the route as a choice of network path. Apps using the VPN send traffic through the VPN connection; apps that bypass it use the regular network connection, which may be Wi-Fi or mobile data. A bypass rule does not make an app invisible to the network it uses, and a VPN does not eliminate the need to use secure accounts, updated software, and careful sharing practices. Avoid adding an app to an exception list simply because a connection is slow until you have considered what that change means for its traffic.
Undo a rule when an app stops connecting
If an app fails after you change split tunneling, first reverse the most recent rule change rather than resetting every network setting. Open the same list, check whether the client is using an include or exclude model, and remove or invert the affected app’s entry. Save the change, reconnect if the client requests it, and retry the app on the same network. If the app works again, the rule or its interaction with another setting is a likely cause, though a temporary outage could still be involved.
If the rule did not help, temporarily disable split tunneling and test the app with the normal VPN profile. This comparison can show whether the issue is tied to app-based routing. Then test the app with the VPN disconnected only if doing so is appropriate for the service and your privacy needs. Do not leave a sensitive app on a route you did not intend just because it connects more easily; make an informed choice about whether the VPN or regular connection is appropriate for that task.
When the app still fails, check for common causes outside the rule list: a stale login session, an app update, a captive Wi-Fi sign-in page, a system date or time issue, a weak network, or a service-side restriction. Restarting the client or reconnecting to the same profile may help, but avoid changing the protocol, server, DNS, and app list all at once. If you need to contact support, describe the Android version, client version, rule mode, affected app, and the steps you tried. Do not include passwords, private keys, authentication tokens, or an unredacted subscription URL.
To return to a simple baseline, remove the app-specific entries or turn the feature off, restore the intended VPN profile, and confirm whether any Android always-on or block-without-VPN setting remains enabled. Keep a short note of the working configuration so you can recreate it later. If the client has no clear way to restore the previous state, use its official instructions rather than deleting system components or installing another tunnel app as a workaround.
Split tunneling is most useful when its purpose is specific and its effects are verified. Choose the rule mode deliberately, make a small change, test the apps on both sides, and undo the change if the behavior does not match your plan. Those habits make app-based routing easier to troubleshoot while keeping the distinction between VPN traffic and regular network traffic clear.