Android VPN Split Tunneling Guide: Choose Which Apps Connect

Android VPN Split Tunneling: What It Does and When to Use It

Android split tunneling lets you decide which apps use a VPN connection and which apps connect through the device’s regular network route. Instead of applying one route to every app, a compatible VPN client can select apps individually. This is useful when a work tool needs the VPN but a local service should remain directly reachable, or when you want to test one app’s connection without changing how the rest of the phone behaves.

The exact setting depends on the client. An app may call it split tunneling, per-app VPN, app routing, include apps, or exclude apps. The names are not fully standardized, so read the description beside the option before changing it. In an include list, the selected apps use the VPN and unselected apps generally use the normal route. In an exclude list, selected apps bypass the VPN and the remaining eligible apps use it. The same list of apps can therefore produce the opposite result depending on the mode.

Split tunneling is an app-selection feature, not a guarantee that every request made by an app follows the same path. Some apps rely on companion services, system components, custom DNS behavior, or connections that are not obvious from their icon. A browser may also load content through other installed apps. Test the actual task you care about rather than assuming that choosing one app covers every related process.

It also helps to separate a VPN client from a rule-based proxy client. A VPN client may route traffic by installed Android app through Android’s VPN framework. A proxy client may instead apply domain, IP, or rule-based routing, and its app-level controls can work differently. A subscription importing successfully does not by itself confirm that a particular client supports per-app selection. Check the client’s current documentation and settings before planning a route around it.

Choose an App Routing Mode Before Editing the List

Start with the smallest change that meets your goal. If only a few apps need the VPN, an include list can make the intended route easy to inspect. If nearly all apps should use the VPN and only a few need direct access, an exclude list may be more convenient. Neither mode is universally safer or more reliable: the result depends on the client’s implementation, the apps selected, and the device’s other network settings.

• Use an include list when you want a limited set of apps to use the VPN and prefer other apps to remain outside that selection. Verify whether unselected apps use a direct route or are blocked by another system setting.
• Use an exclude list when the VPN should normally apply broadly but particular apps should bypass it. Select only apps for which direct access is intentional, and check that updates or reinstallations have not changed the app entry.
• Keep the list focused while testing. Selecting many apps at once makes it harder to identify which selection caused a failure or unexpected route.
• Record the original mode and selections before changing them. A brief note or screenshot can make it much easier to restore a known working configuration.

Check Android’s system-level VPN options as well as the client. Always-on VPN and “block connections without VPN” or lockdown behavior can affect apps that the client intends to leave outside the tunnel. Depending on the device and Android version, those settings may prevent direct connections, cause an excluded app to appear offline, or change what happens while the VPN is disconnected. Do not assume the client’s app list overrides every operating-system restriction.

Consider the consequences for the app, not just the convenience of the route. A direct connection may expose the device’s ordinary network address to that app and its services. A VPN-routed connection may make a local device, workplace resource, or region-dependent service harder to reach. For sensitive activities, use a clearly understood configuration and avoid treating an app selection as a substitute for checking the app’s own privacy settings.

The figures above describe the two common list modes and a practical testing approach, not a promise about client capabilities. Some clients may use different controls or may not offer per-app routing at all. If the option is missing, check whether the client version and Android build support it; do not assume a similarly named setting elsewhere has the same effect.

Configure the List and Test App Routing

Before changing settings, connect using the client’s normal configuration and confirm that the apps you need work in that state. If the client supports a subscription import, finish the import and select a working profile before testing split tunneling. For general client access and setup information, the VPNOY home page is the relevant starting point; per-app routing itself must still be checked in the Android client you use.

1. Open the VPN client’s settings. Look for a section named split tunneling, app routing, per-app proxy, or a similar term. If you cannot find one, consult the client’s help material rather than changing unrelated DNS or system settings.
2. Identify the list mode. Read whether the control includes selected apps in the VPN route or excludes them from it. If the wording is unclear, test with a non-critical app before relying on the setting.
3. Select one test app. Choose an app whose network behavior you can check safely. Avoid changing several selections at once, and note the current list so you can restore it.
4. Save the setting and reconnect if required. Some clients apply a change immediately; others need the VPN connection to be restarted. Follow the client’s prompt and wait until its connection status indicates that the profile is active.
5. Test both sides of the route. Open the selected app and perform the relevant action, then check an app that should use the other route. A browser’s IP-check page can provide one clue about that browser’s route, but it does not prove that a separate app uses the same route.
6. Repeat after a network change. If you use both Wi-Fi and mobile data, check the behavior on each. Switching networks can trigger reconnection, DNS, or app-session changes that a single test on one network will not reveal.
7. Expand the list gradually. Once the first test behaves as expected, add or remove one app at a time. Keep a record of each change and confirm the target app still completes its normal task.

