Android Split Tunneling Guide: Route Apps with VPN Rules

Android split tunneling lets you decide which apps use a VPN tunnel and which apps keep using the ordinary network connection. This is useful when one application needs a different region or a protected route, while another works better with a direct connection. It can also reduce unnecessary routing for local services, banking apps, smart-home tools, or work systems that should remain reachable through the normal network.

The important point is that split tunneling is controlled by the VPN client, not by the subscription link alone. A subscription can provide server addresses, protocol parameters, and route groups, but the Android client decides how traffic is captured and which application rules are applied. Depending on the app, you may see options called per-app VPN, app bypass, include apps, exclude apps, split tunneling, or application rules. These labels may describe different behaviors, so always test the actual result instead of assuming that two similarly named settings work the same way.

What Android split tunneling actually does

When an Android VPN client starts a tunnel, it normally creates a system VPN interface and receives traffic from applications according to the client’s routing policy. In a full-tunnel configuration, most or all application traffic is sent into that interface. The client then forwards matching traffic through the selected remote route. In a split-tunnel configuration, the client creates exceptions or an allowlist so that only selected applications, or only selected destinations, use the tunnel.

There are two common policy models. An include list sends only the apps you select through the VPN, while all other apps use the direct connection. An exclude list sends most applications through the VPN but leaves selected apps outside it. Include mode is usually easier to reason about when you need to protect only a few applications. Exclude mode is convenient when almost everything should use the tunnel and only local or sensitive applications need to stay direct.

Not every Android client implements these policies at the same level. Some clients match applications by Android package identity. Others expose only destination rules, domain rules, or a broad bypass switch. A client may support per-app routing for a built-in VPN mode but not for every protocol core. For example, a client that imports a subscription successfully may still lack application-level controls for a particular profile type.

Application rules also do not automatically solve every network dependency. An app may use a separate browser component, a background service, a WebView, or an account login handled by another app. If the visible application is direct but its login provider uses the tunnel, the final behavior may look inconsistent. Similarly, an app can open a remote connection through an IP address while its domain lookup is handled by a different DNS path. For this reason, the result should be tested by the app’s actual functions, not only by looking at the VPN icon.

Choose the client and policy before editing rules

Start by identifying which client will create the Android tunnel. A provider’s official Android client is generally the simplest option when it supports per-app rules directly. A compatible third-party client can be useful when you need more detailed routing, multiple profiles, protocol selection, or readable logs. sing-box-based clients and Clash-compatible Android clients may expose different rule structures, and their subscription formats are not interchangeable by default.

Before importing a configuration, check four compatibility points:

• ✅ The client supports the subscription format you intend to import, rather than merely accepting a URL field.
• ✅ The client recognizes the protocols used by the configuration, such as Shadowsocks, VMess, Trojan, Hysteria2, or WireGuard.
• ✅ The Android version and client version provide application-level routing, not only global proxy mode.
• ✅ The client shows connection logs, selected route information, or rule-match details that can be used during testing.
• ❌ Do not run two VPN applications at the same time and expect their app rules to combine.
• ❌ Do not assume that a browser’s proxy setting changes traffic from every other Android application.

Protocol support and split tunneling are separate questions. WireGuard may be supported by the Android system or by a dedicated client, while a Clash-compatible profile may require a Clash-compatible core. Shadowsocks, VMess, Trojan, and Hysteria2 also depend on the client’s parser and transport implementation. If a profile connects in full-tunnel mode but fails when application rules are enabled, first confirm that the client documents per-app support for that profile type. Do not immediately edit transport fields or replace server parameters.

Also decide whether you need app-based rules or domain-based rules. App-based rules are easier for a small number of applications, but they do not always distinguish individual destinations inside an app. Domain rules provide more control, but they require accurate domain coverage and may be affected by encrypted DNS, embedded domains, content delivery networks, or hard-coded IP addresses. For most first-time Android setups, begin with app-based routing and add destination rules only when the app behavior requires them.

Set up Android split tunneling step by step

The exact button names vary between clients, but the workflow is similar. The following sequence is designed to keep each change observable and reversible.

Prepare the configuration

Install the official client or a compatible Android client from a source you trust. If the service provides a subscription link, import it through the client’s subscription or profile section rather than pasting it into a random conversion website. A subscription link can contain account-identifying access information, so do not publish it in screenshots, issue reports, or chat messages.

After importing, update the profile and confirm that the server or proxy group appears. Choose one route for the initial test. If the client offers separate modes such as direct, rule, global, or proxy, select the rule-oriented mode only after confirming how that client defines application matching. Some clients treat “rule” as destination-based routing, while others combine destination rules with per-app policy.

Create an application rule

Open the client’s VPN settings and look for an application list. If the interface offers include selected apps, select only the application you want to test. If it offers exclude selected apps, make sure you understand whether every unlisted app will use the tunnel. A small allowlist is normally safer for diagnosis because it limits the number of variables.

Pay attention to similarly named applications. Android may show a main app, a companion app, a system WebView, a media service, or a work-profile copy as separate entries. Selecting one package does not necessarily select the others. If the target function opens another application for authentication or playback, that second package may need its own rule. Do not select an entire category without checking the package names and the client’s explanation of the policy.

Grant permission and activate the tunnel

Save the rule, start the connection, and accept Android’s VPN permission prompt. Android normally allows one active VPN service at a time. If another VPN, firewall, ad blocker, enterprise profile, or security application already owns the VPN interface, the new client may fail to start or may silently replace the previous service.

