Android Split Tunneling Guide: Set App Rules the Right Way

Android split tunneling is the practical way to decide which apps use a VPN tunnel and which apps continue using the ordinary network. Instead of treating the phone as one undivided connection, you create app-specific rules: a browser, streaming app, or work tool can use a selected VPN route, while banking, local services, or an app that rejects proxy traffic can stay outside the tunnel.

The feature sounds simple, but the result depends on several layers working together. The Android VPN service controls the system tunnel, the VPN client interprets your include or exclude list, the imported subscription determines available nodes and protocols, and Android battery controls may stop the client from maintaining its connection in the background. A rule that looks correct can still appear broken if the app is using a second process, if “always-on VPN” overrides the expected behavior, or if the selected route cannot reach the app’s servers.

What Android split tunneling actually controls

In a full-tunnel profile, the client attempts to send most system traffic through the VPN interface. In an app-based split-tunnel profile, the client changes that decision according to package names registered by Android. Depending on the client, you may see two common modes:

• Include selected apps: Only the apps on the list use the VPN. Everything else remains on the normal network.
• Exclude selected apps: Most apps use the VPN, except those placed on the bypass list.

These modes are not interchangeable. Include mode is usually easier to audit because the tunnel has a narrow scope. It is useful when only a few apps need a different route. Exclude mode is more convenient when most of the phone should use the VPN and only a few local or incompatible apps need direct access.

App rules are different from domain-based routing. An app rule normally identifies the Android application, not every website or destination that the application contacts. A single app may connect to several domains, content delivery networks, authentication services, analytics endpoints, and update servers. If you route the app through the tunnel, all of those requests may follow the same app-level decision unless the client provides an additional domain, IP, or rule-set layer.

There is also an important difference between the VPN tunnel and the client’s proxy mode. A client using Android’s VPNService can apply app rules at the operating-system level. A local HTTP or SOCKS proxy may require each app to support proxy settings, and many Android apps do not expose such controls. If the client offers both modes, verify which mode is active before diagnosing a routing problem.

Understand application boundaries before creating rules

Android can treat an application package as the unit of selection, but the visible app name is not always the complete picture. Some products separate the main app, media player, login helper, download component, or work-profile copy into different packages. A browser may also open links in a custom tab handled by another package. This is why an app that appears to be selected may still show mixed behavior.

Work profiles and cloned applications deserve special attention. The personal copy and work-profile copy can appear as separate entries, and selecting one does not necessarily select the other. If a client lists duplicate names, use the Android icon and profile indicator to distinguish them. Avoid selecting every similarly named package until you know which process needs the tunnel.

Choose the right routing mode and client

The exact labels vary between official Android clients and compatible clients such as Clash Verge on supported desktop environments, sing-box-based Android clients, or Shadowrocket on Apple platforms. On Android, use an Android-compatible client that implements app routing through the system VPN interface. The menu may be called Split tunneling, Per-app VPN, App rules, Bypass apps, or Route apps. The wording is less important than the behavior described by the mode.

Before editing rules, import a valid subscription or configuration through the client’s supported workflow. Depending on the service and client, the profile may expose Shadowsocks, VMess, Trojan, Hysteria2, or WireGuard options. These are not interchangeable labels: Shadowsocks is an encrypted proxy protocol, VMess and Trojan are commonly used in proxy-oriented configurations, Hysteria2 is designed around QUIC-based transport, and WireGuard is a VPN protocol with its own tunnel configuration. Whether an Android client supports a given protocol depends on the client build and the supplied profile.

Do not change the protocol, node, DNS mode, and app list at the same time. If several variables change together, you will not know which change fixed or caused the result. First make the profile connect with a simple route. Then configure app selection. Only after that should you compare another node or protocol.

For a first configuration, select a route that is geographically reasonable for the service you are testing and avoid switching repeatedly during the same test. A route can be technically connected while a particular app still fails because of regional policy, server-side filtering, DNS resolution, or protocol compatibility. Split tunneling decides which interface the app uses; it does not guarantee that every destination will accept the resulting connection.

Set up Android app rules step by step

The following workflow is intentionally conservative. The names of buttons may differ, but the sequence applies to many Android VPN clients that support per-app routing.

1. Update the client and open the active profile. Confirm that the profile is complete and that the client can display available routes. If the profile was imported from a subscription, refresh it before troubleshooting an app rule.
2. Connect without split tunneling. Establish a normal tunnel first. Check that the client reports a connected state and that a simple browser test works. This separates a basic connection problem from an app-selection problem.
3. Open the app-routing section. Look for Split tunneling, Per-app VPN, or a similar setting. Read the description carefully to determine whether the list is an allowlist or a bypass list.
4. Select one application. In include mode, add the app that should use the VPN. In exclude mode, add an app that should remain direct. Do not select system packages unless the client documentation specifically explains them.
5. Save the rule and reconnect. Some clients apply changes immediately; others require the tunnel to be stopped and started. If Android displays a VPN permission prompt, review it and accept only if you recognize the client.
6. Force a clean application test. Close the target app from the recent-apps screen, reopen it, and repeat the action that previously failed. This prevents an old socket or cached connection from making the rule appear ineffective.
7. Test an app outside the rule. Open a second app that was not selected. The purpose is to verify the boundary, not merely to confirm that the selected app can load.
8. Add rules gradually. Once the first app behaves as expected, add related apps one at a time. Record the purpose of each rule so that a future reset does not require guessing.

After saving the list, check whether the client has separate switches for IPv6, DNS, local network access, or bypassing private networks. These settings can change what “direct” means. For example, an app may reach one service over IPv4 through the tunnel but use an IPv6 path outside it if the client does not handle IPv6 consistently. A local-network bypass may be useful for printers and home devices, but it should not be confused with app-level exclusion.

