Android Split Tunneling Rules: A Practical VPN Setup Guide

Android split tunneling is useful when only certain apps should use a VPN while everything else stays on the normal connection. A streaming app, AI tool, work service, or browser can use a selected route, while banking apps, local devices, casting tools, and ordinary domestic services continue to use the direct network. This arrangement can reduce unnecessary routing and makes it easier to understand which application is responsible for a connection problem.

The difficult part is not finding an “include” or “exclude” switch. The important questions are what the rule actually means, whether the Android client can identify the app correctly, how DNS requests are handled, and what happens when the phone changes between Wi-Fi and mobile data. A configuration that appears correct on the first screen may still route the wrong apps, bypass the intended tunnel, or stop working after Android suspends the client in the background.

Android Split Tunneling: How app-based rules work

Most Android VPN clients use the Android VpnService interface. The client creates a local VPN interface, receives traffic selected by the operating system, and then forwards that traffic through a configured node or proxy protocol. The visible VPN icon belongs to Android’s system interface. The actual transport may use Shadowsocks, VMess, Trojan, VLESS, Hysteria2, TUIC, WireGuard, or another protocol supported by the client and service.

Split tunneling adds an application-selection layer before traffic is forwarded. Depending on the client, the setting may be named “per-app proxy,” “app rules,” “bypass apps,” “proxy only selected apps,” or “exclude selected apps.” Similar words can describe opposite behaviors, so never assume that selecting an app means “send this app through the VPN.” Read the label and test the result.

There are two common ways a client applies these rules. An allowlist can establish a tunnel only for packages selected by the user. A bypass list can establish a wider tunnel but exclude named packages from it. The result can look similar, yet the failure modes differ. With an allowlist, forgetting a required companion app may prevent sign-in or media playback. With a bypass list, a newly installed app may unexpectedly use the VPN until it is added to the exclusions.

The service, client, rule mode, and node are separate layers. A subscription link supplies configuration data; it does not automatically decide which Android packages should be proxied. A compatible client must import the subscription, create a usable profile, and then apply the app rules. If the node connects but one app still fails, investigate the rule and DNS behavior before replacing the entire subscription.

Choose the Right Rule: Start with a small and clear policy

Before touching the client, write down the desired behavior in plain language. For example: “Only the video app and its browser should use the VPN; local payment, casting, and home-control apps should remain direct.” This sentence is more useful than a long list of package names because it gives you a reference when the client presents several similar apps.

• ✅ Use an allowlist when only a small number of apps need the VPN.
• ✅ Add companion apps when sign-in, media delivery, or external links depend on them.
• ✅ Keep local banking, printing, casting, and device-control apps direct when that matches your privacy and connectivity needs.
• ✅ Record the selected rule mode before changing the profile so the configuration can be restored later.
• ❌ Do not confuse “bypass selected apps” with “proxy selected apps”; they are usually opposites.
• ❌ Do not select every package simply because its name contains “service,” “system,” or “Google.”
• ❌ Do not run two Android VPN clients at the same time; Android normally allows only one active VPN interface.

App Selection: Package names matter

Android clients normally display installed applications rather than individual web domains. Selecting a browser means that traffic generated by that browser may use the chosen route, but it does not guarantee that every other app opened through the browser’s share sheet will follow the same path. A media app may also use a separate download process, account component, or system browser for authentication.

Start with one application and its clearly required companion. Do not add a large group before testing, because a large rule set makes it difficult to identify the cause of a failure. After the target app works, add another app only if there is a demonstrated need. This approach also makes battery and data behavior easier to observe.

Be careful with duplicate entries. Android may show a normal app, a work-profile copy, a cloned app, or a manufacturer-specific version with a similar display name. The package installed in a work profile can behave as a different application from the personal-profile copy. If the client shows package details, compare the entry with the profile where the app is actually installed.

Rule selection also interacts with Android’s “always-on VPN” and “block connections without VPN” options. Those system settings are designed for a stronger full-device policy. If you intend to let non-selected apps use the direct connection, a kill-switch-style block may conflict with that design and make direct applications appear offline. Decide whether your priority is selective routing or preventing all traffic outside the tunnel; do not enable both without understanding the consequence.

Set Up Split Tunneling: A repeatable Android procedure

The following process is deliberately conservative. Menu names differ between Android versions and clients, but the order remains useful. If you have not installed a compatible client or imported a subscription before, the setup tutorial can be used as a separate reference. The exact protocol options shown after import depend on the client and the subscription format.

1. Prepare the profile. Install a trusted Android client that supports the subscription format and protocols you need. Import the complete subscription link, refresh the profile, and confirm that the expected nodes are visible.
2. Choose one node. Select a node with a clear name and connect without changing advanced routing options first. Confirm that Android grants the VPN permission and that the client reports an active connection.
3. Open application rules. Look for per-app proxy, split tunneling, app routing, or a similar setting. Identify whether the screen is an allowlist, a bypass list, or a full-device mode.
4. Choose the target app. In allowlist mode, select only the first app you want to test. In bypass mode, select only the apps that must remain direct. Save the rule and reconnect if the client asks for it.
5. Check DNS behavior. Review whether DNS is handled by the client, sent through the selected route, or left to the local network. Per-app routing does not always create per-app DNS routing, so a domain lookup can follow a different path from the final connection.
6. Test the target. Open the selected app, sign in if appropriate, load its main content, and perform the action that originally required the VPN. Leave the app, return to it, and check whether it still works after the client moves into the background.
7. Test a direct app. Open an application that was not selected. Confirm that its expected local behavior remains available, such as access to a local device or a service that should not use the VPN.
8. Save the working state. Note the rule mode, selected applications, node, DNS choice, and Android battery setting. This record is more useful than relying on memory after a future profile refresh.

