Android split tunneling lets you choose which apps send traffic through a VPN and which connect over the ordinary network. The useful part is not simply excluding a streaming or banking app: it is being clear about which rule the client applies, then checking that the app, DNS requests and background connections follow the route you intended. The exact menu names differ between Android versions and VPN clients, so treat the steps below as a method rather than a promise that every app has the same switches.

The safest approach is to change one routing rule at a time. First identify whether your client is set to include selected apps or exclude selected apps, then test a small number of apps on both routes. If a test fails, you can usually correct the app list or a conflicting system setting without deleting the subscription or rebuilding the whole VPN profile.

What split tunneling changes on Android

A VPN client on Android normally creates a system VPN connection using Android’s VPN service interface. The client then decides which app traffic enters that connection. With split tunneling, some apps are sent into the tunnel while other apps use the device’s normal network route. The result is two paths on one phone: a VPN route and a direct route.

“Direct” means that the app does not use the VPN tunnel. It does not mean that the app becomes private, encrypted by the VPN, or hidden from the network it connects through. An app using the direct route still has whatever protection its own connection provides, such as HTTPS, but the VPN does not supply its exit location or tunnel encryption for that traffic.

Clients commonly present one of two modes. The labels vary, so read the explanation on the screen rather than relying only on a toggle name:

  • Only selected apps use the VPN: apps in the list are routed through the tunnel; other apps go direct. This is an allowlist for VPN traffic.
  • Selected apps bypass the VPN: apps in the list go direct; other apps use the tunnel. This is a bypass or exclusion list.

Those modes can look similar in a settings screen but have opposite outcomes. If you switch from one mode to the other without reviewing the list, an app you intended to protect may end up direct, or an app you meant to exclude may still use the VPN. Some clients also offer a global “direct” or “VPN” mode alongside per-app rules; confirm that the per-app feature is enabled and that the selected route is active.

Split tunneling is useful when an app needs the local network, behaves differently with a VPN exit, or should not use the same route as the rest of the device. It is less suitable when the requirement is that every connection from the phone must remain inside the VPN. In that case, a bypass rule creates an exception by design.

Key point: confirm whether the app list means “use VPN” or “bypass VPN” before saving; the same selection can produce opposite routing behavior in different clients.

Choose a routing policy before editing the app list

Start with the job you need the route to do. If only a small set of apps needs the VPN, an allowlist can make the intended path easy to inspect: select those apps, then verify that the rest remain direct. If nearly every app should use the VPN and only a few need direct access, a bypass list is often less work to maintain. Neither mode is universally better; the right choice depends on how many exceptions you expect and how carefully you need to control them.

Before changing anything, write down the apps that must use each route. Include background services if they matter. A messaging app, for example, may have a visible application and separate background activity; depending on the client and Android version, the app list may show only the package as one selectable item, or may present work-profile and personal-profile copies separately. Select the correct installed copy and check both profiles if you use a managed work profile.

Also decide what should happen when the VPN disconnects. Android and many clients provide options such as always-on VPN or blocking connections without a VPN. These are separate from the app-routing list. A lockdown or block-without-VPN setting can prevent direct traffic when the tunnel is unavailable, and may therefore conflict with the expectation that bypassed apps continue to connect normally. The precise interaction depends on Android’s version, profile settings and the client’s implementation. If you rely on a direct route, verify that the system’s always-on and lockdown settings match that requirement.

  • ✅ Use an allowlist when only a small, known group of apps should use the VPN.
  • ✅ Use a bypass list when most apps should use the VPN and only a few need direct access.
  • ✅ Check personal and work-profile copies separately when Android displays them as distinct apps.
  • ❌ Do not assume that “exclude,” “bypass,” and “only these apps” mean the same thing.
  • ❌ Do not enable a block-without-VPN option without testing what it does to apps assigned a direct route.

Choose the VPN client with this policy in mind. The Android platform offers the underlying VPN capability, but the per-app controls and their names are provided by the client. An official client or a compatible third-party client may expose different controls, and not every client supports the same split-tunnel behavior. If you import a subscription into a compatible app, importing the subscription and setting app-level routes are separate tasks: the subscription provides connection configuration, while the client’s routing screen decides which apps use it.

Configure the app list and test each route

Use this sequence to change the policy without replacing the VPN configuration. Menu labels differ between apps, but the order keeps the test focused and makes it easier to identify which setting caused a change.

  1. Connect the VPN and note the current state. Confirm that the client connects before editing split tunneling. If it does not connect at all, resolve that separate issue first; app selection cannot fix a failed tunnel.
  2. Open the per-app routing controls. Look for names such as split tunneling, app routing, per-app proxy, include apps or bypass apps. Read the client’s short description to determine which route the selected apps receive.
  3. Select a single test app. Avoid changing the whole list at once. Choose an app whose behavior you can observe, save the selection and reconnect if the client requests it.
  4. Check the VPN route. With the app assigned to the VPN, use a trustworthy IP-check page inside that app’s built-in browser if available, or compare the app’s connection behavior with the client connected and disconnected. A separate browser may have a different routing rule, so it is not a substitute for testing the target app.
  5. Check the direct route. Assign a second app to bypass the VPN, then confirm that its connection works while the tunnel remains active. Do not use a successful page load alone as proof of a specific exit route; use a route-checking method that actually runs in the app being tested.
  6. Test after reconnecting. Disconnect and reconnect the VPN, then repeat the checks. Some clients apply app rules only when the tunnel is established, and a rule that appears saved may not take effect until the connection is restarted.
  7. Record the final policy. Keep a short note of the mode and selected apps. This helps distinguish a routing change from a later client update, a profile change or an Android permission prompt.

