Android Split Tunneling Guide: Choose Which Apps Use VPN

Android split tunneling lets you decide which apps use a VPN connection and which apps continue through the ordinary network. This is useful when one app needs a different exit region, while local services, banking tools, smart-home controls, or bandwidth-heavy downloads should remain direct. The feature is not simply an on/off switch: the Android client, VPNService permission, subscription format, routing mode, DNS behavior, and app rules must all agree.

A reliable setup has four stages. First, use a compatible Android client and import the original subscription link. Second, confirm whether the client uses an allowlist or a bypass list. Third, select the applications and connect with the intended mode. Finally, verify the result from inside the selected app and from an app that should remain direct. If you check only the VPN icon in the status bar, you may mistake an active tunnel for correctly applied app rules.

What Android Split Tunneling Actually Controls

Android normally allows one VPN service to register through the system VPNService interface at a time. A compatible client creates a virtual network interface, receives permission from Android, and then decides which application traffic enters that interface. The application rules are therefore enforced by the client and the operating system together. Android does not automatically understand every proxy protocol or subscription format on its own.

In an include mode, sometimes called an allowlist mode, only the apps you select are sent through the VPN. All other applications use the normal connection, assuming the client and Android do not apply an additional block rule. This is usually the easiest mode to understand when you want to protect one or two apps and leave everything else unchanged.

In an exclude mode, sometimes called a bypass mode, most applications use the VPN while the apps you select are kept outside it. This is more convenient when you want broad VPN coverage but need a few local or network-sensitive applications to connect directly. It also carries a higher risk of sending more traffic through the tunnel than you intended if the rule list is incomplete.

App-based routing is different from domain-based routing. A split-tunnel rule for a video application may cover the traffic generated by that application, but it may not automatically control a browser opened from a notification, an embedded web view, a separate download helper, or a companion application. Some apps also use several processes or external authentication components. If only part of an app works, inspect its related processes and the client’s rule behavior before changing protocols.

Android clients may present the feature under names such as “Per-app VPN,” “App proxy,” “Application rules,” “Bypass apps,” or “Route applications.” The wording is not standardized. Read the description beside the switch, identify whether the list means “use VPN” or “do not use VPN,” and check whether a mode change requires reconnecting. A list that looks correct can have the opposite effect when the client is set to bypass mode.

Client and Protocol Compatibility

The official Android client is generally the simplest starting point because its subscription format, route options, and app-rule interface are designed for the service. A compatible sing-box-based Android client may offer more granular routing, but its rule syntax and import workflow can be different. Clash-family Android clients may also use YAML profiles and their own application matching behavior. Clash Verge is primarily a desktop client, so it should not be treated as an Android solution merely because a configuration works on Windows or macOS.

Shadowsocks, VMess, Trojan, VLESS, Hysteria2, and WireGuard are not interchangeable entries. Shadowsocks requires the server, port, password, and encryption method to match. VMess commonly depends on the user ID, transport, host, and path. Trojan and VLESS may require correct TLS, server-name, and transport parameters. Hysteria2 depends on its compatible QUIC-based settings, while WireGuard uses key and peer parameters rather than a conventional proxy subscription. The Android client must support both the protocol and the fields delivered by the subscription.

A successful import does not prove that every node is usable. The client may display a server list while silently skipping unsupported protocols or fields. If a selected app cannot connect, test one known-compatible node first, inspect the client log, and then compare another protocol. Avoid disabling TLS certificate verification or accepting an unknown certificate merely to force a connection.

Choose the Right App Rule Before Connecting

Start by describing the desired traffic in plain language. “Only my video app uses the VPN” suggests include mode. “Everything uses the VPN except local payment and casting apps” suggests exclude mode. Writing this down prevents a common mistake: selecting applications first and discovering later that the current mode reverses the intended result.

Consider companion applications and login dependencies. A streaming app may open a browser for account verification. A work application may rely on a separate authentication app. A game may use a launcher, update service, or push-notification process. If the main app uses the VPN but its login helper remains direct, authentication can fail. Conversely, routing every companion service through a distant exit can make local sign-in or device discovery unreliable.

Also consider whether the app uses IPv4, IPv6, or both. Some clients apply application rules to the VPN interface but handle IPv6 separately. If a service appears to ignore the selected route, check whether the client supports IPv6 handling and whether DNS requests follow the same policy. Do not assume that changing the visible server is enough to correct a leak or a routing mismatch.

• ✅ Use include mode when only selected apps need the VPN.
• ✅ Use exclude mode only after listing the apps that must remain direct.
• ✅ Add login helpers, launchers, and companion processes when the target app depends on them.
• ❌ Do not assume a selected app name controls every browser window or external helper it opens.
• ❌ Do not run two VPN or proxy clients at the same time; Android normally allows only one active VPN service.

Hands-On Setup: Import, Select Apps, and Connect

The exact labels vary by client, but the following sequence works as a safe general method for Android. Before editing rules, ensure that the subscription is current and that at least one node is visible. If the list is empty, solve the import problem first; app rules cannot repair an invalid subscription.