Do not change the protocol, node, rule mode, DNS, and battery policy all at once. If the first test fails, you need to know which layer changed. A practical sequence is to confirm a full-device connection, then enable split tunneling, then adjust DNS, and only afterward compare another node or protocol. Shadowsocks, VMess, Trojan, and VLESS are not interchangeable configuration labels, while Hysteria2 and WireGuard have their own transport and implementation requirements. The client must support the selected profile rather than merely display its name.

Subscription refreshes deserve special attention. A refreshed profile can add, remove, or rename nodes without necessarily changing the Android app rules, but some clients create a new profile instead of updating the old one. After a refresh, verify that the intended profile is active and that the application list still belongs to it. Do not assume that a successful update preserved every local routing option.

Test the Rules: Verify both routed and direct traffic

A reliable test uses contrasting applications. The selected app should demonstrate the expected VPN behavior, while an unselected app should demonstrate direct behavior. Testing only the target app is incomplete because a misconfigured bypass rule can still route the entire phone through the VPN.

Use a network-check page or the service’s own connection diagnostics to compare the selected app and a direct app, but interpret results carefully. An exit address observed in one browser does not prove that every Android process uses the same route. Likewise, a successful DNS lookup does not prove that the subsequent application connection followed the same path. The most useful test is tied to the actual app and action you need.

Android may display a VPN icon even when an application rule is wrong. The icon indicates that a VPN interface exists, not that the selected package is using the intended node. Also check whether the client shows transferred traffic, whether the profile is active, and whether the rule list is attached to the current profile rather than an older one.

Troubleshoot and Roll Back: Isolate one layer at a time

If the selected app cannot connect, first disable split tunneling temporarily and test the same node in full-device mode. If the app works in full-device mode, the node and basic protocol are probably usable, and the problem is more likely to be the package selection, rule direction, DNS handling, or a required companion process. If it fails in both modes, investigate the profile, protocol support, node, network environment, or client permission.

If an unselected app cannot connect, check whether the client is using bypass mode when you intended an allowlist, or vice versa. Then inspect Android’s always-on VPN and block-without-VPN settings. A direct app can also fail because it depends on a domain or authentication component that is being routed differently from the app you selected.

If the configuration stops working after the screen is locked, review the client’s battery setting. Android manufacturers may place VPN clients into aggressive power-saving states. Allow the client to run in the background according to the device’s battery-management options, keep its notification visible when the client requires a foreground service, and avoid force-stopping it. A permanent notification is often a sign that the client is maintaining an active foreground service rather than evidence of a problem.

After switching networks, wait for the client to establish a new session before judging the rule. If the status remains connected but the selected app has no traffic, disconnect and reconnect once. When repeated recovery is required, check whether automatic reconnection is enabled and whether another client or system profile is competing for the VPN interface.

• ✅ First compare full-device mode with split-tunnel mode.
• ✅ Confirm that the current profile, not an old imported profile, contains the rule.
• ✅ Recheck Android VPN permission after clearing app data or reinstalling the client.
• ✅ Test DNS separately from the application’s final connection.
• ✅ Reconnect after changing networks before changing several advanced settings.
• ❌ Do not delete the only working profile before exporting or recording its settings.
• ❌ Do not treat one failed app as proof that every node or protocol is unusable.

For a safe rollback, turn off the application rule first and return to full-device or direct mode, depending on the state that was known to work. Disconnect the VPN, verify that Android no longer shows the VPN indicator, and test the phone’s normal connectivity. If the client created a system VPN profile that remains active, remove or disable that profile through Android’s VPN settings. Only then remove the imported profile or reinstall the client.

Keep a minimal fallback profile with one known-compatible node and no complicated application rules. This makes future diagnosis faster: if the fallback connects, the issue is likely in the rule set or advanced options; if it does not, the problem is broader than split tunneling. For users who need richer routing logic than Android’s package-level controls provide, a compatible sing-box or other advanced client may expose domain, IP, DNS, and protocol policies, but greater flexibility also creates more opportunities for conflicting rules. Use the simplest policy that satisfies the actual requirement.

The most maintainable Android setup is usually small: one compatible client, one active profile, one clearly understood rule mode, and a short list of applications. Add packages only when testing shows that they are needed. Recheck the rules after subscription updates, Android system changes, and network changes. If you need a different route, review the available global nodes; if you need a new client or subscription workflow, return to the setup tutorial rather than rebuilding every setting from memory.

In practice, split tunneling works best when each decision is observable. Define which apps should be proxied, identify which must stay direct, verify DNS and network recovery, and preserve a rollback configuration. This turns Android per-app VPN control from a trial-and-error switch into a predictable routing policy that can be adjusted without losing the rest of the phone’s connectivity.