Android split tunneling lets you decide which apps use a VPN and which apps connect directly through the local network. That sounds simple, but the result depends on three separate layers: Android’s VPN service, the client’s per-app routing interface, and the way each application creates network connections. If those layers are not aligned, an app may appear in the direct list but still use the VPN, or it may lose connectivity after the VPN starts.

This Android split tunneling guide explains the complete process in 2026. You will learn how to choose between “VPN only” and “direct only” app lists, import a subscription into a compatible client, build a small test group, verify the routing result, and troubleshoot apps that ignore your rules. The goal is not to make every application follow one global setting. It is to create a predictable policy that matches how you actually use your phone.

Understand how Android split tunneling works

Android VPN clients normally use the Android VpnService interface to create a local VPN tunnel. The client then captures traffic from selected applications and forwards it through the configured protocol and route. Depending on the client, the interface may be labeled per-app proxy, app routing, split tunneling, include apps, or exclude apps. These labels describe related ideas, but they do not always use the same selection logic.

There are two common models. In an allow-list model, only the apps you select use the VPN and all other apps remain direct. In a deny-list model, most apps use the VPN and the apps you select are excluded from it. The same app list can therefore produce the opposite result when you switch clients. Before changing anything, read the label beside the list and check whether it says “VPN apps,” “bypass apps,” “excluded apps,” or something similar.

5

Common protocol families

5

Routing layers to check

100+

Countries available

250+

Routes available

The protocol is another important layer. A subscription may provide profiles based on Shadowsocks, VMess, Trojan, Hysteria2, WireGuard, or another supported format. The Android client must support the profile type, and the imported profile must contain a valid server, port, authentication method, and transport configuration. Split tunneling can only control traffic after the client has successfully loaded and activated a compatible profile.

Finally, remember that “an app uses the VPN” does not necessarily mean every connection created by that app follows the same path. Some applications use their own proxy, a separate secure tunnel, a content delivery system, or a browser engine with independent behavior. Android work profiles and managed devices can also have different application identities and network policies. These exceptions are why verification matters more than the name of the toggle.

Key principle:

Always identify whether the client uses an include list or an exclude list before adding applications. A correct app name in the wrong list can create a completely opposite routing result.

Prepare the client and define an app policy

Start with a simple policy instead of trying to classify every installed application. Write down the apps that genuinely need a remote route, the apps that should remain local, and the apps that are uncertain. This prevents a long list from hiding one incorrect selection. A practical first test usually includes one browser, one messaging app, and one local service rather than the entire app library.

If you use the official Android client, sign in to the user panel and obtain the available configuration or subscription information. If you use Clash-compatible software, sing-box, or another compatible Android client, confirm that the client can import the provided format before attempting to configure per-app routing. A subscription link is a configuration credential, so keep it private and do not paste it into public screenshots, shared notes, or support forums.

NrVPN supports Windows, macOS, iOS, Android, and Linux. Its published network includes 100+ countries and 250+ routes, but the presence of a country in a service list does not mean every route is suitable for every application. Select a route based on the destination and test the actual app. Streaming, account login, real-time calls, and ordinary web browsing may react differently to the same route.

Android can display a VPN connection request the first time a client starts the tunnel. Approve it only for the client you intend to use. If another VPN, firewall, DNS filter, or security application is already active, disable it temporarily while testing. Android generally permits only one active VPN service at a time, and multiple network-control tools can make the symptom look like a split-tunneling failure.

Battery optimization can also interfere with long-running VPN connections. The exact menu differs by Android version and manufacturer, but look for the client under battery settings and avoid aggressive background restrictions during diagnosis. This does not fix an incorrect route policy, but it helps distinguish a routing problem from a client process that Android has stopped in the background.

Choose VPN apps or direct apps

Use a VPN app list when only a few applications need the remote route. This is usually easier to audit: the browser or selected work app goes through the tunnel, while everything else stays direct. Use a direct or bypass list when most of your applications need the VPN and only a small number must reach local resources without it.

Do not place the same app in both lists if the client allows that configuration. Some clients reject the conflict, while others apply an order that is not obvious from the interface. Remove old entries before switching between modes. If an app has both a regular version and a clone, dual-app copy, or work-profile copy, add the correct instance separately.