1. Install a compatible client. Use the service’s Android download instructions or a recognized client that explicitly supports the protocols in your subscription. Check the developer identity and supported configuration formats.
2. Import the subscription. Open the client’s subscription or profile section, add the original URL, save it, and refresh the list. Confirm that server names and protocol types are displayed correctly.
3. Choose one node for the first test. Select a route appropriate for the target service region. Do not change the node, protocol, app list, and DNS mode simultaneously, because that makes later troubleshooting ambiguous.
4. Open application routing. Look for per-app VPN, application rules, or a similar setting. Read whether the current list means “apps through VPN” or “apps bypass VPN.”
5. Select the test application. For a narrow test, use include mode and select only the target app. If the client offers a separate system-app switch, leave it unchanged until the basic application test succeeds.
6. Save and reconnect. Some clients apply rules only after the tunnel is stopped and started again. Approve Android’s VPN connection request if it appears, and check that no other VPN profile is active.
7. Test both paths. Open the selected app and verify its route. Then open an unselected app that should remain direct. Test again after switching between Wi-Fi and mobile data if both networks are part of your normal use.

When a client provides a rule preview or connection log, use it. The log may show whether an application was matched, whether a DNS request was handled by the tunnel, and whether the selected node accepted the connection. A status icon only confirms that Android has an active VPN interface; it does not confirm that the intended package is using the correct path.

Verify the Selected and Direct Applications

Verification should use two applications with different expected outcomes. For the selected application, check whether the displayed region, account behavior, or service availability matches the VPN route. For the direct application, check that it still reaches local services normally and does not unexpectedly inherit the remote exit. Use the same network while comparing results so that a Wi-Fi change is not mistaken for a routing change.

For an app that accesses websites, open a trusted IP or DNS checking page inside that app’s own browser component. If the app does not display web content, use the client’s route log and the service’s own connection information. Avoid relying on a browser test alone: Android’s browser, the target app, and a background helper can use different processes and may not be covered by the same rule.

DNS deserves separate attention. A VPN may route application data while DNS requests are still sent through the default network, or the client may deliberately use a remote resolver. Either behavior can affect region detection and privacy expectations. Review the client’s DNS mode, encrypted DNS settings, and IPv6 behavior. If changing DNS fixes the target app but breaks local discovery, use a documented split policy rather than repeatedly switching random servers.

Common symptoms can be grouped by layer:

• The VPN connects, but the selected app remains unchanged: Check whether the list is an exclude list, whether the app has multiple processes, and whether the client requires a reconnect after saving.
• The selected app has no network access: Try a different compatible node, inspect the protocol log, and check whether Android battery restrictions stopped the client in the background.
• Unselected apps also use the VPN: Confirm that the client is not in global mode and that the rule profile was actually activated.
• Local devices disappear: Review local-network bypass options, multicast or discovery requirements, and whether the selected app is communicating with a local address.
• Only sign-in or notifications fail: Add the authentication or companion process if appropriate, or test whether that service must remain direct.

Battery Optimization and Background Reliability

Android may restrict background activity when an application is idle, the screen is off, or battery-saving policies become active. A split-tunneling client needs to maintain the VPNService connection, refresh routing state, and sometimes keep a notification visible. If Android suspends the client, the tunnel may disconnect, rules may not refresh, or an app may silently fall back to its ordinary network.

Open Android’s battery settings for the client and review whether it is set to unrestricted or allowed to run in the background. The exact labels depend on the device manufacturer. Also check autostart permissions, background-data restrictions, data-saver rules, and aggressive “sleeping apps” features. Make the least permissive change that solves the problem; unrestricted background execution can increase battery use.

Do not judge battery impact from one short session. VPN encryption, packet handling, DNS processing, and the workload of the selected app all contribute. Routing only a high-use application through the VPN can reduce tunnel traffic, but the client still has to monitor the VPN interface. If battery consumption rises, compare include mode with global mode, disable unnecessary auto-refresh tasks, and avoid keeping several profiles active.

Always-on VPN and “block connections without VPN” settings require extra care. These Android controls can override the practical result you expect from a split configuration. A direct application may lose access if the system blocks non-VPN traffic, even when the client’s app list says that application should bypass the tunnel. Review system-level VPN settings together with client-level rules before concluding that the rule engine is broken.

How to Undo a Configuration Safely

When testing is complete, remove temporary rules instead of leaving an experimental profile active. Return the client to its default or global mode only if that is what you intend, then reconnect and verify one selected and one unselected app again. If you want the phone to use a normal connection, disconnect the client and confirm that Android no longer shows the VPN indicator.

If the phone behaves unexpectedly, use a controlled reset. Stop the client, disable always-on or block-without-VPN options if they were enabled for testing, remove the application rules, and reconnect the normal network. If Android asks whether to allow a VPN again, read the prompt rather than approving it automatically. Clear only the client profile or subscription that you intend to remove; deleting account information is not necessary for ordinary route troubleshooting.

Before creating a new profile, record the settings that worked: client name, subscription source, protocol, node region, routing mode, selected apps, DNS mode, and battery permission. This record is more useful than a screenshot of a single connected state because it identifies the variables that affect the result. Never share the full subscription URL in that record; redact credentials and access tokens.

• ✅ Confirm the client supports the subscription’s actual protocols and format.
• ✅ Decide whether the list means “use VPN” or “bypass VPN” before selecting apps.
• ✅ Reconnect after changing application rules or system VPN settings.
• ✅ Test the selected app, an unselected app, DNS behavior, and background operation.
• ❌ Do not disable certificate verification or install unknown certificates to solve a route error.
• ❌ Do not leave always-on blocking enabled until you have confirmed which apps must remain direct.

For most Android users, the safest approach is to begin with one application, one compatible node, and include mode. Once that path is verified, expand the rule set gradually and document each change. Use exclude mode when broad VPN coverage is genuinely needed, but review local services, authentication helpers, DNS, IPv6, and battery behavior before relying on it daily. With a clear rule direction and a repeatable verification process, split tunneling becomes a practical traffic-management tool rather than a source of unexplained connection failures.