Android Split Tunneling Guide: Set VPN Rules by App

Android split tunneling lets you decide which apps use a VPN tunnel and which apps continue through the ordinary network connection. Instead of applying one routing policy to the entire phone, you can send a browser, streaming app, work tool, or messaging client through a selected exit while leaving banking, local services, or high-bandwidth downloads outside the tunnel. This can reduce unnecessary traffic through the proxy, preserve access to local devices, and make troubleshooting more precise.

The important point is that split tunneling is an app-routing feature, not simply a faster connection mode. The client normally creates an Android VPN service and then builds an allowlist or blocklist for applications. Depending on the client, the setting may be called Per-app VPN, App routing, Include apps, Exclude apps, Bypass VPN, or Split tunneling. The wording differs, but the decision is the same: identify the apps that should enter the tunnel, then verify the apps that should remain direct.

What Android split tunneling controls

A normal Android VPN connection can capture traffic from many applications through the Android VpnService framework. A compatible client can associate installed application packages with the virtual interface and apply a per-app policy. In practical terms, the client decides whether traffic created by a particular app is routed into the tunnel or sent through the phone’s ordinary network path.

There are two common policy models:

• Include selected apps: Only the apps listed in the rule use the tunnel. Everything else remains direct.
• Exclude selected apps: Most apps use the tunnel, while the apps listed in the bypass rule remain direct.

These policies are not always interchangeable. An include list is usually easier to audit because the tunnel scope is deliberately small. An exclude list is convenient when you want broad coverage but need to protect a few local or region-sensitive apps from being routed through the VPN. Some clients expose both modes, while others expose only one. If the client does not clearly show which mode is active, do not assume that selecting an app means the app will be tunneled; in some interfaces, selecting an app means it will be excluded.

Split tunneling also does not automatically rewrite every connection made by an app. An application may call a separate helper process, use an embedded browser, open a system custom tab, or rely on another app for authentication. Android may therefore display several related packages, and routing only the visible app may not cover the complete workflow. Push notifications, background synchronization, media playback, and login redirects can follow different connection paths from the main screen.

The tunnel itself may use different protocol families, including Shadowsocks, VMess, Trojan, VLESS, Hysteria2, or WireGuard, depending on the service and client. Split tunneling decides the traffic scope; it does not make one protocol universally better. A UDP-oriented application, a browser using HTTP/3, and an app that uses ordinary TCP may behave differently even when they are assigned to the same route.

Choose an app-routing strategy before changing settings

Start with the destination and function that actually require the tunnel. For example, a region-specific streaming app may need a matching exit location, while a local smart-home controller may need direct access to devices on the home network. A work application may require an organization-managed VPN rather than a consumer subscription. Writing down these requirements first prevents a common mistake: enabling a broad tunnel and then excluding apps randomly whenever something fails.

When to use an include list

An include list is a good starting point when only selected apps need an alternate route. It reduces the amount of traffic entering the tunnel and makes the expected behavior easy to describe: the listed apps use the VPN, and unlisted apps do not. This arrangement is useful for testing a new subscription, accessing one service, or keeping most local and domestic traffic on the direct connection.

Include lists are also easier to troubleshoot. If a selected app cannot connect, you can inspect the node, protocol, DNS behavior, and app permissions without changing the route for every other application. However, remember to include companion apps when the target workflow depends on them. A streaming app may use an account component, a browser, or a download service outside the main package. Add only the packages you understand, and expand the list after observing the actual connection behavior.

When to use an exclude list

An exclude list is more suitable when most applications should use the tunnel but a small number must stay direct. Typical reasons include local network administration, services that reject the selected exit location, or applications that need to discover devices on the same Wi-Fi network. Excluding an app does not necessarily make all of its related traffic direct if another component is still assigned to the tunnel.

Broad tunnel policies can also expose hidden dependencies. A notification service, authentication provider, or application update component may be routed differently from the foreground app. If the app opens but sign-in, images, or notifications fail, examine the complete flow rather than adding unrelated packages one at a time. A bypass list should be a deliberate policy, not a collection of guesses.

• ✅ Use an include list when only a few apps require the alternate route.
• ✅ Use an exclude list when most apps need the tunnel and only a few must remain direct.
• ✅ Record the selected mode before changing individual app switches.
• ❌ Do not assume a checked app is tunneled without reading the client’s label.
• ❌ Do not run two VPN-style clients at the same time while testing routing.

Configure Android app rules step by step

The exact labels depend on the Android version and the client. The following process applies broadly to official Android clients and compatible clients that support subscription import and per-app routing. If you are using a client such as a sing-box-based application, follow its own naming for profiles, routes, and package lists. A client that can import a subscription is not automatically capable of per-app split tunneling.

1. Import and activate the configuration. Add the subscription URL through the client’s subscription manager or import the configuration file supplied by the service. Confirm that the profile contains usable nodes and that the selected protocol is supported by the client. Do not paste a private subscription URL into a public browser, screenshot, or chat message.
2. Open the routing section. Look for an item named App routing, Per-app proxy, Split tunneling, or a similar term. It may be located inside the active profile rather than in the global settings.
3. Select the policy mode. Choose whether the list represents apps that use the VPN or apps that bypass it. Read the explanatory text carefully; the same checkbox design can mean opposite actions in different clients.
4. Search for installed packages. Use the search field if the list is long. Select the actual package used by the target app. If the client displays duplicate names, compare the package information or test them separately instead of enabling every similarly named item.
5. Save the profile. Some clients apply changes immediately, while others require saving, selecting the profile again, or restarting the connection. Keep a note of the original list so you can restore it without relying on memory.
6. Reconnect the Android VPN. Disconnect and connect again after changing app rules. Android may keep existing sockets open, so a foreground app can appear unchanged until its connection is recreated.
7. Test both sides of the rule. Open a selected app and an app that should remain direct. Check the client’s connection log, the visible exit region where relevant, and whether ordinary local functions still work.

