Android split tunneling lets you choose which apps send traffic through a VPN and which use the phone’s ordinary internet connection. It can be useful when one app needs a VPN route while another depends on a local network, nearby devices, or a service that works better with a direct connection. The exact controls depend on the VPN client: some offer an app list, some provide include-or-exclude modes, and others do not support per-app routing at all.

Understand what Android split tunneling changes

When a VPN app creates an Android VPN connection, it can request that Android route traffic from selected applications into the tunnel. Depending on the client, you may either choose the apps that use the VPN or choose the apps that bypass it. These are opposite policies, so read the control’s wording carefully before selecting anything. “Only selected apps use VPN” is not the same as “selected apps bypass VPN.”

App routing is usually based on the Android application installed on the device, rather than on an individual website or a URL. If a browser is routed through the VPN, its traffic to many different sites may follow that route; the setting generally cannot send one website through the VPN and another website directly within the same browser. Likewise, a social app may contact several services for sign-in, images, notifications, and media, all under the same app selection.

Split tunneling does not create two independent VPN connections. It changes which app traffic is assigned to the active VPN. An app set to bypass the tunnel normally uses the current network connection, such as Wi-Fi or mobile data. That can help with local services, but it also means that app’s traffic is not protected by the VPN tunnel. If you are uncertain which route a sensitive app should use, leave it on the default policy until you have checked the app’s requirements.

2

Common policies: include or exclude

1

Active Android VPN connection at a time

0

Guarantee of website-level routing from an app list

Those figures describe the basic routing model, not a promise that every Android version or client presents the same controls. Android versions, device manufacturers, work profiles, and client implementations can change the available options. Check the app’s own documentation and settings rather than assuming that a feature shown in another client will also appear in yours.

Check client support and choose a policy

Start by confirming that the Android VPN client you intend to use offers per-app routing. Look in its connection, routing, or split-tunneling settings, and check whether the feature is available for the current configuration. A subscription link supplies configuration information to a compatible client; it does not by itself guarantee that the client supports Android app selection. A client may import a connection successfully while still lacking the routing controls you need.

Before changing the list, decide which behavior you want:

  • Include selected apps: the apps you select use the VPN, while other apps ordinarily connect directly. This is often easier when only a small number of apps need the tunnel.
  • Exclude selected apps: traffic from selected apps bypasses the VPN, while other apps ordinarily use it. This can suit a setup where most apps should use the tunnel but a few need a direct route.
  • No app list or unclear wording: do not infer support from a general “proxy” or “VPN” label. Review the client’s help information, or use its default routing until the behavior is clear.

Write down the intended outcome in plain language before selecting packages: for example, “the work app uses the VPN; the local printer app stays direct.” This simple check prevents a common mistake: choosing an exclude list when you meant to create an include list. If the interface describes an allowlist, bypass list, or application filter, read its explanation and verify the result with a non-sensitive app before relying on it.

Also check whether the app list includes every app you care about. A browser and a separate streaming app are distinct Android applications, even if they open related content. Some apps use companion processes or browser-based sign-in, so a selected app may depend on another component that follows a different route. A list organized by package name or icon may not make those dependencies obvious.

Choose the policy first: Decide which apps should use the tunnel and which should bypass it, then confirm whether the client labels its list as an include rule or an exclude rule.

Set up and verify app rules

The following workflow applies to clients that expose Android per-app routing. Names and menu locations vary, so treat these as checkpoints rather than exact button labels. If you use VPNNV with an Android client, the connection still depends on the client’s own routing controls and compatibility; check the client documentation for the exact interface.

1

Confirm the routing mode

2

Select the intended apps

3

Reconnect and test each route

  1. Confirm the base connection first. Connect without changing app rules and verify that the client reports an active connection. Test one ordinary app that should use the VPN. If the base connection does not work, resolve that issue before adding app-level rules; otherwise, it will be difficult to tell whether the problem comes from the tunnel or the selection list.
  2. Open the app-routing controls. In the VPN client, look for a section named split tunneling, per-app proxy, application routing, or a similar term. If no such option is present, do not assume Android’s system settings can add it to a client that does not implement the feature.
  3. Read the mode description. Determine whether the list means “route only these apps through VPN” or “bypass VPN for these apps.” If the interface offers a choice between the two, select the mode before selecting apps. Take a screenshot for your own reference if useful, but avoid capturing subscription links, credentials, or other private information.
  4. Select apps by their actual installed entries. Add the app or apps that match your intended policy. If a work-profile copy appears separately, treat it as a separate entry unless the client says otherwise. Avoid selecting every app merely to make the list look complete: a broad rule can cause direct-only services to lose local access, or can send apps through the VPN when you expected them to bypass it.
  5. Save the rule and reconnect. Some clients apply changes immediately; others require disconnecting and reconnecting. Follow the client’s instruction, then check that the connection is active again. If the client has a configuration update control, do not confuse updating a subscription with saving app rules: one refreshes imported connection information, while the other changes local routing behavior.
  6. Test one app from each group. Open an app intended to use the tunnel and confirm that it can reach the service you need. Then test an app intended to bypass it, preferably one that should work directly on the current Wi-Fi or mobile network. A successful connection alone does not prove which route was used; use the VPN client’s connection details or a reputable IP-checking method where appropriate, and interpret results carefully because cached content and app-specific network behavior can be misleading.
  7. Record the working state. Note the selected mode, selected apps, and whether the client requires reconnection. This makes later changes easier to diagnose, especially after a client update, Android update, or network change.

