Android VPN Split Tunneling Guide: Choose Which Apps Use VPN

Android VPN split tunneling lets you choose which apps send traffic through a VPN and which continue using their usual network connection. It can be useful when one app needs a VPN exit region while another works better with your regular connection, or when a local service does not cooperate with VPN routing. The exact controls depend on the VPN client and Android version, so read each setting’s description carefully: “include selected apps” and “exclude selected apps” produce opposite results.

Before changing anything, decide which apps need the VPN and which should stay outside it. Then test both groups instead of assuming that a connected VPN means every app follows the same route. Split tunneling changes the path for selected app traffic; it does not change the account region, permissions, or access rules of the services you use.

Understand split tunneling

A VPN connection creates a network path for traffic from your device. With full-device routing, the VPN client generally attempts to send the device’s traffic through that path. Split tunneling adds an app selection rule: traffic from some apps uses the VPN, while traffic from other apps uses the ordinary connection provided by Wi-Fi or mobile data. The exact meaning of “ordinary” depends on the active network and Android’s system settings.

Most Android clients present one of two basic policies. An include list means only the apps you select use the VPN; other apps are excluded from the tunnel. An exclude list means the selected apps bypass the VPN and other apps use it. Some clients describe these policies as “VPN for selected apps” and “bypass VPN for selected apps.” Do not infer the policy from the list itself: check the heading, help text, or confirmation screen before saving.

App-based routing is not the same as choosing a different route for a website. In many clients, the rule applies to an app as a whole rather than to individual domains or pages. If you put a browser in the VPN list, its traffic generally follows that app’s selected route, even when you visit a local website. A separate app that opens the same website may follow a different route because it has its own rule.

Android VPN apps commonly use the system’s VPN interface to establish a local VPN service and apply traffic rules. The client controls how it exposes those rules and how it handles details such as DNS and IPv6. A per-app list therefore should not be treated as a guarantee that every request from an app will behave identically on every device. Android version, manufacturer changes, app permissions, and the VPN client’s implementation can all affect the result.

Choose an include or exclude list

Choose the policy that makes your intended behavior easiest to check. If only a few apps need the VPN, an include list can be easier to review: select those apps and leave the rest out. If nearly all apps should use the VPN except for a small number of local or incompatible apps, an exclude list may be more convenient. Neither choice is inherently more private or more reliable; the outcome depends on which apps you select and whether the client applies the list as expected.

• Use an include list when: You want a short, explicit set of apps to use the VPN, while most other apps stay on the normal connection. Review the list whenever you install an app that should also use the tunnel.
• Use an exclude list when: You want most apps to use the VPN and have only a small set bypass it. Be deliberate about excluded apps because their traffic will not receive the VPN route.
• Use full-device routing when: You do not need per-app exceptions, or you want a simpler baseline while checking whether the VPN connection itself works.

Consider the consequences for both groups. An app routed outside the VPN can use the network’s ordinary public connection, so the destination service may see the connection associated with that network rather than the VPN exit. Conversely, an app routed through the VPN may no longer reach a device or service that is available only on the local network, depending on the VPN configuration. Split tunneling changes traffic paths; it does not make excluded traffic private from the network it uses.

Also check whether your phone has separate instances of an app. A work-profile app, a cloned app, or an app installed in another Android user profile may appear as a separate entry or may not be governed by the rule you expect. If your work profile is managed by an organization, its administrator may control VPN behavior. Do not assume that selecting a personal-profile app also selects its work-profile counterpart.

When comparing client options or setup guidance, use the VPNGH homepage as a starting point for the supported platform information, then confirm that the Android client you actually use exposes the per-app controls you need. Client interfaces and available options can change; a feature described for another operating system or another client may not apply to your Android setup.

Configure the rules on Android

Settings names differ among VPN clients, so use the steps below as a general workflow rather than a promise that every menu has the same label. Keep the client’s own instructions nearby, and avoid changing unrelated system network settings during the initial setup. Testing one change at a time makes it easier to identify a mistaken selection or a client-specific limitation.

1. Confirm the baseline. Open the VPN client, connect using the route you normally use, and check that a basic app you expect to use through the VPN can load. If the baseline connection does not work, fix that first; split tunneling adds another variable.
2. Find the app-routing control. Look in the connection, VPN, or advanced settings for wording such as “per-app VPN,” “app routing,” “split tunneling,” or “bypass selected apps.” The location and terminology vary between clients.
3. Select the policy before selecting apps. Confirm whether the screen is asking which apps should use the VPN or which apps should bypass it. If the client offers both modes, choose one and read any notice about apps not on the list.
4. Review the app list carefully. Select the intended app entries, including the correct profile or duplicate where applicable. If an app is missing, check whether it is installed, whether the client needs a refresh, and whether Android or a work-profile administrator restricts access to it.
5. Save and reconnect if requested. Some clients apply changes immediately; others require you to reconnect or restart the VPN service. Follow the client’s prompt, and allow Android to show its VPN permission confirmation if it appears.
6. Test one app from each group. Open an app that should use the VPN and verify its connection behavior. Then open an app that should bypass the VPN and check that it still works as intended. Use the same Wi-Fi or mobile-data connection for both tests.

