Android VPN split tunneling lets you decide which apps use the encrypted VPN connection and which apps continue through the normal network. This is useful when only a browser, streaming app, messaging tool, or work application needs a different network exit, while local services, banking apps, smart-home devices, or games should keep their direct route. The important point is that split tunneling is an app-routing policy, not a faster protocol or a guarantee that every application will follow the same path.

Android clients implement this feature through the system VPN framework, usually with an allow list or a bypass list. An allow list sends only selected apps through the VPN. A bypass list sends most apps through the VPN but excludes the apps you specify. The exact names vary between official Android clients and compatible clients such as sing-box-based applications, so always confirm which list type is active before testing. This guide explains how to choose the right mode, create app rules, verify the result, and resolve conflicts caused by battery optimization, Android settings, or another VPN profile.

What Split Tunneling Means on Android

Without split tunneling, an Android VPN usually attempts to capture traffic from the device and send it through the selected VPN route. Depending on the client, this may be implemented as a system proxy, a VPNService-based tunnel, or a TUN interface. A system proxy does not necessarily cover every application, because many Android apps ignore system proxy settings. A VPNService or TUN-based client can usually provide broader coverage, but it still depends on the client’s application rules, DNS handling, IPv6 behavior, and the way each app opens its connections.

With split tunneling enabled, the client checks the originating application before forwarding traffic. If the app matches the VPN list, its request enters the tunnel and leaves through the selected node. If it matches a bypass rule, the request uses the local Wi-Fi or mobile network instead. A simplified flow looks like this:

Android app
→ Android VPNService or TUN interface
→ Application rule check
→ VPN tunnel or direct network
→ DNS and destination connection
→ Response returns to the same app

There are two common policy models:

  • VPN only selected apps: The apps on the list use the VPN, while other apps are intended to connect directly. This is usually the clearest option when only a few applications require a different route.
  • VPN all apps except selected apps: Most applications use the VPN, and the apps on the exclusion list connect directly. This can be convenient for local services, but one forgotten app may still send traffic through the tunnel.
  • Rule-based routing inside a compatible client: The client may combine app names, domain rules, IP rules, protocol rules, and geographic lists. This provides more control, but it also creates more opportunities for DNS or rule-order mistakes.

These modes should not be confused with choosing a different protocol. Shadowsocks, VMess, Trojan, Hysteria2, WireGuard, and similar technologies describe how traffic is carried between the device and the remote endpoint. Split tunneling describes which traffic is handed to that connection. Changing from one protocol to another may help a handshake or transport problem, but it does not automatically create app-based routing.

5

Android checks to verify

2

Main app-list policies

90+

Available countries

200+

Available routes

Choose the Right App Policy Before Editing Rules

The most reliable configuration begins with a small, specific requirement. Write down the apps that need the VPN and the apps that must remain direct. For example, you may want a browser and an international collaboration app to use the tunnel, while a local payment app and a nearby printer remain outside it. This is easier to maintain than starting with a broad exclusion list and trying to remember every application that should bypass the VPN.

Allow List or Bypass List?

Choose an allow list when the VPN is needed by only a few apps. It reduces the chance that background updates, local discovery traffic, or unrelated accounts unexpectedly use the remote exit. It also makes verification easier because you can compare one selected app with one unselected app on the same device.

Choose a bypass list when most of the device should use the VPN and only a small number of apps must stay direct. Common examples include a local banking application, a home automation app, or a game that depends on a nearby regional server. Before selecting this mode, check whether the client labels the feature as “exclude apps,” “bypass selected apps,” or “apps not using VPN.” Similar wording can describe the opposite behavior in another client.

  • ✅ Use an allow list when only a few apps need the remote route.
  • ✅ Keep local discovery, payment, or device-control apps direct only when their behavior requires it.
  • ✅ Record the selected policy before adding individual applications.
  • ❌ Do not assume an app is direct merely because its icon is not visible in the VPN client.
  • ❌ Do not mix an Android VPN profile with another active VPN application.

Android work profiles deserve special attention. A personal version and a work-profile version of the same application may appear as separate app entries. If the client lists both, add the correct profile explicitly. An enterprise management policy can also force a work profile through a particular network path or prevent users from changing VPN behavior. In that situation, the client’s app list may not override the administrator’s policy.

