Android VPN Split Tunneling Guide: Route Apps Your Way

Android split tunneling is the practical way to decide which apps use a VPN tunnel and which apps keep using the ordinary network. Instead of sending every connection through one route, you can place selected applications inside the tunnel while leaving local services, banking apps, smart-home tools, or other traffic outside it. The setting sounds simple, but the result depends on the Android VPN service, the client’s rule model, DNS behavior, protocol support, and the order in which exceptions are evaluated.

The short answer is to begin with an app-based policy rather than a long list of domains. First decide whether the VPN should include only selected apps or exclude selected apps from an otherwise global tunnel. Then confirm how the Android client describes that choice, import the subscription, connect to a suitable route, and test each important application separately. A successful browser test does not prove that another app follows the same route, and an app that opens normally may still be using a different DNS or proxy path than expected.

What Android split tunneling actually controls

Android VPN clients generally use the system VPN service to create a tunnel interface. The client receives permission through Android’s VPN framework, then decides how application traffic is forwarded. Depending on the client, the policy may be implemented as per-app VPN routing, a proxy-based rule engine, or a combination of virtual routing and DNS handling. This is why two applications with similar-looking menus can produce different results.

There are two main policy models. An include list, sometimes called an allowlist or “VPN apps only” mode, sends only the applications you select through the tunnel. Everything else remains outside unless another system rule changes the result. An exclude list, sometimes called a bypass list, sends most applications through the tunnel but keeps selected apps on the direct network. The names are not standardized, so read the description carefully before saving.

Include mode is usually easier to reason about when only a few apps need the route. For example, you might select one browser, a collaboration app, and a testing tool, while leaving local payment, transportation, and home-network applications untouched. Exclude mode is more convenient when most applications need the same route and only a small number must stay direct. It also carries a greater risk of unintentionally sending a newly installed application through the tunnel.

App selection does not always describe every connection made by that application. An Android app may start a separate service, use a custom WebView, launch an external browser, or communicate through a background process. A download manager can also use its own process or follow Android’s network policy rather than the foreground app’s assumptions. If a selected app opens an external activity, test the external application as well instead of assuming that the original rule follows it.

DNS deserves separate attention. Some clients send DNS requests through the VPN, some use the system resolver, and some apply rules to DNS based on the selected mode. An app may appear to be routed correctly while its domain lookup still fails or uses a local resolver. Conversely, a domain may resolve to an address that is reachable only through a particular route. Split tunneling is therefore not merely a visual list of app names; it is a policy covering application traffic, name resolution, and sometimes IPv6.

Choose the client and subscription model

Start with the client recommended for the subscription. A provider-specific Android client often offers the shortest path from sign-in or subscription import to a working connection. A generic client can provide more control over app routing, DNS, proxy modes, and policy groups, but it also requires you to understand which subscription formats and protocols it can parse. Installing several clients at the same time is not a good first test because Android may show multiple VPN profiles and only one VPN service can normally control the active tunnel.

Common Android choices include an official provider client, sing-box-based clients, v2rayNG, and other rule-oriented applications. Their interfaces and supported configuration formats differ. sing-box is a framework and configuration engine rather than a guarantee that every client exposing it supports every feature. A subscription that imports successfully may still lose some provider-specific groups or advanced rules when converted into another format. Check the generated profile and compare its supported protocol fields before assuming that the import is complete.

The protocol also affects what the client can do. Shadowsocks is a proxy protocol frequently used in rule-based clients. VMess and Trojan require the client to understand their respective authentication and transport settings. Hysteria2 uses a different transport design and cannot be treated as a normal Shadowsocks entry. WireGuard uses a tunnel configuration with keys, peers, addresses, and routing parameters rather than a simple proxy URL. The application-routing interface may be shared across these protocols, but the underlying connection and troubleshooting steps are not identical.

For a subscription service that supports Windows, macOS, iOS, Android, and Linux, it is useful to keep the same general policy idea across devices, but do not expect identical syntax. A rule named “direct,” “bypass,” or “proxy” may mean something slightly different from one client to another. On Android, the system permission prompt, battery controls, always-on VPN settings, and per-app list are especially important because the operating system can affect the tunnel after the client reports that it is connected.

Configure app routing step by step

Before editing rules, connect the client with its default policy and confirm that the selected node can establish a tunnel. This separates a basic protocol or network problem from a split-tunneling problem. If the tunnel cannot connect globally, changing the app list will not repair the handshake. Select a route based on the destination and current network conditions rather than choosing a name only because it looks familiar.

Start with a small test set

Open the client’s settings and find a section labelled VPN apps, per-app routing, app proxy, bypass apps, or a similar term. Record the current mode before changing it. If the screen offers “VPN apps only,” select one test browser and one target application. If it offers “bypass selected apps,” select a local application that should remain direct. Avoid selecting the entire application list on the first attempt; a small test group makes the outcome easier to interpret.

Android may display system applications alongside user-installed applications. Be cautious with entries related to system services, connectivity checks, Google components, device administration, or local network discovery. Excluding or including a system component can have effects beyond one visible app. If the client offers a separate switch for system apps, leave it unchanged until the basic policy works.

Save the policy and check rule order

Rule order matters in clients that combine app rules with domain, IP, or final-policy rules. A broad direct rule placed before a more specific proxy rule may prevent the selected app from reaching the tunnel. In the opposite direction, a global proxy rule placed before a direct exception can make the exception appear ineffective. Look for a final rule such as proxy, direct, reject, or system default, and understand what happens when no earlier rule matches.