When selecting an app, the list may include system components, duplicated app entries or packages with names that are not obvious. Do not exclude a system component merely because its label looks unfamiliar. If the client explains an entry, use that description; otherwise, begin with ordinary user-installed apps and leave system entries unchanged until you know what they do.

For example, if a work app needs the VPN but a local-network utility must connect directly, add only those two apps to the appropriate route and test them one at a time. A split-tunnel rule belongs to the client’s routing policy, not to the VPN subscription itself. That distinction is useful when comparing client options on VPNEH: first confirm that the Android client supports the routing behavior you need, then configure its app list.

Test on the network you actually use. Wi-Fi and mobile data can behave differently because of local DNS, captive portals, network restrictions or Android’s handling of background activity. If a route works on one network but not another, keep the app list unchanged while testing the network; changing both at once makes the cause harder to identify.

Troubleshoot common split-tunneling failures

An app still appears to use the VPN after being bypassed. First verify the mode. The app may be in an allowlist where selected apps use the VPN, rather than in a bypass list. If the mode is correct, save the change, reconnect the tunnel and test from within the target app. Check whether the app has a built-in proxy or secure connection setting that changes its own route. A browser’s private relay or proxy feature, for example, can affect what an IP check reports independently of the VPN client’s app list.

An app cannot connect after being excluded. Check whether Android is set to block connections without a VPN, whether the client has a lockdown option, and whether the app depends on a connection that the current network blocks. Temporarily turn off the relevant lockdown setting only if you understand the security trade-off, then test again. If the direct route works only when the VPN is disconnected, the issue may be an interaction between the client’s bypass handling and the system’s VPN policy rather than a damaged subscription.

The VPN connects, but an app has no network access. Confirm that the app is assigned to exactly the intended route and that the tunnel is active. If it is included in the VPN route, try a different server or connection profile only after confirming that other VPN-routed apps work. If it is assigned direct, check local network access and any app-specific proxy or DNS options. Changing the protocol or importing a fresh subscription before checking the route list can add variables without addressing the actual cause.

DNS results do not match the expected route. DNS handling can be separate from the visible per-app traffic rule. Android Private DNS, a browser’s secure DNS setting, a client-provided DNS mode and app-level name resolution can all affect what a test observes. Do not conclude that all traffic is direct or tunneled from a single DNS result. Compare the target app’s behavior, the client’s route indicators and a route check performed in that same app; then change one DNS setting at a time if the results remain inconsistent.

Rules stop working after an update or restart. Reopen the client and confirm that the selected policy remains saved. Check whether the app was updated, reinstalled, cloned, moved to a work profile or restored under a different package entry. Battery optimization can also delay a client’s background activity, although it does not automatically explain every routing failure. If the VPN disconnects when the screen turns off, review the client’s battery and background settings before changing the app routes.

Two VPN-style apps interfere with one another. Android generally allows one active VPN connection for a user or profile at a time. A security app, another VPN client or a local filtering tool may request the same system VPN slot. Disconnect the other service and test again. Do not run multiple VPN clients simultaneously expecting their app lists to combine; the active connection and its routing policy are controlled by the client that currently owns the VPN connection.

When troubleshooting, make the smallest reversible change first: confirm the routing mode, inspect the selected app, reconnect, and retest. If the problem persists, temporarily return only the affected app to the default route. This narrows the issue without removing the subscription, clearing all client data or resetting Android network settings.

Understand the privacy trade-off and maintain the rules

Each bypassed app is an intentional exception to the VPN route. Its traffic reaches the network through the device’s ordinary connection, so the local network and the app’s destination may observe the connection details that would otherwise be presented through the VPN route. That may be acceptable for a local printer or a service that requires a direct connection, but it is not equivalent to routing that app through the VPN.

An allowlist has a different maintenance cost: apps not explicitly selected may remain direct. If the goal is broad VPN coverage, review newly installed apps and cloned or work-profile copies after adding them. A bypass list may be easier when the VPN should cover most apps, but every exclusion needs a reason and should be revisited when the app’s behavior changes.

Keep the client and Android system updated, but treat changes to routing controls as a configuration change that needs a quick retest. An update may rename a menu, change how an app list is displayed or request VPN permission again. After accepting a new system prompt, confirm both a VPN-routed app and a direct-routed app rather than assuming the previous policy was carried over unchanged.

  • ✅ Keep a short record of whether the client uses an allowlist or a bypass list.
  • ✅ Recheck the route after changing VPN clients, Android profiles or network settings.
  • ✅ Test the app itself, not just another browser or a general connection indicator.
  • ❌ Do not treat a direct route as VPN-protected traffic.
  • ❌ Do not reset the whole VPN setup before checking the mode, profile and system lockdown settings.

Split tunneling is most reliable when the policy is small, explicit and tested. Decide which apps need each path, verify what the client’s selected-app list means, and then check both routes after reconnecting. If an app behaves unexpectedly, inspect the rule and Android’s VPN restrictions before changing the subscription or rebuilding the configuration.

Bottom line: assign apps by purpose, test each route inside the app that will use it, and revisit the policy whenever the client, profile or Android network settings change.