Android Split Tunneling Guide: Set App Rules Easily

Split tunneling lets you decide which Android apps use a VPN and which apps keep using the normal network connection. This is useful when one app needs a specific remote region while another works better with a local route. It can also reduce unnecessary VPN traffic, prevent conflicts with local devices, and make troubleshooting easier because each app has an explicit path.

However, split tunneling is not simply a speed switch. Android applies the rules through its VPN service, and the exact behavior depends on the client, the selected protocol, the rule mode, DNS handling, IPv4 or IPv6 support, and whether another VPN or firewall is active. The safest approach is to decide which apps need protection or a remote exit, configure one rule set, and verify the result with actual app behavior instead of assuming that every connection follows the same path.

What Android split tunneling changes

Without per-app rules, an Android VPN normally creates a system-wide VPN interface. Applications send traffic to that interface, and the VPN client forwards it according to its tunnel configuration. With split tunneling enabled, the Android VPN service uses application-level rules to determine whether a package is placed inside or outside the tunnel.

An included app normally sends its supported traffic through the selected VPN node. The destination service sees the VPN exit rather than the device’s ordinary network address, subject to the protocol and client implementation. An excluded app normally uses the Wi-Fi or mobile network directly. It may still use the local gateway, the network provider’s DNS, or another DNS configuration supplied by the operating system.

This distinction matters because a rule applies to an application package, not necessarily to every service that appears on the screen. Some Android apps use background processes, web views, download workers, companion services, or separate packages. A main app can therefore appear to work while a login component, notification service, or media request follows a different path. If a service is important, test the complete workflow rather than checking only whether the first page opens.

Include mode or exclude mode?

Use include mode when only a small number of apps need the VPN. For example, you may want a browser, a work tool, or a streaming app to use a particular exit region while keeping banking, smart-home, local printing, or delivery apps on the direct connection. This mode is easier to audit because the tunnel’s scope is deliberately narrow.

Use exclude mode when nearly all apps should use the VPN and only a few have a clear reason to bypass it. This may be convenient for general browsing, but it requires more attention. Newly installed apps may automatically fall into the VPN path, and an excluded app may behave differently when it uses a shared account or exchanges data with an included app.

Prepare the Android profile before editing rules

Before changing application rules, make sure the base VPN profile works without split tunneling. Connect to a suitable line, open the apps you intend to test, and confirm that the client remains connected when the screen turns off and on. If the profile already has a protocol, DNS, or authentication problem, split tunneling will make diagnosis harder rather than solve it.

VPN TX supports Windows, macOS, iOS, Android, and Linux. On Android, the official client is usually the simplest starting point because it can associate your account with the service configuration directly. Compatible clients such as sing-box may also be used when you need more detailed routing control, provided that the selected client supports the subscription format and protocol in the profile. Clash-based Android clients use their own rule syntax and package behavior. Do not assume that a configuration copied from a desktop client will have identical application matching on Android.

Common transport choices include WireGuard, Shadowsocks, VMess, Trojan, and Hysteria2, but availability and rule support depend on the client and imported profile. A protocol changes how traffic is carried to the remote node; it does not automatically decide which Android apps should use that node. Keep protocol selection and app selection as two separate decisions.

1. Update the Android client and confirm that only one VPN application is set as the active VPN service.
2. Import the subscription through the supported subscription-link or profile-import method.
3. Select a line based on the destination and the required region, rather than choosing only by its name.
4. Connect with the default system-wide profile and test the apps before adding any rules.
5. Record the packages that need the VPN and the apps that must remain on the direct connection.

If you use a third-party client, check whether it supports per-app routing through Android’s VPNService interface, package-name matching, and the protocol contained in the imported profile. Some clients expose application rules under “App VPN,” “Per-app VPN,” “Application control,” or “Bypass apps.” The wording may differ, but the important question is whether the rule changes the VPN inclusion set, the exclusion set, or only the client’s domain rules.

Configure Android app rules step by step

The labels below describe the common workflow. Your client may place the controls in a profile editor, connection settings page, or advanced routing menu. Avoid changing several unrelated options at once; otherwise, you will not know whether a failure comes from the app list, the node, DNS, or the protocol.

1. Choose the rule mode

Open the active profile and locate the per-app VPN setting. Select include mode if the VPN is needed by only a few apps. Select exclude mode if most apps should remain inside the tunnel and only clearly identified apps should bypass it. Read the confirmation text carefully: some clients call include mode “VPN only for selected apps,” while others describe it as “allow list.” Similarly, bypass lists and deny lists can use opposite terminology.

2. Select packages, not just visible app names

Android may display a friendly app name while the client internally matches a package identifier. If two apps have similar names, open each entry and confirm the icon and package details. Select the main app first. If its sign-in, download, or notification function fails, inspect whether the client allows related packages to be added separately.

Be cautious with system components. Adding Android system services to an include or exclude list without understanding their role can affect many applications at once. Avoid broad selections such as “all system apps” during the first test. A narrow rule is easier to reverse and less likely to create a hidden dependency.

