Android Split Tunneling Guide: Route Apps With Custom Rules

Android split tunneling lets you decide which apps use the VPN and which apps keep a direct connection. This is useful when a browser, work tool, or streaming app needs a different route while local services, banking apps, printers, or battery-sensitive background tasks should remain outside the tunnel. The important point is that split tunneling is an app-routing policy, not a faster protocol by itself. The final result depends on the Android VPN permission, the client’s routing engine, DNS behavior, the selected mode, and whether the application sends traffic through Android’s VPN interface.

A reliable setup therefore starts with a clear traffic plan. Decide which apps must use the VPN, which apps must bypass it, and what should happen when the VPN is disconnected. Then configure the rule mode, reconnect the tunnel, verify the result with both an IP check and an application test, and keep a recovery path if an app stops working. Menu names differ between provider-specific Android clients and general-purpose clients, but the underlying ideas are similar.

Understand what Android split tunneling actually changes

When an Android VPN client connects, Android creates a VPN interface and allows the client to request traffic routes. In a full-tunnel configuration, most or all application traffic is sent through that interface. In a split-tunnel configuration, the client adds rules that either include selected apps in the tunnel or exclude selected apps from it. The client may implement this with Android’s per-application VPN capability, route tables, package-name matching, or a combination of these mechanisms.

There are usually two main modes. Allow-list mode, sometimes called “VPN only for selected apps,” sends only the apps you choose through the VPN. Every other app uses the direct connection. This mode is easy to reason about when only a small number of applications need the tunnel. Exclude-list mode, sometimes called “bypass selected apps,” sends traffic through the VPN by default and leaves the selected apps outside. This is more convenient when most of the device should use the VPN but a few local or region-dependent apps should not.

The word “app” can also be misleading. Some Android services are separate packages, while a visible application may use browser components, background services, or a WebView. If an app appears partly connected and partly disconnected, its main package may not be the only component involved. A social app, for example, might load content through a built-in browser component; a work application might depend on a separate authentication service. The client can only match the packages and traffic that Android exposes to its VPN API.

• ✅ Use allow-list mode when only a few named apps need the VPN.
• ✅ Use exclude-list mode when most traffic should use the VPN and only selected apps need a direct path.
• ✅ Reconnect after changing the application list so the new policy is applied.
• ❌ Do not assume an app bypasses the VPN simply because its page opened from an old cache.
• ❌ Do not run two VPN clients at the same time; Android normally grants the VPN interface to only one active service.

Routing principle Split tunneling chooses the traffic path for an application. It does not automatically change the application’s account region, content permissions, DNS records, or server-side policy.

Choose the right app rule mode before adding packages

Start by writing a small routing list instead of opening the client and selecting apps randomly. Put apps into three groups: apps that must use the VPN, apps that must remain direct, and apps that can follow the default policy. The first group may include a browser used for international services, an AI tool, or a work application that requires a particular exit region. The second group may include local banking, local government, home-device control, printer discovery, or services that reject a foreign exit address. The third group should remain unmodified until you understand the effect of the policy.

For most people, allow-list mode is the safer starting point. It limits the scope of the change and makes testing easier because you know exactly which applications are expected to use the tunnel. Exclude-list mode is useful when you need broad VPN coverage, but it can expose more applications to route changes than you intended. It may also affect background synchronization, push notifications, or applications that you forgot were installed.

Read the client’s wording carefully. “Bypass VPN for selected apps” and “VPN only for selected apps” are opposite policies. Some clients show a switch such as “Allow selected apps,” “Disallow selected apps,” or “Per-app proxy.” Others place the feature under routing, profiles, advanced settings, or a profile editor. A checked box may mean either “included” or “excluded,” so confirm the description and test one known application before building a long list.