It is also worth checking the client’s rule priority. Some profiles evaluate app rules before destination rules, while others apply a global mode first and app selection afterward. If the interface offers a rule order, keep the configuration readable: place broad rules before narrow exceptions only when the client’s documentation confirms that later rules override earlier ones.

Test each route without guessing

A connected badge is not enough evidence. It tells you that the VPN interface is active, not that every selected app is using the intended route or that every excluded app is bypassing it. Test one behavior at a time and compare the selected app with an unselected app.

• ✅ Confirm the selected app opens after the tunnel reconnects.
• ✅ Confirm an unselected app still behaves according to the intended direct or tunnel route.
• ✅ Test both a foreground action and a background refresh when the app depends on notifications.
• ✅ Recheck after switching between Wi-Fi and mobile data.
• ✅ Check whether a work-profile or cloned copy needs its own rule.
• ❌ Do not use only one website or one loading screen as proof of routing.
• ❌ Do not conclude that a route is broken before testing another supported node or protocol.
• ❌ Do not enable several VPN clients while comparing results.

For a browser, test page loading, sign-in, and a resource hosted by the service you actually care about. For a streaming app, test account access and playback separately; the login endpoint and media delivery endpoint may behave differently. For a work application, verify authentication, file access, and notifications while respecting the organization’s network policy. For a banking or payment application, avoid changing routing during a transaction and use the provider’s recommended network conditions.

If the selected app works only after being opened again, Android may have retained an old connection before the rule changed. If it stops working after the screen turns off, background restrictions are a more likely cause than the app list. If both selected and unselected apps follow the same route, inspect whether the client is in full-tunnel mode or whether the profile ignores app rules.

Tune battery, always-on VPN, and DNS settings

Android power management can suspend a VPN client when it is idle, especially on phones with aggressive manufacturer-specific battery policies. The symptoms may include a connection that disappears after the screen is off, delayed notifications, or an app that works immediately after opening the VPN client but fails later. Open the Android battery settings for the VPN client and review background activity, battery optimization, and auto-start permissions. The available controls depend on the phone manufacturer and Android version.

Do not disable every battery safeguard automatically. A better approach is to allow the client to maintain its tunnel only if your use case needs persistent routing. If the tunnel is needed for occasional browsing, manually reconnecting can be simpler and use fewer resources. If notifications or background synchronization are important, test the phone after the screen has been locked and after the device has changed networks.

Always-on VPN is a separate system feature. It can reconnect the selected client automatically, but it may also change how exclusions behave. The Block connections without VPN option is even stricter: it can prevent direct traffic when the VPN is unavailable. That may be desirable for a privacy-focused profile, but it can also stop excluded apps from connecting directly and may interfere with local-network access. Enable it only after you understand the failure mode and have a recovery path through Android settings.

DNS settings deserve the same caution. A VPN client may send DNS requests through the tunnel, use a configured resolver, or allow the operating system to resolve some names directly. An app that loads its main page but fails on login, images, or media may be encountering a DNS or endpoint-selection issue rather than a simple app-rule error. Change DNS behavior only after the basic app list has been verified. If a profile supports domain-based rules in addition to app rules, document which layer is responsible for each decision.

Troubleshoot failures and restore the default profile

When an app refuses to connect, begin with the least destructive checks. Confirm that the subscription or configuration has not expired, refresh the profile, and reconnect using the original route. Then remove the app from the split-tunnel list temporarily and compare the result. If the app works in full-tunnel mode but not in the split configuration, the rule mode, DNS path, local-network setting, or application boundary is likely involved.

Some apps reject connections from particular network ranges or behave differently when their authentication and content requests use different exits. A selected app may also launch an external browser, system web component, or media handler that is not selected. In that situation, adding every system component is not automatically the right fix. Identify the handoff first, then test the smallest additional rule that addresses it.

Use this recovery order:

1. Stop the VPN connection and close the affected app.
2. Return the app mode to the client’s default profile, or temporarily disable split tunneling.
3. Reconnect with the original route and test the app again.
4. Refresh the imported subscription if the route list or credentials appear incomplete.
5. Try another supported route only after confirming that the default profile is functioning.
6. Recreate the app rule with one application and one clear mode.

Keep a written note of the working state: routing mode, selected apps, DNS choice, always-on status, and battery permission. This is more useful than taking a screenshot of a long list with no explanation. If the client offers export or backup for local settings, use its built-in function and protect the resulting configuration because it may contain access credentials.

A full reset is appropriate when rules have become contradictory, the client was migrated between profiles, or Android keeps applying an old VPN state. Disconnect the tunnel, disable always-on and blocking options if they prevent access to the client, clear only the relevant app settings, and import the known-good profile again. Avoid clearing all phone network settings unless necessary, because that can remove saved Wi-Fi networks and other device preferences.

• ✅ Keep a minimal default profile that can be restored quickly.
• ✅ Name or document profiles by purpose, such as testing, work, or general browsing.
• ✅ Recheck rules after an Android system update or client migration.
• ❌ Do not stack a system VPN, a second VPN client, and a manual proxy during diagnosis.
• ❌ Do not assume that uninstalling an app removes every related work-profile or cloned-app rule.

The best Android split-tunneling setup is not the one with the longest application list. It is the one whose scope you can explain, test, and restore. Start with include mode when only a few apps need the tunnel, use exclusions when most traffic should follow the VPN, and treat always-on, DNS, and battery settings as separate decisions. If you need help importing a supported profile or installing the client, see the setup guide before expanding the rule set.