Android VPN Split Tunneling: Choose Which Apps Use the VPN

Android VPN split tunneling lets you choose which apps send traffic through a VPN and which connect directly. It is useful when, for example, you want a browser or messaging app to use a VPN while a banking, casting, or local-network app connects through your regular internet connection. The exact controls depend on the VPN client: some offer an app list, while others expose routing rules through a compatible configuration. Android settings can also affect the result, especially when Always-on VPN or “Block connections without VPN” is enabled. This guide explains how to choose a mode, configure it, test the routes, and return to routing all apps through the VPN.

What split tunneling changes on Android

In a full-tunnel setup, the VPN is intended to carry network traffic from all apps through the selected VPN connection. With per-app split tunneling, the client uses an app selection to decide which traffic enters the tunnel and which traffic bypasses it. Depending on the client, you might select the apps that use the VPN, or instead select the apps that are excluded from it. Those two options sound similar, but their defaults are opposite, so read the mode description before changing the list.

App-based routing applies to network traffic associated with the selected apps; it does not make an app’s content or account independent of its network. An app using the VPN may see the VPN exit’s public IP address, while an excluded app normally uses the device’s direct connection. That direct route may expose the public IP address assigned by your internet provider or mobile carrier. If you switch between Wi-Fi and mobile data, the direct route can change as well.

Split tunneling is not the same as choosing a server location, changing a browser’s proxy setting, or selecting a DNS provider. A VPN client may offer these controls in nearby menus, but they affect different parts of the connection. Similarly, selecting an app in a routing list does not guarantee that every feature of that app uses only one route: an app may use system services, open links in another app, or have its own network behavior. Test the tasks you actually use rather than relying on the label in the settings screen.

Choose which apps should use the VPN

Start with a short list based on what each app needs to reach. An international browser or a service that you specifically want to access through a VPN may belong in the VPN-routed group. An app that needs to discover a printer or another device on your home network may work better outside the tunnel, depending on the client and network. A local banking or payment app might also be more predictable on a direct connection, but do not assume that every service requires this; check its behavior and any applicable rules.

For each app, decide whether the VPN or direct routing is the intended path. Avoid changing several unrelated apps at once. If something stops working, a small list makes it easier to tell whether the cause is the selected route, the VPN connection, the app itself, or an Android system restriction. Also consider how an app is opened: a link tapped in one app may launch a browser or another app that has its own routing selection.

• ✅ Route an app through the VPN when you want its traffic to use the selected VPN connection and exit location.
• ✅ Exclude an app only when you understand that it will use the device’s direct internet connection.
• ✅ Keep the initial selection small, then add or remove apps after testing each use case.
• ❌ Don’t assume that an app is excluded just because a related website or another app is excluded.
• ❌ Don’t use a successful connection indicator as proof that every selected app follows the intended route.

Before setting up the list, check that the VPN client actually provides per-app routing on your Android version. Availability and menu names vary by client, release, and device manufacturer. A client that imports a subscription can provide server choices without necessarily offering an app-selection control; importing configuration and choosing which apps use the VPN are separate steps. If you need to install or compare an Android client, the VPNND homepage is a starting point for finding the available service information. Verify the specific client’s settings before depending on split tunneling.

It can help to write down the desired behavior in plain language before opening the settings. For example: “Browser A uses the VPN; payment app B connects directly; all other apps use the VPN.” This makes it easier to distinguish an include list from an exclude list and to notice unintended exceptions. If your client offers only one of those modes, translate your plan carefully: an include list may require you to select each app that should use the tunnel, while an exclude list may require selecting only the apps that should bypass it.

Configure per-app routing step by step

The following sequence works as a general method, though the exact labels and screens differ. Keep the VPN client connected while testing where possible, and change one setting at a time. If the client has a separate profile or configuration selector, first select the profile you intend to use; app rules may be stored per profile rather than globally.

1. Open the VPN client and connect to the location or profile you intend to use. Confirm that the client reports an active connection before changing app rules.
2. Open the client’s settings and look for wording such as “Split tunneling,” “Per-app VPN,” “App routing,” “Include apps,” or “Exclude apps.” If you cannot find such a control, consult that client’s own help information instead of assuming Android’s system settings provide an equivalent app list.
3. Read the mode description. Determine whether the displayed apps will go through the VPN or bypass it. Some clients present a choice between the two modes; others show only one list with a short explanation.
4. Select the apps for the chosen mode. Use the app’s displayed name and icon to avoid selecting a similarly named app or a companion component by mistake. If the list has a search field, search for the installed app rather than typing a website address.
5. Save or apply the changes if the client requires it. Some apps may need to be closed and reopened before a new connection uses the updated route. Disconnecting and reconnecting the VPN can also help the client apply a revised configuration.
6. Test one selected app and one app on the other route. Use a fresh request, such as loading a new page or refreshing account data, instead of judging by a screen that was already loaded before the change.
7. Record the working configuration or take a private note of the selections. Do not share screenshots that reveal a subscription link, account information, or other sensitive details.