Rule priority matters when the client offers domain rules, IP rules, and application rules together. A package rule may determine whether an app enters the tunnel, while a domain rule may determine how a particular request is handled after it enters. A direct rule for one domain does not always bypass the entire application, and an application exclusion may override all domain rules for that package. The exact order is client-specific, so use the client’s displayed priority rather than copying a rule structure from another platform.

Configure split tunneling on Android step by step

Before editing the profile, install the Android client from the provider’s client download page or its official release channel. Confirm that the client supports the protocols used by your subscription. Depending on the subscription and client, these may include Shadowsocks, VMess, Trojan, VLESS, Hysteria2, TUIC, or WireGuard. Protocol support alone is not enough: the client must also parse the subscription format, transport settings, TLS options, authentication fields, and DNS instructions correctly.

1. Import the subscription. Use the client’s subscription import, clipboard import, QR import, or remote configuration function. Treat the subscription URL as a credential. Do not paste it into a public decoder, search engine, or group chat. After importing, check that the client displays profiles or routes rather than only reporting that the URL was saved.
2. Update the configuration. If the client provides a subscription update action, run it before testing. An old profile may contain removed routes or outdated parameters. If the update fails, read the error message and check the network used for the update; do not immediately conclude that every route is unavailable.
3. Open the routing section. Look for split tunneling, per-app routing, app proxy, VPN mode, or bypass settings. Select the intended policy: only selected apps through the VPN, or all apps except selected apps.
4. Select packages carefully. Use the visible application name and inspect similar entries. Avoid selecting every package with a similar name unless you know they belong to the same service. If the client offers system apps, leave them unchanged during the first test unless a specific requirement calls for them.
5. Save the profile and connect. Android will display a VPN permission prompt when the client requests access. Confirm that the expected client is shown. If Android offers an always-on VPN or block-without-VPN option, do not enable it casually; those settings can change the behavior of excluded applications and may prevent direct fallback.
6. Reconnect after saving. Disconnect the current tunnel, apply the profile, and connect again. Some clients update the application list only during a new connection. A status indicator that remains connected does not prove that the new rules have taken effect.

Android battery management can also interfere with a per-app VPN. If the client is frequently suspended in the background, the tunnel may disconnect or fail to refresh its rules. Review the system’s battery settings for the VPN client, especially on devices that aggressively restrict background activity. Do not grant unrelated permissions simply to make a connection work. Keep the client’s required permissions narrow and use its logs to identify whether the problem is suspension, permission denial, DNS failure, or route rejection.

Verify both application routing and DNS behavior

Verification should test the included app, an excluded app, and a neutral control. If you configured a browser to use the VPN, open the IP lookup page inside that browser and record the displayed exit region before and after connecting. Then open the same page in an application that should remain direct, if that app supports web content. The results should match your policy, but remember that some applications use their own DNS resolver, proxy, or encrypted transport and may not behave like a standard browser.

Do not rely on a changed public IP alone. A browser may show a new exit address while another application continues through the direct network. Conversely, an app may show cached content even though its new requests are routed differently. Fully close and reopen the test application, sign out only when necessary, and repeat a request that clearly requires a network connection. For streaming or account-based services, a catalog result can also be affected by cookies, account settings, licensing, and platform controls, so it is not a pure VPN test.

DNS deserves separate attention. A split-tunnel policy can route application packets through the VPN while DNS queries still use the local resolver, or it can send all DNS queries through the VPN even for applications that are excluded. Some clients provide “remote DNS,” “follow routing,” “fake IP,” or “local DNS” choices. These names describe different implementations and should not be treated as interchangeable. If the excluded app needs local name resolution, forcing every DNS query through a remote resolver may make local services fail. If privacy or regional resolution is important for an included app, local DNS may produce a different result from the VPN route.

• ✅ Test the selected app after a fresh connection rather than using an old cached page.
• ✅ Test an excluded app separately and confirm that its expected local service still works.
• ✅ Compare IP location, DNS resolution, and application behavior as separate observations.
• ✅ Check whether the client has a DNS mode that follows application routing.
• ❌ Do not publish screenshots containing a subscription URL, access token, full node details, or private diagnostic logs.