During testing, distinguish a routing problem from an app login or service problem. If an app reports an error, try its ordinary refresh or sign-in recovery only after checking whether the VPN connection is active and whether the app is in the intended list. A connection indicator in the VPN client shows that a tunnel or proxy session is active; it does not verify the route chosen for every application.

For a useful comparison, keep other settings unchanged between tests. Do not simultaneously switch profiles, DNS modes, app permissions, and the split-tunneling list: if behavior changes, you will not know which change mattered. Where the client provides connection logs, check them for timestamps or route decisions related to the test. Treat logs as diagnostic evidence, not as proof that every request was captured.

Verify the Result Without Overreading One Test

Verification should match the app and the route you intended. If the selected app is supposed to use the VPN, confirm that it can complete its normal network action while the VPN is connected. If it is supposed to bypass the VPN, confirm that it still works with the VPN active and check the client’s route display or logs when available. A successful page load alone cannot tell you which path carried the request.

Use more than one observation when the distinction matters. A browser-based IP check reports the browser’s connection, not the route of every app on the phone. A DNS test may indicate which resolver answered a particular query, but it does not prove that all traffic from that app follows the same route. Likewise, an app’s own “online” indicator may remain visible from cached data even when a new request fails. Combine the client’s status, a fresh app action, and any relevant diagnostic information the client exposes.

Android app routing may also be affected by apps that open links in another application, shared system services, or separate work-profile installations. The same app name can appear more than once if the device has a personal profile and a managed profile. Select the correct entry and test from the profile where you actually use the app. If the client’s app picker does not show the expected application, check for a work profile, cloned app, or installation issue before assuming that routing is broken.

Connection behavior can differ across Android versions, device manufacturers, client releases, and network types. Battery management may pause background activity, while a Wi-Fi-to-mobile transition can briefly interrupt a session. Those issues are not necessarily caused by the app list. Test with the screen active first, then test background behavior separately if that is part of your use case. Change one factor at a time so that an operating-system restriction is not mistaken for a routing rule problem.

• ✅ Confirm the selected app’s intended route in the client’s own wording.
• ✅ Test a fresh network action in the target app, not only its cached home screen.
• ✅ Check a second app that should follow the opposite route.
• ✅ Repeat on the network type you actually use and after a reconnect.
• ❌ Do not treat a browser IP check as proof of every app’s route.
• ❌ Do not change routing, DNS, battery, and profile settings all at once.

Troubleshoot a Broken App or Undo the Change

If an app stops connecting after you change the list, first restore the last known configuration. Remove the most recently changed app selection, check whether you selected the correct include or exclude mode, and reconnect the client if it requires that step. Then test the app again without making any additional changes. This quick rollback helps distinguish a routing selection from a broader service outage or an unrelated device setting.

If the app still fails, temporarily turn off split tunneling or return to the client’s default app-routing state, then reconnect and retry the same action. If the app works in the default state, the list mode, selected entry, or an interaction with Android’s VPN restrictions is a likely area to inspect. If it still fails, investigate the client connection, profile, app sign-in, network access, and system-level VPN options separately.

Check always-on VPN and lockdown settings only if you understand their effect. A setting that blocks traffic outside the VPN can prevent excluded apps from connecting directly; disabling it without considering the privacy consequences can also change the device’s behavior when the tunnel disconnects. If the device is managed by an organization, its administrator may control VPN or work-profile behavior. Follow the applicable device policy rather than attempting to bypass it.

For persistent failures, collect information that helps isolate the issue: Android version, device model, client name and version, selected list mode, whether the app is included or excluded, network type, and the time of a failed test. Remove account identifiers, subscription links, and other private details before sharing diagnostics. A subscription URL can grant access to configuration data; do not paste it into public discussions or send it to an unverified support contact.

Once the app works again, make only the routing change you need and keep the list understandable. Revisit it after reinstalling an app, changing profiles, or updating the VPN client, since the app picker or client behavior may change. If split tunneling is unnecessary, leaving it disabled is a valid way to reduce configuration complexity. The right setup is the one you can explain, verify, and undo—not the one with the most rules.

• ✅ Save or note the original mode and app selections before troubleshooting.
• ✅ Roll back the last change first, then retest the same app action.
• ✅ Test the default routing state to separate list issues from connection issues.
• ❌ Do not share subscription links or private account details in diagnostic reports.
• ❌ Do not leave an app excluded if you are unsure what direct routing means for it.