Test with low-risk activity first. For example, load a basic page or open a non-sensitive service rather than initiating a payment, changing an account security setting, or sending confidential data. If an app behaves differently over Wi-Fi and mobile data, test each connection separately; a rule can be correct while the underlying network blocks or handles the destination differently.

Troubleshoot apps that stop working

If an app loses access after enabling split tunneling, first identify the intended route and the actual policy mode. A reverse-mode mistake is easy to miss: an app selected in an include list is routed through the VPN, while the same selection in an exclude list may bypass it. Compare the current setting with your written intention, correct the mode if necessary, then reconnect and test again.

If only one app fails, remove or change that app’s rule temporarily and compare its behavior with the default connection. Check whether it uses a separate sign-in page, browser, or companion app. If the main app is included but its sign-in component is not, the workflow may fail even though the app itself can open. Add only the required component after confirming its role; avoid broad changes that make unrelated traffic follow an unintended route.

If all apps lose connectivity, turn off the app filter temporarily and test the base VPN connection. Then check whether Android is showing a VPN permission prompt, whether another VPN client is active, and whether the selected configuration is still available in the client. Android generally allows one active VPN service to manage the system VPN interface at a time, so two VPN apps may conflict or one may disconnect the other. Close or disconnect the competing client before testing again.

When a direct-route app fails but VPN-routed apps work, check the ordinary network itself. The direct app does not inherit the VPN route, so it can be affected by local Wi-Fi rules, mobile carrier behavior, DNS settings, or restrictions imposed by the destination service. Conversely, if an app that should use the tunnel appears to bypass it, verify the client’s selected mode and whether the app is actually included. Restarting the app or reconnecting the VPN may be needed for an application to establish new network sessions after a rule changes.

  • ✅ Verify whether the list is an include list or a bypass list.
  • ✅ Reconnect the VPN after changing rules if the client requires it.
  • ✅ Test the base connection with app filtering temporarily disabled.
  • ✅ Check separate work-profile, browser, or companion-app entries.
  • ❌ Do not run multiple VPN clients at once while diagnosing routing.
  • ❌ Do not treat a page loading once as proof that every app follows the intended route.

Keep troubleshooting changes small: change one rule, reconnect if needed, and retest the affected app. If the problem began after an update, check the client’s release notes or support materials for changes to Android compatibility or routing behavior. Do not paste a private subscription URL, password, or complete configuration into a public forum while asking for help; describe the client, Android version, routing mode, and symptoms without exposing access credentials.

Choose a practical default and maintain it

There is no universal best split-tunneling list. An include policy can be straightforward when only a few apps need the VPN, while an exclude policy can be convenient when most apps should use it and a small set needs direct access. Choose based on the apps you actually use and the privacy or connectivity requirements of each one, not on the number of entries in the list.

Review the rules after reinstalling an app, adding a work profile, changing VPN clients, or updating Android. A package may be renamed, duplicated in another profile, or removed and reinstalled, and a previously saved selection may no longer match the app you intended. After any significant change, repeat the basic test for one app in each routing group. If you cannot establish which route an app is taking, temporarily return to the client’s default policy rather than assuming that the rule is working.

Finally, treat bypass rules as a deliberate network choice. Direct traffic may be necessary for local devices or a service that does not work through the tunnel, but it does not receive the VPN’s tunnel routing. VPN routing also does not replace an app’s own account protections, Android security updates, or careful handling of sensitive information. A clear list, a known mode, and a repeatable test are more useful than a complicated configuration whose behavior you cannot verify.

Practical takeaway: Start with the simplest app list that meets your needs, verify both routed and bypassed apps, and revisit the rules whenever the client or device setup changes.