3. Save, reconnect, and test one change

Save the profile and disconnect the VPN before reconnecting. Some clients apply changes immediately, while others keep the previous tunnel until a new connection is created. After reconnecting, wait for Android to show the VPN indicator and check the client’s connection status. Then test one included app and one excluded app separately.

For an included app, check whether the service region, login session, and normal requests work as expected. For an excluded app, check whether local devices, direct services, or region-dependent functions return to their normal behavior. Do not use only the VPN client’s connection badge as proof: the badge confirms that a tunnel exists, not that every selected package is following the intended path.

4. Verify the actual path

Use a reputable IP or DNS checking page from the browser, but remember that this tests the browser package only. To test another app, use that app’s own connection or account status, a controlled upload or download, or a service that clearly reports its access region. Compare the result with the app inside and outside the VPN while keeping the node and network unchanged.

• ✅ Test an included app after connecting and confirm that it reaches the intended remote service.
• ✅ Test an excluded app separately and confirm that local or direct-only functions still work.
• ✅ Recheck the rule after switching from Wi-Fi to mobile data.
• ✅ Test background notifications if the app depends on a separate service process.
• ❌ Do not assume that a browser result proves the route used by every Android app.
• ❌ Do not edit protocol, DNS, node, and app rules simultaneously during troubleshooting.

For a detailed client and subscription workflow, see the view the guide. The exact control names can change between client versions, so use the current app interface as the final reference.

Common conflicts and practical fixes

When an app fails after split tunneling is enabled, the rule itself may not be the only cause. Android permits one active VPN service at a time, and another VPN, firewall, DNS changer, ad blocker, or security application can compete for the same traffic path. Disable competing network tools temporarily, reconnect the VPN, and test again before making the rule list more complicated.

The app still appears to use the wrong route

First confirm the mode. In include mode, an app not on the list should bypass the VPN; in exclude mode, an app not on the bypass list should normally use the VPN. Next, check whether the client applies rules only after reconnecting. If the behavior remains inconsistent, inspect IPv6 handling and DNS settings. An app may resolve a destination through one path and establish a connection over another, creating results that look like a rule failure.

Notifications or login functions fail

Some apps divide their work among a foreground package, a background worker, a web view, and a platform notification service. If the main screen loads but login callbacks, notifications, or downloads fail, add only the necessary companion package if the client exposes it. If the client does not provide that level of control, test the app with system-wide routing or use a simpler profile rather than adding broad system packages at random.

Local devices stop working

Printers, media receivers, local file shares, and smart-home devices often depend on local-network discovery. A full-tunnel profile may route or block traffic that should remain within the LAN. Excluding the relevant app may help, but it does not always restore every discovery protocol. Check whether the client has a “bypass local network” or equivalent option, and avoid changing it unless you understand how the client treats private addresses.

Battery and background behavior changes

Android battery optimization can pause a VPN client or its rule service when the screen is off. If the connection repeatedly disappears, allow the client to run according to Android’s battery settings, keep the profile persistent where appropriate, and check whether the system has restricted background data. This is separate from split tunneling, but it can make the rules appear unreliable because the VPN service is no longer active.

Reset without rebuilding the entire setup

When troubleshooting becomes unclear, export or note the current profile if the client supports it, then return temporarily to system-wide routing. Test the base connection, reconnect, and add one app rule at a time. If the problem disappears after removing the rules, rebuild the list from a minimal set. If it remains, investigate the node, protocol, DNS, account session, or destination service instead of continuing to edit application selections.

A safe split-tunneling checklist

Split tunneling is most useful when it reflects a clear decision about traffic boundaries. Before keeping the profile enabled, write down which apps need the VPN, which apps must stay direct, and why. This prevents a temporary exception from becoming a permanent route that you no longer remember.

• ✅ Use a narrow include list when only selected apps need a remote exit.
• ✅ Use an exclude list only when you understand which new apps will inherit the VPN path.
• ✅ Keep one tested profile with simple system-wide routing as a comparison point.
• ✅ Recheck app rules after reinstalling an app or changing the Android client.
• ✅ Test Wi-Fi and mobile data separately when the behavior matters on both networks.
• ✅ Review DNS, IPv6, local-network, and kill-switch settings as separate controls.
• ❌ Do not run two VPN clients at the same time and expect their rules to combine.
• ❌ Do not treat a successful browser IP check as proof for another application.
• ❌ Do not add broad system packages just because one background function failed.

For users who switch between phone, tablet, desktop, and other supported devices, the same account can be used across unlimited simultaneous devices according to the service specifications. That does not mean every device should share the same routing assumptions: Android package rules are platform-specific, while desktop clients may use different process or domain controls.

The best Android setup is therefore not the one with the most rules. It is the smallest profile that sends the intended apps through the intended VPN line, leaves trusted or local services on the appropriate direct path, and can be explained and tested later. Start with one mode, one node, and one app group; verify both included and excluded traffic; then expand only when a real requirement appears.