For a meaningful test, use a network check that reports the public IP address within each app or browser you are evaluating, where the app supports such a check. Compare the result with the route you intended: a VPN-routed app should show the VPN exit rather than the ordinary connection, while a bypassed app should use the direct route. Do not treat a DNS result alone as proof of the full traffic path; DNS handling and application traffic can be configured differently. If your client provides connection logs or route indicators, use them as supporting evidence, not as a substitute for testing the app itself.

After confirming the basic selection, repeat the test on the networks you commonly use. A setup can behave differently after changing from Wi-Fi to mobile data, reconnecting after sleep, or switching the active VPN profile. Test only one change at a time and restore the prior selection if the result becomes unclear. The point is not to generate a large list of exceptions, but to keep the route understandable and easy to maintain.

Check Android system settings and limitations

Android’s VPN settings can affect how an app-level configuration behaves. Depending on the Android release and device, settings may include “Always-on VPN” and “Block connections without VPN.” Always-on VPN can ask Android to keep a selected VPN app active. The blocking option is designed to prevent connections outside the VPN when the tunnel is unavailable. If bypassed apps stop connecting after you enable such a restriction, check how the client and Android handle excluded traffic before assuming the app list is broken.

Do not switch on a blocking option without understanding its effect on your intended split-tunnel setup. A restriction that blocks traffic outside the VPN may conflict with the reason you excluded an app in the first place. The exact interaction can depend on Android, the device manufacturer, and the VPN client. If you need a particular app to connect directly, test that use case after changing any system-level VPN option. If the app cannot reach the network, restore the previous system setting and retest before making further changes.

Other Android behaviors can complicate diagnosis. Battery management may pause a client in the background; a device may restrict background data for an individual app; and an app may rely on a system component that is not included in the visible app list. A work profile or managed device may also apply policies that you cannot change yourself. If the route works while the client is open but fails later, investigate background restrictions separately from the app selection. Changing battery settings will not correct a mistaken include/exclude mode, just as changing the app list will not necessarily correct a client that has been stopped by the system.

Some services use multiple app components, browser handoffs, or operating-system services to complete a task. For example, an app may open a web page in a separate browser, so the browser’s route determines the connection for that page. Add or remove the browser only if that matches your intended behavior; changing its route may affect every site opened in it. Avoid relying on an app label to predict every connection it will make, especially when a task moves between apps.

Troubleshoot problems or restore full-tunnel mode

If an app fails after you enable split tunneling, first identify whether it is meant to use the VPN or bypass it. Check the client’s mode, app list, selected profile, and connection status. Then test the same app with the split-tunnel feature temporarily disabled, if the client provides that option. If it works with split tunneling off, re-enable the feature and add or remove only that app. This comparison helps isolate a routing issue without changing unrelated settings.

If an app that should use the VPN appears to connect directly, check for an exclude-list mode, a duplicate app entry, or a second browser that opened the request. Confirm that the VPN is active and that the client has applied the current profile. If a bypassed app appears unable to connect, check whether Android’s blocking option is preventing direct traffic, then review the client’s explanation of excluded apps. A cached result or an existing session can also mislead you; close the app, reopen it, and make a fresh request before judging the route.

To return to full-tunnel behavior, use the client’s control to disable split tunneling or clear the app exceptions. If the interface requires a list, follow its description: an empty include list might mean no apps use the tunnel, whereas an empty exclude list might mean no apps bypass it. Never infer the meaning from an empty screen alone. Reconnect the VPN if needed, then test a few apps that previously used different routes. If you enabled Android’s Always-on or blocking settings during testing, review those separately and restore the configuration that matches your needs.

Keep the final setup simple. A small, documented set of exceptions is easier to audit than a long list whose purpose is unclear. Recheck the list after reinstalling an app, changing VPN clients, importing a different profile, or updating Android, because app names and client behavior can change. If the routing control is unavailable or the result remains inconsistent, use full-tunnel mode while you investigate rather than assuming that traffic is following a route you have not verified.