Key decision: Start with the smallest group of apps that needs the VPN. Expanding an allow list is usually easier to diagnose than shrinking a broad bypass list after unexpected traffic has already been routed.

Set Up Android Split Tunneling Step by Step

The following workflow applies to many official Android clients and compatible clients that support app-based VPN rules. Button names may differ, but the order is useful because it separates account, node, permission, and routing problems. If you use a subscription link, import it first and confirm that the client can display the available profiles. A subscription is a configuration source; it is not itself proof that the Android VPN tunnel is active.

  1. Install a compatible client. Use the official Android client when available. If you use a compatible client, confirm that it supports the protocol and subscription format provided by the service. A client may import a profile successfully while still lacking support for a specific routing feature.
  2. Import or update the subscription. Sign in or paste the subscription link according to the client’s instructions. Treat the link as sensitive account information. Do not post it in a screenshot or send it through an open group.
  3. Select a node and test a basic connection. Connect with the default global or full-device mode first. This establishes whether the account, subscription, node, and protocol work before app rules are introduced.
  4. Open the routing settings. Look for “Split tunneling,” “App routing,” “Per-app VPN,” “Application proxy,” or a similar entry. Some clients place it under VPN settings, while others put it inside a profile editor.
  5. Choose the policy direction. Select VPN-only-for-chosen-apps or VPN-for-all-except-chosen-apps. Read the explanatory text carefully instead of relying on the position of a switch.
  6. Add the applications. Search by the package or application name and check the intended personal or work-profile entry. Add one or two apps first rather than changing the entire list at once.
  7. Save and reconnect. Android may ask to create or approve a VPN connection. Accept the system prompt, disconnect the old session if necessary, and reconnect after saving the rules. Some clients do not apply a changed app list until the tunnel is restarted.
  8. Test selected and unselected apps separately. Open one app that should use the VPN and one app that should remain direct. Test both foreground behavior and the specific function you care about, such as login, file transfer, or local device discovery.

When using a compatible client, distinguish between application rules and domain rules. An app rule may send all connections created by that application through the VPN, while a domain rule may affect a domain regardless of which app requests it. Rule order also matters: a broad direct rule placed above a narrower VPN rule may prevent the intended match. If the client supports rule previews or connection logs, use them to identify which rule handled a request.

TUN, System VPN, and Application Coverage

Android VPNService is not identical to a browser proxy. It can capture traffic at a broader system level, but the client must still correctly handle UDP, TCP, DNS, IPv6, and app-specific connection methods. Some applications use their own encrypted transport, certificate pinning, or separate connectivity checks. They may work differently from a normal browser even when the app appears on the VPN list.

For everyday use, choose the client mode that clearly explains its coverage. If a TUN mode is required for application routing, enable it only after confirming that the client supports the Android version and protocol you use. If the client offers both system proxy mode and VPN mode, the system VPN mode is generally the relevant choice for per-app routing. However, greater coverage can also increase the chance of conflicts with private DNS, always-on VPN, firewall applications, and battery restrictions.

Verify VPN and Direct Traffic Correctly

A successful connection indicator only proves that the client has established some form of tunnel. It does not prove that every selected app is using it, that every excluded app is direct, or that DNS requests follow the same policy. Verification should therefore compare an app that belongs to the VPN list with an app that does not.

First, check the public exit from the selected app. A browser opened through the VPN can use the site’s IP Check page to confirm the visible country and network exit. Then close the browser or disconnect it from the VPN list and repeat the check through a direct configuration if the app supports that test. Do not compare results taken at different times without noting whether the node changed.

Next, test the actual application function. A page opening does not prove that uploads, notifications, background refresh, WebSocket connections, or media playback use the intended route. For a work app, test sign-in and a small file operation. For a game, test the login region and matchmaking behavior without claiming that a particular route will always improve latency. For a local device app, check whether it can discover devices on the same Wi-Fi network after the VPN is enabled.

  • Selected app: Confirm the visible exit and verify the feature that needs the VPN.
  • Unselected app: Confirm that local access or direct connectivity still works.
  • DNS behavior: Check whether the client sends DNS through the tunnel, keeps it direct, or applies a separate DNS policy.
  • IPv6 behavior: If the client does not handle IPv6 consistently, an app may reveal a different path even when IPv4 appears correct.
  • Background behavior: Lock the phone briefly and reopen the app to see whether Android stopped the VPN service or the app’s network process.
