Android Split Tunneling Setup: Choose Which Apps Use VPN

What Android Split Tunneling Changes

Split tunneling lets you choose which apps send traffic through a VPN connection and which use the device’s ordinary network. For example, you might route a work app through the VPN while letting a local banking app connect directly, or do the reverse if you need a particular app to use the VPN and want other apps to keep their usual route. The setting applies to app traffic on the Android device; it does not change an account’s country, a service’s eligibility rules, or the network route used by another device.

On Android, per-app routing is usually configured inside the VPN client. The client uses Android’s VPN service to create a device-level connection and, if it supports the feature, specifies which installed apps are included or excluded. Menu names and available controls differ by client version, Android release, and sometimes the connection profile. A guide for one app may therefore show controls that do not exist in another.

Look for terms such as Split tunneling, Per-app VPN, App routing, Included apps, or Excluded apps. If none appears, check the client’s current documentation or settings before assuming Android has a separate universal switch. The Android system VPN screen can show the active connection, but it generally does not provide the same per-app selection interface as a VPN client.

There are two common selection models. An allowlist, sometimes called “only selected apps,” sends the chosen apps through the VPN and leaves other apps direct. A blocklist, sometimes called “exclude selected apps,” sends most apps through the VPN but leaves the chosen apps direct. The labels are not always intuitive: read the description in the client and confirm the resulting route rather than relying on a checkbox’s position.

Choose Apps by Their Network Needs

Start with the task, not a long list of app names. Ask whether an app needs the VPN’s exit location, whether it must reach devices or services on your local network, and whether you can tolerate it using your ordinary connection. An app that works correctly in one routing mode may fail in the other because it depends on a different region, network address, or route to a local resource.

• ✅ Route an app through the VPN when its connection needs the VPN route or exit region, and verify that the app works after connecting.
• ✅ Consider a direct route for an app that must reach a local printer, local streaming device, or other resource on your home network.
• ✅ Keep apps with sensitive or work-related traffic in the route required by your organization or your own security policy.
• ❌ Do not assume that excluding an app makes it more secure; excluded traffic normally uses the regular network connection.
• ❌ Do not change several routing settings at once. A single change makes it easier to identify what fixed or caused a problem.

App categories are only starting points. A browser may contain both local and international services; a messaging app may use separate processes for messages, calls, and notifications; and a work app may rely on a browser or authentication component. If the client lists several related apps, use the app names and descriptions to identify the actual package you need. Avoid excluding system components just because their names are unfamiliar.

Local-network access deserves particular attention. When an app is sent through a remote VPN route, it may no longer be able to discover devices that are reachable only on the local Wi-Fi network. Some clients offer a separate option for local network access; others do not. If you need a printer or local device, test that task and consult the client’s own setting descriptions rather than assuming split tunneling automatically preserves local access.

Likewise, a direct app can expose its network traffic to the local network and internet connection instead of the VPN. That may be appropriate for a trusted local service or an app that is incompatible with the VPN route, but it is a deliberate routing choice. For a managed work device, follow your organization’s policy before changing which apps use the VPN.

Configure Per-App Routing on Android

Menu wording and screen order vary, so treat the following as a reliable workflow rather than an exact path for every Android device. Before changing settings, update the VPN client from its official source, connect to the profile you intend to use, and note whether the client currently routes all apps through the VPN. If you need the service’s official setup instructions, the TangVPN site is a starting point for checking available resources; per-app options still depend on the Android client you have installed.

1. Open the VPN client. Find the connection or profile settings, then look for per-app routing, split tunneling, or an app selection screen. Do not confuse this with Android’s list of installed apps or a general battery-optimization menu.
2. Read the mode description. Determine whether the screen selects apps to route through the VPN or apps to bypass it. If there is a toggle between “include” and “exclude,” read the explanatory text before continuing.
3. Select a small test set. Choose one app that should use the VPN and, if useful, one app that should connect directly. Avoid selecting unrelated system apps. Some clients show only apps they recognize or apps installed for the current user profile.
4. Save and reconnect if requested. Some clients apply changes immediately; others require you to reconnect or rebuild the VPN connection. Follow the prompt. Android may display a system confirmation the first time a VPN connection is established or when a client changes its VPN configuration.
5. Test each route separately. Open the app expected to use the VPN and verify its connection. Then check the app expected to bypass it. Use a trusted IP-checking method in the relevant app or browser when appropriate, and compare the observed route with the route you intended. A browser check only describes the browser’s path, not every app’s path.
6. Record the working configuration. Note the selection mode and the apps you changed. If an update or profile switch later changes the behavior, this record helps you restore the intended configuration without rebuilding it from memory.

