Android Split Tunneling Guide: Set VPN App Rules Easily

Android split tunneling lets you decide which apps use a VPN connection and which apps continue to use the regular network. This is useful when one phone serves several purposes at once: a browser or work app may need a remote route, while banking, local services, games, or devices on your home network may work better through the direct connection. The goal is not to force every app through one tunnel, but to match routing behavior with the way you actually use the phone.

Per-app rules are simple in principle, but the result depends on the Android client, the VPN implementation, battery management, and whether another application is already controlling the system VPN slot. This guide explains how to plan the rules, configure them in a compatible client, verify the result, and troubleshoot the most common conflicts. The names of menus vary between official VPN apps, sing-box-based clients, and other Android-compatible tools, so focus on the meaning of each option rather than looking for one exact label.

What Android split tunneling actually changes

An Android VPN normally creates a virtual network interface and asks the operating system to send selected traffic through it. With split tunneling, the client adds application-based rules to that routing decision. Depending on the client, you may either choose apps that should use the VPN or choose apps that should bypass it. These are usually called an allow list and a disallow list, although some clients use terms such as “VPN apps,” “bypass apps,” “exclude apps,” or “per-app proxy.”

In VPN mode, selected applications send traffic into the encrypted tunnel and then to the chosen route. Applications outside the selection use the normal Android network path. In bypass mode, most applications use the VPN and the apps you exclude remain direct. The two modes may look similar in the interface, but they produce very different results when you add or remove an application. Always check which mode is active before saving the rule set.

Split tunneling does not turn a VPN into an application firewall with unlimited control. Some apps use several processes, companion services, browser components, or system services. An application may also connect through a web view, a custom domain, or a separate background process that the client does not expose in the same way as the visible app. For this reason, a rule should always be tested against the actual behavior you care about instead of being judged only by the label shown in the app list.

Plan your app rules before touching the settings

Start with tasks rather than app names. Write down which activities need the VPN, which activities should stay direct, and which activities must not run at the same time. For example, you may want an international browser or collaboration tool to use the tunnel, while a local payment app, smart-home controller, or local streaming service remains on the ordinary connection. This approach prevents a common mistake: adding apps one by one without understanding whether the current client uses inclusion or exclusion logic.

Keep the first rule set small. Choose one application that clearly needs the VPN and one application that should clearly remain direct. Test both before adding more. If you select many apps immediately, a failure becomes difficult to diagnose because the problem could come from a wrong mode, an overlooked system service, a battery restriction, or one incompatible application.

• ✅ Use inclusion mode when only a small group of apps needs the VPN.
• ✅ Use exclusion mode when most apps should use the VPN and only a few must stay direct.
• ✅ Record whether each application is expected to access local devices, domestic services, or remote destinations.
• ✅ Keep local payment, home-network, and device-management apps direct unless you have tested them carefully through the tunnel.
• ❌ Do not assume that a game, browser, or messaging app uses only one network process.
• ❌ Do not change routing mode and several other connection settings at the same time.

Also consider DNS behavior. A VPN client may send DNS queries through the tunnel even when an application is excluded, or it may apply a local DNS rule to all apps. This can make an app appear partially routed: the application opens, but a local hostname fails; or a service loads a region-specific result even though its main connection is direct. DNS handling differs by client, so look for options related to remote DNS, system DNS, fake IP, or per-app DNS behavior when the result does not match the routing rule.

Choose a client that exposes per-app controls

The official Android client is usually the easiest starting point because its connection profile, subscription update process, and per-app controls are designed together. If the service provides an official application, install it from the service’s stated distribution channel, sign in, import the available configuration or subscription, and look for a per-app VPN or split-tunneling section. The exact position may be under connection settings, advanced settings, route settings, or application settings.

Compatible clients can be useful when you need more detailed routing. sing-box-based Android clients may expose rule sets, package names, DNS policies, and multiple outbound groups. Other clients may use a simpler application selector. A subscription link is not the same thing as a split-tunneling rule: the subscription supplies server or outbound configuration, while the local client decides how application traffic is assigned. Importing a subscription does not automatically create the app policy you want.