Usage pattern Recommended policy What to verify
Only a browser or research app needs the route VPN-only allow list Other apps still use the local connection
Most apps need the route, but local banking or office tools do not Direct-app exclude list The excluded apps can reach local services
Work and personal apps have different requirements Separate package entries where supported Personal and work profiles are not being treated as one app
The client has unclear list labels Test one app in each mode Compare the result with an external IP or route check

Configure Android split tunneling step by step

The names of menus vary between the official client, Clash-based clients, sing-box front ends, and Android manufacturers. The sequence below is therefore more useful than memorizing one interface. Complete each stage and confirm its result before moving to the next one.

  1. Import the profile. Open the client’s profile, subscription, or configuration section. Add the subscription link or import the configuration file using the method supported by the client. Wait until the profile is parsed successfully; an imported item that cannot be selected is not ready for routing.
  2. Select a route. Choose a server or policy group appropriate for the destination you want to test. If the client offers automatic selection, record the selected group so that a later route change does not get confused with an app-list change.
  3. Open per-app settings. Look for app routing, split tunneling, application proxy, or bypass settings. Read the mode description carefully. Some clients place “include apps” and “exclude apps” behind a separate switch.
  4. Choose one test application. Add a browser or another application that can clearly show a network result. Avoid starting with a background-only service because it may not create a visible connection immediately.
  5. Save and activate. Apply the policy, start the VPN, and accept Android’s VPN permission prompt if it appears. Wait for the VPN indicator before opening the test app.
  6. Generate a fresh request. Fully close and reopen the test app, or use its own refresh control. Existing sessions may continue using an established connection and can make a new policy appear ineffective.
  7. Test a direct app. Open an app that is intentionally outside the VPN list, such as a local service. Compare its behavior with the VPN-selected app rather than judging the whole phone from one result.
  8. Record the result. Note the app, selected route, list mode, and whether the request succeeded. Small records are valuable when troubleshooting a later update or profile change.

When using a compatible third-party client, do not assume that a subscription import automatically creates the same app policy as the official client. The subscription generally supplies route and protocol data; per-app behavior is often controlled locally by the Android client. You may need to choose a tunnel mode, configure an application list, and then select a rule set or outbound group.

For advanced configurations, separate application selection from domain rules. An app list answers “which application enters the VPN service?” A rule set answers “which destination or domain uses which outbound route?” Mixing these concepts can lead to a policy where the app enters the tunnel but a domain rule sends part of its traffic direct. That may be intentional, but it should be documented so the result is not mistaken for random behavior.

Verify both VPN and direct connections

A VPN icon in the Android status bar confirms that a VPN service is active, but it does not prove that every app is using it. Verification should test the selected application, the excluded application, and the actual destination. Use a reputable IP-check page or the destination application’s own connection diagnostics. Compare the public IP, approximate region, DNS result where the tool exposes it, and the ability to complete the intended task.

For a VPN-selected browser, open a fresh private tab and check the public IP. Then close the browser, temporarily remove it from the VPN list, reconnect the tunnel, and test again. A change in the observed exit IP is stronger evidence than simply seeing the VPN icon. For an excluded app, test a function that requires a new network request. A cached page or an already authenticated session may not reveal the current path.

DNS deserves separate attention. An app can appear to connect through the VPN while using a DNS path that does not match your intended policy, or it can fail because the selected DNS mode cannot resolve a required domain. Do not treat a DNS leak checker as a complete routing test, however. It cannot prove how every application handles its own DNS, encrypted DNS, or embedded browser traffic.

Also test IPv4 and IPv6 behavior when the client exposes separate controls. If one address family is tunneled and the other is not, an application may select the path that does not match your expectation. The correct setting depends on the client and network. Avoid making broad changes until you know whether the failure is limited to IPv6, DNS, or the application itself.

Verification standard:

A split-tunneling policy is working only when the selected app and the direct app both produce the expected result under a fresh connection. The VPN icon alone is not enough.

Troubleshoot ignored rules and lost connectivity

If an app ignores the split-tunneling rule, first check the list direction. “Exclude selected apps” and “VPN selected apps” can look similar in a compact mobile interface. Remove the app, save the settings, add it again in the intended mode, and reconnect the VPN. Then check whether you selected the correct package, especially if the phone has a cloned app, work profile, beta build, or manufacturer-specific application variant.