Some clients treat app selection as a separate layer from the domain rule list. In that design, an app can be allowed to enter the VPN tunnel while its request is still sent directly because the domain policy says direct. Other clients use the app list as a hard filter and then apply domain rules only after the traffic enters the tunnel. Read the client’s documentation and inspect its log view if the UI does not explain the order.

Apply Android permission and battery settings

When Android asks to create a VPN connection, approve the request only for the client you intend to use. If another VPN application is active, disconnect it first. Android may show a key or VPN indicator in the status area after the tunnel starts. That indicator confirms that a VPN service is active, but it does not confirm that every selected app is using the expected route.

Battery optimization can stop a client’s background service, especially when the device screen is off or the system is under memory pressure. The exact menu differs by Android version and manufacturer. If the tunnel disconnects after the device sleeps, review the client’s battery setting, background activity permission, and notification permission. Do not disable every power-saving feature by default; change only the setting required for the client to maintain its service.

Also check Android’s Always-on VPN and block-connections-without-VPN options. These are useful when you need to prevent accidental direct connections, but they may conflict with an intentional bypass design. If selected apps are meant to stay direct, a block-without-VPN policy can produce a result that looks like an app-routing failure. Make a note of these system controls before troubleshooting the client’s rule list.

• ✅ Confirm the tunnel connects with the default route before changing app rules.
• ✅ Begin with one or two applications so each result has a clear cause.
• ✅ Check whether the client uses include mode, exclude mode, or a separate direct rule.
• ✅ Review Always-on VPN, block-without-VPN, battery, and background permissions.
• ❌ Do not run two VPN clients at the same time while diagnosing routing.
• ❌ Do not assume an external browser or background service follows the foreground app.

Test direct and tunneled apps separately

Testing should compare an application that is supposed to use the VPN with one that is supposed to bypass it. Start with a simple request, then test the actual workflow you care about. For a browser, check the visible exit address and open a destination relevant to your use case. For a messaging, collaboration, or media application, sign in, load content, and leave the connection active long enough to observe whether it reconnects. A one-time page load is not enough for applications that maintain long-lived sessions.

Use the client’s connection log when available. The log may show the application name, destination domain, selected policy, DNS result, and outbound route. It can reveal that a request came from a different package than expected or that the application opened a domain covered by a direct rule. Avoid treating every log line as proof of a problem: background checks, analytics, certificate services, and content delivery requests can be normal. Focus on the request associated with the failed action.

Test local services independently. Open a device on the home network, use local casting or printer discovery if applicable, and check whether a local application still behaves normally. Some local features depend on multicast, private addresses, or direct device discovery that a full-tunnel mode may not handle as expected. If a bypass app works but its local feature does not, the issue may be local-network access rather than the selected app list.

DNS testing should use the same application and the same network conditions as the real task. Switch between Wi-Fi and mobile data only after the initial policy is understood, because a captive portal, carrier resolver, or router DNS policy can change the result. If IPv6 is enabled on the device and the client handles only IPv4 routing, an application may obtain an IPv6 path outside the intended policy. The correct response is to review the client’s IPv6 behavior and Android network settings, not to keep changing node names.

Safe rollback and ongoing maintenance

Keep a known-good baseline before experimenting. Export or copy the client profile if the application supports it, record the original app mode, and note which node connected successfully. Do not edit the only working subscription profile in place when the client provides a duplicate or backup option. A rollback is much faster when you can restore the previous profile instead of reconstructing every field.

If a rule change causes broad failures, return to the default global policy or temporarily disable split tunneling. Reconnect the VPN and test one browser request. If the global policy works, the problem is probably in the app list, rule order, DNS policy, or an Android system setting. If the global policy also fails, inspect the subscription update, protocol compatibility, current network, and selected node. This two-stage comparison prevents a routing rule from being blamed for a connection that never established correctly.

Subscriptions may change over time. A provider can add routes, remove entries, rename groups, or update transport parameters. After a subscription refresh, check whether the client preserved your app policy and final rule. Some clients keep the local routing configuration, while others replace part of the generated profile. If an application suddenly changes behavior after an update, compare the imported profile and the client version before rewriting the entire policy.

Use the simplest rule set that meets the requirement. A few clearly named app groups are easier to maintain than many overlapping exceptions. Keep notes such as “work apps through tunnel” or “local device direct,” and review them after installing a new application. When an app is updated, its Android package name usually remains stable, but a companion app or external activity may still introduce a new traffic source.

For users who need the same subscription on multiple systems, the service supports Windows, macOS, iOS, Android, and Linux, with unlimited devices online. That does not mean every platform exposes identical split-tunneling controls. Android app routing is package-based, while desktop clients may use process, domain, IP, or system proxy rules. Keep the policy goal consistent, but configure each platform according to its own routing model.

QEvpn provides 90+ countries and 200+ routes, with monthly subscriptions of ¥9.9/month including 60GB, ¥18/month including 250GB, and ¥28/month including 500GB. Monthly traffic resets each month on the activation date. Traffic packages are available as ¥158/300GB, ¥358/1000GB, and ¥658/3000GB, and remain available until used without expiring. Payment methods include Alipay, WeChat Pay, and USDT; registration requires only a username and password, without an email address. The service also provides a 30-day no-questions-asked refund policy.

For the Android setup itself, use the official instructions to import the subscription, select a compatible client, and verify the system VPN permission before building a larger rule set. View the guide when you are ready to move from a basic connection to a controlled per-app policy.