Verification rule: Test the route from inside the same app that matters, then compare it with a deliberately unselected app. A client status badge alone is not enough evidence.

Fix Battery, VPN, and Routing Conflicts

Many split-tunneling problems are not caused by the app list itself. Android may suspend the client in the background, another security application may request a VPN connection, or a system policy may override the client’s routing choice. Troubleshoot in a fixed order and keep a note of each change.

Battery optimization and background suspension

Battery optimization can pause the VPN service when the screen is off or when the client has been idle. The visible symptom may be an app that works immediately after connecting but fails after the phone sleeps. Open Android’s battery settings for the VPN client and review background activity, unrestricted battery use, auto-start, and background data options where available. The menu names differ by device manufacturer, so look for the client’s battery and background permissions rather than following a single universal path.

Do not disable every battery restriction without a reason. Start by allowing the VPN client to maintain its service, then test again after locking the device. If only one application stops working, check that application’s own background and data-saving restrictions as well. A VPN client can remain active while Android pauses the target application.

Always-on VPN and block-without-VPN settings

Android can provide always-on VPN and a “block connections without VPN” option. These settings can be useful for an all-device privacy policy, but they may conflict with split tunneling. If an app is intentionally excluded from the VPN, a block-without-VPN policy may prevent that direct connection rather than allowing it. During diagnosis, review Android’s system VPN settings and temporarily disable a restrictive block policy only if your security requirements allow it.

Also check for another active VPN request from an ad blocker, firewall, enterprise profile, or security product. Android normally gives control to one VPNService at a time. Two applications cannot independently control the same device VPN path, even if both display a connected-looking status. Close or disable the competing profile, then reconnect the intended client.

Private DNS, local access, and overlapping rules

Private DNS is separate from the VPN app list. Depending on the client and Android version, DNS may be handled by the VPN, by Android’s Private DNS setting, or by a resolver configured inside the client. If a selected app reaches the expected exit but fails to resolve certain domains, inspect DNS mode before changing the node. If a local app cannot find a printer, television, or home server, check whether the client has an “allow LAN,” “bypass local network,” or similar setting.

Rule overlap is another common cause. A client may have an application rule, a domain rule, a country rule, and a final catch-all rule. The first matching rule may decide the path. Remove temporary experiments, place narrow rules before broad rules when the client requires ordered matching, and use connection logs to confirm the selected action. After editing rules, reconnect rather than assuming that existing sessions will be reclassified.

  • ✅ Exclude competing VPN, firewall, or ad-blocking VPN profiles during testing.
  • ✅ Review Android always-on and block-without-VPN settings.
  • ✅ Allow the VPN client to run in the background when sleep causes disconnections.
  • ✅ Check Private DNS and local-network access separately from app rules.
  • ❌ Do not delete the subscription immediately when one app fails; first test the default full-device mode.
  • ❌ Do not run multiple VPN clients at the same time and compare their status icons.

Build a Maintainable Android Routing Plan

App-based routing is easiest to maintain when the list reflects a stable purpose. Name or document the policy outside the client if the application does not provide notes. Record which apps are intended to use the VPN, which are direct, whether local network access is enabled, and whether DNS is handled by the client or Android. This makes future troubleshooting much faster after an Android update, a client update, or a subscription refresh.

Review the list after installing a new app or adding a work-profile application. Updates can change package behavior, but the more common issue is that the user tests the wrong app entry. Some media apps also delegate login or playback to a browser, system web component, or separate authentication service. If only part of the workflow follows the VPN, identify every app involved instead of adding random applications until the symptom disappears.

Use the default full-device mode as a diagnostic baseline. If an app works there but fails under split tunneling, the likely causes are an incorrect policy direction, a missing app entry, DNS handling, local-network restrictions, or a rule-order issue. If it fails in both modes, investigate the subscription, node, protocol compatibility, account access, or the app’s own network restrictions instead. This distinction prevents unnecessary changes to a working route.

VncVPN supports Windows, macOS, iOS, Android, and Linux, with subscription-based configuration available for compatible clients. Its service information lists 90+ countries and 200+ routes, while simultaneous online device count is unlimited. Those service capabilities do not remove the need to configure Android app rules carefully: the final path still depends on the client, Android permissions, the selected route, and the destination application.