If an included application still reports the direct exit address, check whether it uses a private DNS setting, an embedded proxy, or a separate package. If an excluded application shows the VPN exit, confirm that the app is actually listed in the exclusion policy and that the client reconnected after the change. Also check Android’s system VPN settings for always-on behavior, because a system-level policy can alter the expected fallback route.

Understand rule conflicts, protocols, and client limits

Per-app routing is controlled by the Android client, while the subscription supplies connection profiles. These are separate layers. A subscription can connect successfully in the provider’s official Android client but fail to behave correctly in a general-purpose client if the latter parses the route format differently or lacks support for a transport option. The reverse can also happen: a general-purpose client may expose detailed routing controls that the official client does not provide, but require more manual maintenance.

Shadowsocks is commonly used as an encrypted proxy protocol with relatively direct configuration fields. VMess and VLESS may include transport and TLS parameters that must match the server side. Trojan generally relies on TLS-related settings, while Hysteria2 and TUIC use UDP- or QUIC-oriented transport behavior. WireGuard uses a different configuration model with cryptographic keys and peer routes. The protocol name shown in an import screen does not confirm that every field is valid, and changing protocols will not repair an incorrect application rule.

When a route is unstable, isolate the variables in a controlled order. First confirm that the same profile can connect in the client. Then check whether the problem affects every application or only one package. Next compare full-tunnel and split-tunnel behavior without changing several DNS and protocol settings at once. If full tunnel works but one included app fails under split tunneling, investigate package selection, app-specific DNS, and embedded traffic first. If every app fails, inspect the profile, Android permission, network environment, and client logs instead.

Route labels such as direct, relay, BGP, CN2, or IEPL describe network design or path categories, not a universal performance guarantee. An IEPL route can be useful for a particular carrier and destination, while a BGP route may be preferable elsewhere. Split tunneling does not select a better route automatically; it only decides which applications are eligible to use the selected VPN profile. Test the route with the applications that matter to you rather than choosing solely by a label.

Recover quickly when an app stops working

If an application stops loading after split tunneling is enabled, avoid deleting the entire subscription immediately. First disconnect the VPN and check whether the application works directly. If it does, reconnect with a full-tunnel profile or temporarily remove the app-specific rule. This separates an application-rule problem from a general route or account problem.

Next, confirm the policy direction. A selected package may have been placed in the bypass list when it needed to be included, or placed in the include list when it needed direct access. Save the corrected policy and reconnect. If the application still fails, clear only the client’s relevant profile cache or recreate the profile according to the client’s documentation. Avoid clearing Android application data unless you have the subscription information available and understand which local settings will be removed.

For local services, check whether the issue is caused by DNS rather than the application rule. A home device may be reachable only through a local hostname, while a remote DNS resolver cannot resolve that name. A work application may require a specific private DNS path. Change one DNS option at a time, reconnect, and record the result. If the client supports logs, remove subscription secrets from the log before sharing diagnostic information with support.

Android’s always-on VPN and block-without-VPN settings deserve special attention during recovery. Block-without-VPN can intentionally stop excluded traffic when the tunnel is down, which may look like an application failure. Always-on behavior can also reconnect a profile after you think the client is disconnected. Review those system settings and return to the default behavior if you need direct connectivity for recovery.

Once the app works again, reintroduce the split rule gradually. Keep a simple record of the selected mode, included packages, excluded packages, DNS mode, and profile name. This makes future troubleshooting much faster, especially after an Android system update or a client migration. If the client cannot provide the routing control you need, use the provider-recommended client or a compatible client that documents per-app routing rather than combining multiple VPN applications.

LaoVPN supports Windows, macOS, iOS, Android, and Linux, with subscription-based configuration for compatible official and third-party clients. You can review the setup guide for platform-specific import steps before creating an Android split-tunnel profile.