For a reliable comparison, keep the selected VPN region and local network unchanged while testing. Check an app’s sign-in, content loading, and any function that matters to you, rather than relying only on the VPN icon or a single speed test. If the service provides a legitimate way to display connection region, use it as one signal, not as proof that every request from every component of the app followed the same path.

Record the original setting before you change it. A simple note such as “include list: browser and work app” or “exclude list: local banking app” can help you reverse a test later. Avoid changing the app list, VPN region, DNS option, and Android Private DNS setting at the same time; otherwise, a working or broken result will not reveal which change mattered.

Test the routing rules in a useful order

Test at three layers: the VPN connection, the selected app, and the app that should bypass the tunnel. This catches common cases where the client says it is connected but the list is reversed, an app instance was missed, or an app is unable to use the chosen network path. Repeat the checks after switching between Wi-Fi and mobile data if you rely on both, because the ordinary connection outside the tunnel changes with the active network.

• ✅ Confirm that the VPN client reports a connected state before testing app rules.
• ✅ Open an app that should use the VPN and check a normal task such as loading content or signing in.
• ✅ Open an app that should bypass the VPN and confirm it can still reach the service you need.
• ✅ Check the exact work-profile, cloned, or second-user app entry if your phone has more than one instance.
• ❌ Do not treat a VPN icon alone as proof that the intended app is routed through the tunnel.
• ❌ Do not use a speed result from a different network or device as a direct comparison.

When one app fails, first check whether it is in the correct list. Then temporarily return to full-device routing, if the client offers it, and test again without changing the VPN region or local network. If the app works with full routing but not with the split rule, the issue is likely related to the selection, the app instance, or the client’s per-app behavior. If it fails in both modes, investigate the VPN connection, the app account, and the local network separately.

Some apps rely on more than one visible app entry. They may open a browser, invoke an authentication component, or use a system service to complete part of a task. That can make a login flow appear inconsistent even when the main app is selected correctly. Check whether the related component is listed by the client, but do not add every system component blindly: routing changes can affect unrelated Android functions. Follow the VPN client’s documentation when it identifies components that must be included or excluded.

DNS and IPv6 behavior deserve separate attention during troubleshooting. VPN clients differ in how they handle DNS requests and IPv6 traffic, and Android’s Private DNS configuration can also affect name resolution. If an app connects but resolves a service unexpectedly, test with the client’s documented DNS settings before making broader changes. Do not assume that an app exclusion automatically disables every VPN-related setting, or that a DNS change proves which route carried the app’s other traffic.

Troubleshoot or undo a rule

If an app stops connecting after you enable split tunneling, start with the simplest reversible checks. Confirm whether you selected an include or exclude policy, then verify the app’s position in that list. Reconnect the VPN if the client asks you to apply changes. Close and reopen the affected app so it creates a fresh network connection, and check whether the issue occurs on both Wi-Fi and mobile data.

• The wrong apps appear affected: Re-read the policy label and check whether the list means “use VPN” or “bypass VPN.” Switch back to the intended mode only after confirming how the client interprets existing selections.
• An app is missing from the list: Refresh the list or restart the client if its instructions recommend doing so. Check for a work-profile or cloned version, and confirm that Android has not restricted the app.
• A local service no longer works: Test the app with full-device routing or add a deliberate bypass only if the client supports it and the service requires the ordinary local route. Recheck the change afterward.
• Only sign-in or embedded pages fail: Check whether a browser or authentication component is handling part of the flow. Use the client’s guidance rather than changing unrelated system apps at random.
• Nothing connects in either mode: Restore the original app-routing setting, reconnect, and test the basic VPN connection before investigating split-tunneling rules further.

To undo the configuration, remove the app selections or choose the client’s full-device/default routing option, then save and reconnect as prompted. If the client has a separate switch to turn split tunneling off, disabling it is often clearer than leaving an empty or ambiguous list. Verify the result with one app you previously routed through the VPN and one app you previously excluded.

Do not leave an app outside the VPN merely because bypassing it fixed a connection problem. First decide whether using the ordinary network is acceptable for that app and task. If not, restore VPN routing and investigate the service’s own connection requirements, the client’s route selection, and any account or regional restrictions. App access is determined by more than the VPN path, and a successful tunnel does not guarantee that a third-party service will accept a connection.