Next, inspect whether the client is operating in a mode that supports per-app control. Some clients offer several tunnel modes, and a global system VPN mode may not use the same application list as a rule-based mode. A Clash-compatible client may also separate the Android VPN stack from the rule engine. If the app list is visible but has no effect, read the client’s mode description and confirm that the tunnel is actually started by that client.

Apps can also use connections that are difficult for a basic rule to classify. An embedded browser, background service, push component, or separately packaged login module may not share the same package identity as the screen you are using. Some applications use certificate pinning or their own network stack, so changing DNS or a proxy rule will not necessarily change their behavior. In such cases, test the application’s main package and any companion component only if the client exposes it clearly; avoid adding random system packages.

If an app loses connectivity after being excluded, check local network assumptions first. It may require a route reachable only through the VPN, a DNS resolver available only through the tunnel, or an IPv6 path that the local network does not provide. Re-enable the app for the VPN and test again. If it works only through the VPN, the split rule may be correct and the direct network may simply be unable to reach that destination.

When all apps lose connectivity, the issue is probably not per-app selection alone. Refresh the subscription, verify that the profile has not expired or been malformed, and test another route. Check the device clock, captive portal, Wi-Fi sign-in page, mobile data state, and battery restrictions. If the profile uses Shadowsocks, VMess, Trojan, Hysteria2, or WireGuard, confirm that the selected Android client supports that protocol and its required transport options. A protocol mismatch can look like a routing error because the tunnel never becomes usable.

Always-on VPN and “block connections without VPN” settings deserve special attention. These Android controls can override the practical behavior of a direct-app policy. If direct applications stop working, temporarily review those settings and determine whether the client is expected to allow bypass traffic. On managed work devices, an administrator may also prevent bypassing the VPN or restrict which profiles can access the network.

Reset safely and retest

When configuration has become difficult to explain, return to a minimal state. Stop the VPN, remove duplicate profiles, disable other VPN or filtering applications, and keep one route with one test app. Reconnect and verify it. Add a second app only after the first result is clear. This staged approach is faster than repeatedly changing a long application list.

Keep a short record of the client version, Android version, profile name, list mode, selected route, and test result. Do not include the private subscription link in that record. If support is needed, provide screenshots with credentials and links hidden. Clear records help identify whether the issue is reproducible on one app, one network, one profile, or the entire device.

Build a policy that remains reliable

The best Android split-tunneling setup is usually conservative. Put only clearly justified apps into the VPN list, keep local utilities direct when they need local discovery, and avoid routing every system component without a specific reason. A smaller policy is easier to verify after a client update, Android upgrade, route replacement, or subscription refresh.

Review the policy whenever you install a cloned app, move an app into a work profile, change from Wi-Fi to mobile data, or switch between the official client and a compatible client such as Clash Verge-related Android software or a sing-box front end. The same subscription may import successfully in multiple clients, but each client can interpret application routing and rule precedence differently.

For everyday use, separate three questions: does the tunnel connect, does the selected app use the tunnel, and can the destination complete its task? If the first answer is no, investigate the profile, protocol, route, or network. If the first is yes but the second is no, investigate app-list mode and package selection. If the first two are yes but the task fails, investigate DNS, IPv4 or IPv6 behavior, destination restrictions, and the application’s own network stack.

Pricing and traffic planning are separate from split tunneling, but the routing policy can affect total usage because different apps generate very different amounts of traffic. NrVPN’s monthly options are ¥9.9/month with 60GB, ¥18/month with 250GB, and ¥28/month with 500GB; monthly traffic resets on the activation date. Traffic packages are ¥158/300GB, ¥358/1000GB, and ¥658/3000GB, used until depleted and permanently valid. The account supports unlimited device count, so app policy is useful for deciding which device traffic should enter the tunnel, not for bypassing the total traffic rules.

In short, begin with one app, identify the list direction, activate one compatible profile, and verify a fresh connection from both a VPN-selected app and a direct app. Once that baseline is reliable, expand the policy gradually. This method makes Android per-app routing easier to understand, easier to maintain, and much less likely to fail silently after the next configuration change.