On Android, only one application normally owns the active system VPN service at a time. Running an official client together with a sing-box-based client, an ad-blocking VPN, a firewall VPN, or another traffic-filtering tool can cause one connection to replace another. Clash Verge is primarily a desktop client and should not be treated as an Android per-app solution. Shadowrocket is associated with Apple platforms, so it is not a substitute for an Android VPN service. Select one Android client for the test and close competing VPN or filtering applications first.

Before importing a configuration, confirm that the client supports the protocol contained in it. Shadowsocks, VMess, Trojan, Hysteria2, and WireGuard are connection technologies, not interchangeable app-rule formats. A client can support one protocol but still lack the per-app controls, DNS options, or rule behavior available in another client. If the import succeeds but the application selector is missing, that is a client capability issue rather than proof that the subscription is invalid.

Configure split tunneling step by step

The following process works across most Android VPN clients, even when the labels differ. Keep the existing connection profile unchanged during the first test. If the client supports exporting or backing up local settings, save a copy before making complex rule changes.

1. Connect once without split tunneling. Confirm that the client can establish a normal connection. If the full-tunnel connection already fails, fix the profile, protocol, subscription, or route first.
2. Open the per-app setting. Look for split tunneling, app routing, per-app proxy, bypass list, or a similar option. Read the description carefully so you know whether the list is inclusive or exclusive.
3. Select a small test group. Add one app that should use the VPN and, if possible, one app that should remain direct. Avoid selecting Android system processes during the first pass.
4. Save and reconnect. Some clients apply rules immediately, while others require the tunnel to be stopped and started again. Reconnect after changing the list so old sockets do not confuse the test.
5. Check Android’s VPN indicator. The indicator only confirms that a VPN service is active. It does not prove that every app is using it or that the selected app is following the expected route.
6. Test each app separately. Fully close the app, reopen it, and perform a recognizable network action. Test the direct app independently instead of comparing two apps running at the same time.
7. Add the remaining apps gradually. If a new application fails after being added, remove only that application and repeat the test. This creates a clear cause-and-effect trail.

For a client that offers several routing modes, begin with the simplest mode. Rule-based routing can combine application rules with domain rules, IP rules, geolocation lists, and protocol-specific outbounds. That flexibility is useful, but it also creates more opportunities for an earlier rule to match before the app rule. Read the order of evaluation if the client documents it. A broad direct rule placed above an app-specific VPN rule may cause the selected app to bypass the tunnel.

Do not confuse “bypass VPN” with “block without VPN.” A bypass option sends an app through the ordinary network. An always-on or kill-switch-style option may block traffic when the VPN is unavailable. These settings solve different problems. If you need an app to stop working whenever the tunnel drops, use an explicit blocking feature only after understanding its scope; otherwise, you may accidentally block local services or background functions that were supposed to remain direct.

Verify the result instead of trusting the toggle

A successful connection message is only the first check. Verify the selected application and the excluded application separately, preferably on the same network and with the same client state. The VPN app’s connection page can confirm the selected route, but application-level testing is needed to confirm that the split rule is being applied.

For the app that should use the VPN, check an external IP or region indicator inside a browser or service that you trust. The result should correspond to the VPN route rather than your normal network. For the app that should remain direct, use a service whose normal behavior is familiar to you, and check whether local resources or local-only functions continue to work. Do not submit a private subscription link to a public testing website. If diagnostic information is needed, share only the minimum details and remove account tokens.

Test more than the foreground screen. Open the app, sign in if appropriate, load its main content, and perform the action that originally motivated the rule. Then lock the screen briefly, return to the app, and check whether the connection survives. Some applications create a background connection or hand a task to a companion process. If the foreground action works but notifications, uploads, or synchronization do not, investigate background behavior and battery restrictions rather than immediately changing the route.

Fix battery restrictions and background failures