Keep the first test simple: leave automatic server selection disabled if the client allows it, use one profile, and avoid changing DNS settings until the app route is confirmed. Record whether the selected application can load its normal content and whether a known direct application continues to work. A connection icon only confirms that a VPN interface exists; it does not prove that every application is following the intended rule.

Test one application at a time

Force-close the target application before testing so that existing sockets do not remain open from the previous policy. Reopen it and test a complete function such as signing in, loading a page, refreshing content, or starting a connection. Then test an application that should stay direct. Switch the policy temporarily, repeat the same actions, and compare behavior.

After each change, allow enough time for the application to establish new connections. Do not judge a rule from a cached page or an already authenticated session. If the client has logs, check whether the application was matched by the expected rule and whether the selected route accepted the connection. A rule-match record is more useful than a general “connected” status.

If you need a more detailed walkthrough for importing a subscription and starting an Android client, consult the quickstart guide. Keep the split-tunneling changes separate from the initial import so that a failed connection can be isolated more easily.

Common conflicts and how to fix them

The app ignores the rule. First check whether the client is actually running in rule or per-app mode. A global mode may override application settings, while a direct mode may bypass the tunnel entirely. Next, force-close and reopen the app. If the app launches helper processes, add the related package only if the client identifies it as part of the same workflow.

The app connects but some features fail. This often indicates a split dependency. The main app may use the VPN while a browser, WebView, notification service, or authentication component uses a different path. The app may also require several domains that are not covered by a narrow destination rule. Test the feature in stages and inspect the client log. Avoid broad changes until you know whether the missing component is another app, a DNS lookup, or a rejected route.

Local devices become unreachable. A full-tunnel or restrictive DNS policy can affect access to printers, routers, media devices, and local dashboards. Check whether the client supports direct access to private network ranges or a local-network bypass option. If it does not, use the client’s documented direct rules rather than copying arbitrary route entries from another platform. Android network behavior can differ between Wi-Fi, mobile data, and work profiles.

Battery optimization interrupts the connection. Android manufacturers may suspend background VPN clients, especially when the screen is off. Review the client’s battery settings and allow the application to run in the background when persistent routing is required. This is a device-management setting, not a reason to weaken the application rules. Also check whether the system has enabled an always-on VPN or a “block connections without VPN” option that conflicts with your intention to keep some apps direct.

Private DNS changes the result. Android Private DNS can affect domain resolution independently of the client’s selected route. If an app resolves a domain outside the expected path, compare the client’s DNS mode with the Android system setting. Make one change at a time and repeat the same test. Do not conclude that application routing is broken merely because a domain lookup follows a different policy from the application’s main traffic.

Two networking tools compete for control. VPN clients, firewall apps, DNS filters, traffic monitors, and enterprise management tools may all attempt to use Android’s VPN interface. Stop the other service and test again. If the problem disappears, decide which application should own the tunnel. Running both tools simultaneously is rarely a reliable way to merge policies.

• ✅ Check the active mode before changing the app list.
• ✅ Force-close the app after every meaningful rule change.
• ✅ Test Wi-Fi and mobile data separately when the behavior differs.
• ✅ Inspect logs for package matches, DNS errors, and route failures.
• ❌ Do not treat the VPN status icon as proof that every rule is correct.
• ❌ Do not paste credentials or subscription links into third-party diagnostic tools.

Design rules that remain manageable

A good rule set is understandable months later. Use a small number of categories: applications that must use the VPN, applications that must remain direct, and applications that follow the default policy. If the client supports comments or named rule groups, use descriptive names such as “work direct” or “selected apps through route” instead of unexplained abbreviations.

Review rules after installing, uninstalling, or cloning applications. Android package identities can change when an application is replaced by a regional edition or moved into a work profile. A visible icon with the same name is not enough to confirm that the old package rule still applies. Recheck the application list after a major client update as well, because the client may change from an operating-system VPN implementation to a core-specific policy model.

Keep a fallback configuration. Export or record the profile name, selected mode, and the intended application policy where the client permits it. Do not export secrets to an untrusted location. If a subscription update changes available groups or protocols, update the profile first, then test the original application rule before adding new exceptions.

For streaming, communication, development, and productivity applications, choose rules according to the actual task rather than the application’s brand. A video application may use several services for login, playback, images, and telemetry. A development tool may call package registries, API endpoints, and browser authentication pages. A messaging application may keep notifications alive through a background process. These relationships explain why a rule that works for opening an app may fail when a deeper feature is used.

A reliable final checklist

Before considering the setup complete, confirm that the client imports the configuration without errors, the selected protocol is supported, and only one VPN service is active. Confirm whether the policy is include-based or exclude-based. Test one application that should use the tunnel, one application that should remain direct, and any companion application needed for login or media playback.

Repeat the test after switching between Wi-Fi and mobile data, after locking the screen, and after reopening the client. Check Android’s always-on and block-without-VPN settings, battery restrictions, Private DNS, and work-profile controls. If behavior changes, record the exact condition instead of making several random edits. That record makes it easier to identify whether the issue belongs to the application rule, the Android system, the selected route, or the client’s protocol support.

Split tunneling is most dependable when it is treated as a small routing policy rather than a one-click performance switch. Choose a compatible client, select a clearly defined mode, add applications gradually, and verify both the intended tunnel path and the intended direct path. With that method, you can change how individual Android apps connect without changing the configuration of your entire network.