For a useful test, use the same network and the same app account before and after changing the selection. Check more than whether an app opens: sign-in, content loading, notifications, calls, or access to a local device may use different network requests. If the service has its own regional restrictions, account requirements, or location permissions, VPN routing does not remove those conditions.

Verify the Route and Understand the Trade-Off

A successful VPN connection does not prove that every app uses it. Per-app rules can send different apps along different paths, and a VPN client’s connected indicator usually confirms the device-level VPN session rather than the behavior of every app. Verify the apps that matter individually. If the client provides a routing status or app list, use it as an additional check, but confirm with the actual service or task as well.

When checking an exit address, use a method that belongs to the app being tested where possible. A web-based IP check in one browser can confirm that browser’s apparent route, but it cannot establish that a separate email, work, or media app uses the same route. Also remember that an app may use a proxy setting, a built-in secure connection, or a secondary process; its behavior can differ from what a browser test suggests.

Split tunneling creates a practical balance between reachability and routing consistency. Letting an app connect directly can restore access to a local service or avoid a route that the app does not handle well. The trade-off is that the app’s traffic no longer receives the VPN route. Sending an app through the VPN can provide a consistent VPN path for that app, but may prevent it from reaching local devices or services that expect the ordinary network.

Android may also offer an always-on VPN option and a setting that blocks connections without a VPN. Their interaction with per-app routing depends on the Android version and client implementation. A lockdown setting can prevent direct traffic when the VPN is unavailable, which may conflict with your expectation that excluded apps will use the ordinary connection. Review the system and client descriptions together, and test what happens after a disconnect before relying on a particular fallback behavior.

DNS behavior can also affect what you observe. An app may use its own DNS-over-HTTPS service, a platform resolver, or another built-in connection method. Consequently, an IP or location check may not tell the whole story about how every request is routed. Treat discrepancies as a reason to inspect the app and client settings, not as proof that one specific component is broken.

Troubleshoot Missing Settings or Apps That Lose Connectivity

If you cannot find a split-tunneling control, first confirm that you are using the intended Android client and connection profile. A desktop client’s instructions may not apply to Android, and the Android version may expose different options. Update the client, inspect the profile’s advanced settings, and search its help materials for both “per-app VPN” and “split tunneling.” If the feature is not offered for that client or profile, Android does not necessarily provide a hidden equivalent that can be enabled system-wide.

If an app is missing from the selection list, check that it is installed for the Android user or work profile currently in use. App cloning, a managed profile, a paused app, or multiple versions of an app can make the visible name different from the one you expect. Restarting the VPN client after installing or updating an app may refresh its list. Do not choose a similarly named system package unless you know it belongs to the app you want to route.

If an app stops connecting after you change its route, return it temporarily to the previous mode and test again. If it works on the ordinary network but not through the VPN, check the selected profile, reconnect, and test a different available connection in the client if one is offered. If it works through the VPN but not directly, check the local network, DNS behavior, app permissions, and any service requirement that could restrict the direct connection. These checks help distinguish routing from account or service problems.

• Only one app fails: Confirm that the intended app—not a related process or duplicate—is selected. Revert that one selection and compare behavior.
• Several apps fail after saving: Verify whether the mode is an allowlist or blocklist, then reconnect the VPN and recheck the selected apps.
• Local devices disappear: Test the app on the ordinary network and review any local-network access option in the VPN client.
• Apps fail when the VPN disconnects: Review always-on and lockdown settings, then test the client’s documented disconnect behavior.
• The setting is absent: Check the Android-specific client documentation and profile options; do not assume instructions for another platform apply.

Finally, restore a simple configuration before escalating a complicated issue: connect the VPN, use the default routing mode, and verify that the affected app works. Then reapply one per-app change and test again. This controlled comparison is more useful than toggling several Android permissions, DNS options, and routing rules at the same time. If the problem remains, note the Android version, client version, selected mode, affected app, and whether the app works when routed directly or through the VPN. That information makes further troubleshooting more precise without assuming that every failure is caused by split tunneling.