Android manufacturers often limit background activity to extend battery life. A VPN client may be connected while its routing service is suspended, or it may reconnect slowly after the phone enters a power-saving state. The visible symptom can look like a split-tunneling error: one app stops updating, the tunnel appears idle, or the route changes after the screen is locked.

Open the system battery settings for the VPN client and review whether it is restricted, optimized aggressively, or prevented from running in the background. The exact menu differs by manufacturer. If the app needs persistent routing, permit the background operation required by the client. Apply the same review to an app whose background traffic must be reliable, such as a collaboration or synchronization tool, while avoiding unrestricted background access for applications that do not need it.

Power-saving modes can change network behavior even when the VPN configuration is correct. Test once with the phone awake and once after a normal lock-and-unlock cycle. If the problem appears only after the screen is locked, record the battery mode, background permission, and reconnect behavior. Do not disable every battery safeguard permanently without considering the effect on battery life and data use.

Network transitions are another source of confusion. Moving from Wi-Fi to mobile data, changing between access points, or entering a captive portal can invalidate existing connections. Reconnect the tunnel after the network becomes usable, then retest the selected and excluded apps. If only one application fails after a transition, force-stop and reopen it; if every application fails, inspect the VPN profile, network permission, and competing services first.

Resolve conflicting rules and maintain the setup

Conflicts usually come from one of four places: two VPN-capable apps competing for the system slot, contradictory inclusion and exclusion settings, a broad domain or IP rule overriding the app rule, or a subscription update replacing local preferences. Change one layer at a time. First close other VPN and firewall applications. Next simplify the rule list. Then inspect advanced routing and DNS settings. Only after that should you test a different protocol or route.

Keep a short record of the working configuration: client name, connection profile, routing mode, selected apps, excluded apps, and whether background access is needed. This is especially helpful after an Android system update or client reinstall. If the client has separate profiles for different networks, check that you edited the active profile rather than a dormant one.

Subscription updates normally refresh server configurations, but some clients treat the remote configuration as authoritative and overwrite local changes. After each update, confirm the active route and the split-tunneling list. If the list is reset, look for a profile-lock, local-override, merge, or backup option. Never edit a downloaded configuration blindly if the client expects a structured format; a malformed file can remove working routes or create rules that are difficult to inspect.

• ✅ Keep one known-good route available while testing a new route or protocol.
• ✅ Reconnect after changing per-app rules, DNS behavior, or the active profile.
• ✅ Check Android’s active VPN permission when a new filtering app is installed.
• ✅ Re-test after subscription updates, client upgrades, and major network changes.
• ❌ Do not run an ad-blocking VPN and a separate VPN client together unless the design explicitly supports it.
• ❌ Do not diagnose a routing rule with several other settings changing simultaneously.

A practical Android setup for everyday use

For most users, the safest starting configuration is a small inclusion list: place only the applications that clearly need the VPN in the list, keep local and sensitive applications outside it, and verify the result one app at a time. This minimizes unexpected changes to local services and reduces the amount of traffic sent through the tunnel. If your daily workflow depends on the VPN for nearly everything, exclusion mode may be more convenient, but review every newly installed application because it may inherit the default VPN path.

Use the official Android client when you want a straightforward subscription import and fewer moving parts. Use a compatible advanced client when you understand its rule order, DNS design, and outbound groups and need finer control. In either case, choose a route based on the destination and current network conditions rather than assuming that one protocol or location is always best. A route that works well on mobile data may behave differently on home Wi-Fi or a public network.

QaVPN supports Windows, macOS, iOS, Android, and Linux, with subscription-based configuration for compatible clients. The service lists coverage of 90+ countries and 200+ routes, supports unlimited online devices, and offers monthly plans of ¥9.9/month with 60GB, ¥18/month with 250GB, and ¥28/month with 500GB. Traffic resets monthly from the activation date. For users with irregular usage, traffic packages are available as ¥158/300GB, ¥358/1000GB, and ¥658/3000GB, usable until exhausted without expiration.

When you are ready to test the setup, get the client or view the setup guide. Import the configuration, connect with a simple profile, add a small app rule, and verify the actual task before expanding the list.