Example policy description:
Mode: Include selected apps
Tunnel apps: Browser, streaming client
Direct apps: Banking app, local device controller
Verification: Reconnect, test foreground traffic, inspect logs

The example is a planning format rather than a universal configuration syntax. Do not paste it into a client unless that client explicitly accepts the same fields. Some applications use YAML or JSON profiles, while others provide only graphical switches. Editing a generated profile by hand can also be risky: a syntactically valid file may still use package names or route keys that the current core ignores.

If you need a general import and connection walkthrough, see the setup guide. Keep the routing decision separate from subscription maintenance: first confirm that the profile connects in a broad or simple mode, then add app-specific rules. This separation makes it clear whether a failure comes from the node, the protocol, the subscription format, or the split-tunnel policy.

Test tunneled and direct traffic correctly

A connection icon only proves that the client has established some form of tunnel. It does not prove that every selected app is using it, and it does not prove that excluded apps are bypassing it. Test one behavior at a time. Begin with the app that should use the tunnel, then close or force-stop it if appropriate, reconnect the client, and repeat the same action after changing the rule.

For a tunneled app, inspect the client log while the app loads a page, signs in, or requests content. The log may show the process, destination domain, selected node, or route decision. If the client has a traffic panel, use it to confirm that traffic is being generated by the expected package. A browser test alone is not enough because the browser may resolve a domain, open a system component, and fetch content through several different connections.

For a direct app, test a function that does not depend on cached content. A local device controller should rediscover a device, and a direct service should create a new request rather than displaying previously loaded data. Clear only the app cache or restart the app when necessary, but avoid changing several network settings at once. Otherwise, you will not know which change fixed the problem.

DNS deserves special attention. An app can be routed through the tunnel while name resolution follows a different path, or a direct app can resolve a hostname using a DNS service associated with the VPN. This may cause region checks, local-domain failures, or inconsistent results between apps. If the client offers separate DNS routing, read its description before enabling it globally. Do not conclude that an IP address test proves the entire app session uses the same route.

Troubleshoot and restore rules

When a rule causes trouble, first return to a simple baseline. Disable split tunneling temporarily or remove the newly added app from the list, save the profile, and reconnect. If the app works again, the routing policy is a strong suspect. If it still fails, investigate the node, protocol support, Android permission state, network restrictions, or the application itself.

Android allows only one active VPN service in the usual consumer setup. A second VPN client, security application, ad blocker, or work-profile VPN can compete for the same service slot or alter DNS and routing behavior. Close other VPN-style tools before testing. If a managed work profile is present, its administrator may enforce a policy that a personal client cannot override.

Battery optimization can affect long-running background behavior. A client that is paused by the system may appear to have a correct app list but stop forwarding traffic when the phone sleeps. Review the client’s Android battery and background permission guidance, especially if the issue affects notifications or synchronization rather than foreground browsing. Do not grant unrelated permissions merely to make a rule work; grant only what the client explains.

If the client offers Block connections without VPN or an always-on option, treat it as a separate safety policy. It can prevent direct fallback when the tunnel disconnects, but it may also make excluded apps unable to connect if the client does not implement bypass behavior correctly. Test the combination deliberately. A split-tunnel list and a kill-switch-style setting should not be enabled together without confirming how the client defines bypass traffic.

Restore rules in a controlled order:

• ✅ Disconnect the client before deleting or replacing a profile.
• ✅ Restore the last known working app list rather than rebuilding it from memory.
• ✅ Reconnect after each meaningful policy change.
• ✅ Check logs for the target package and destination during a fresh request.
• ❌ Do not change protocol, node, DNS, app rules, and Android permissions simultaneously.

When a subscription updates, it may replace or merge profile fields depending on the client. Check whether the app-routing list belongs to the local profile or is delivered by the remote subscription. If an update repeatedly removes local rules, duplicate the profile if the client supports that workflow, or record the desired policy before refreshing. Never assume that a successful subscription update preserves manually edited routing settings.

Privacy, performance, and maintenance considerations

Split tunneling changes traffic scope, not the trust relationship with the selected route. Apps inside the tunnel send traffic through the configured proxy or VPN service, while direct apps use the network path supplied by the carrier or Wi-Fi provider. This distinction matters when comparing privacy expectations, region behavior, and troubleshooting results. If an app handles sensitive information, read the service terms and client permissions before assigning it to any third-party route.

It can also improve usability by preventing unrelated traffic from consuming tunnel bandwidth or by keeping local services reachable. However, it is not a guarantee of lower latency or better battery life. An app may open many connections, use background traffic, or communicate with endpoints in several regions. A narrower rule set can make the behavior easier to understand, but the best result still depends on the route, protocol, network conditions, and application design.

Review the list after installing, uninstalling, or replacing apps. Android package identifiers can change between editions, work profiles, and vendor versions. An old entry may remain in a client even after the app is removed, while a newly installed app may be direct by default. Keep names and package identifiers private when sharing diagnostics, because they can reveal which services are installed on the device.

The most reliable Android split-tunneling setup is intentionally narrow and observable. Decide which apps need the tunnel, choose include or exclude mode based on that scope, reconnect after applying the rule, and verify both tunneled and direct traffic. If something breaks, return to the baseline first, then reintroduce one rule at a time. This method works across official Android clients and compatible proxy clients while leaving room for differences in protocol support, DNS handling, and Android permission behavior.