Android Split Tunneling Guide: Set App Rules Easily

Android split tunneling lets you decide which apps use the VPN tunnel and which apps continue through the ordinary network connection. That sounds simple, but the result depends on several layers working together: the Android VPN permission, the client’s app-routing mode, DNS handling, battery management, and sometimes an “Always-on VPN” rule imposed by the operating system. A good setup is not merely “VPN on” or “VPN off.” It is a deliberate traffic policy that keeps selected apps on a protected route while leaving local services, banking apps, games, or high-bandwidth downloads on the normal connection when appropriate.

This guide explains how app-based split tunneling works on Android, how to configure it step by step, how to test every rule instead of assuming it works, and how to repair common routing problems without deleting your entire VPN profile. The instructions apply broadly to official Android clients and compatible clients that support subscription imports, including clients built around WireGuard, Shadowsocks, VMess, Trojan, or Hysteria2. The exact button names vary by app, but the decision process remains the same.

How Android Split Tunneling Works

When an Android VPN client connects, it creates a virtual network interface through Android’s VpnService framework. The client then decides which application traffic enters that interface. Split tunneling adds a second decision layer: instead of sending every app through the tunnel, the client matches traffic against an app list and applies either an include rule or an exclude rule.

• Include mode or allowlist mode: only the apps you select use the VPN. Every other app stays on the ordinary connection.
• Exclude mode or bypass mode: most apps use the VPN, while the apps you select bypass it and connect normally.
• Per-app VPN mode: some clients present this as a dedicated “Apps using VPN” screen, while others place it under routing, connection, or advanced settings.
• Global mode: all eligible application traffic is sent through the tunnel, with no app-level exception unless the client separately supports bypass rules.

The most important point is that split tunneling is normally an application-routing feature, not a special property of a particular protocol. WireGuard may carry the tunnel, while the Android client decides which applications are assigned to that tunnel. The same principle applies when the client uses Shadowsocks, VMess, Trojan, or Hysteria2. Changing the protocol can improve compatibility or stability, but it will not automatically create correct app rules.

There are also two different meanings of “bypass” in Android clients. In one client, bypass may mean “do not send this app through the remote VPN server.” In another, it may mean “exclude this app from the local VPN interface but still process its DNS through the client.” Those behaviors can produce different results for region detection, private DNS, and captive portals. Read the wording around the switch carefully, and test the application after every meaningful change.

Choose the Right App-Routing Mode

There is no universally correct split-tunneling mode. The right choice depends on whether you want a small group of apps to use the VPN or whether you want most traffic protected with only a few exceptions.

When Include Mode Is Better

Include mode is usually easier to audit when only a few applications need the tunnel. You might select a browser, an AI application, a streaming application, and a work tool, then leave everything else alone. This minimizes unintended routing changes and often reduces battery and data usage because background applications do not automatically enter the tunnel.

Include mode is also useful when local services must remain reachable. A smart-home controller, printer application, local NAS client, or domestic payment application may behave better on the ordinary connection. By placing only the required apps in the VPN list, you avoid changing the network path for applications that were never meant to use the remote route.

When Exclude Mode Is Better

Exclude mode makes more sense when nearly all applications should use the VPN and only a small number should bypass it. For example, you may want browsers, messaging clients, software updates, and cloud tools to use the tunnel while excluding a local banking app or a game that depends on nearby servers.

The drawback is maintenance. New applications may automatically inherit the VPN path, and an app that you forgot to exclude can unexpectedly appear from the VPN exit region. Some clients also treat system components differently from user-installed applications, so a rule that looks complete may not cover the browser’s WebView, a download manager, or a companion service.

• ✅ Use include mode when only a small, clearly defined group needs the VPN.
• ✅ Use exclude mode when most applications should use the tunnel and only a few need a direct route.
• ✅ Keep the rule list short enough to review after an Android update or client upgrade.
• ❌ Do not assume a selected app covers every related system process or companion app.
• ❌ Do not enable “block connections without VPN” until you understand how it affects bypassed applications.

For a first setup, include mode is generally less surprising. Start with one or two applications, confirm their behavior, then add more. Once the routing policy is understood, you can switch to exclude mode if that better matches your daily use.

Step-by-Step Android Setup

The following procedure is designed to work across official Android clients and compatible clients with an imported subscription. The labels may be “App proxy,” “Per-app VPN,” “Application routing,” “Split tunnel,” “Bypass apps,” or “VPN apps,” but the underlying sequence is similar.

1. Import or verify the profile first. Open the VPN client and confirm that the subscription or profile is present. If you use a subscription link, update the profile before changing app rules so that a later profile refresh does not overwrite an incomplete configuration.
2. Connect once in global mode. Before creating exceptions, confirm that the base profile can connect. Android should display the VPN key or VPN status indicator. If the basic connection fails, split tunneling is not the first problem to solve.
3. Open the routing settings. Look under Settings, Connection, Network, Routing, or Advanced. Find the section that refers to applications rather than domains or IP addresses.
4. Select the operating mode. Choose include mode if only selected apps should use the VPN. Choose exclude mode if most apps should use it and a small list should stay direct.
5. Select applications deliberately. Scroll through the list and select the actual apps you intend to route. Check for separate entries such as a browser, a work profile copy, a cloned application, or a companion service.
6. Save and reconnect. Many Android clients apply app rules only when the VPN tunnel is restarted. Disconnect, wait for the VPN indicator to disappear, and reconnect. If the client offers an “apply” button, use it before reconnecting.
7. Test one included app and one bypassed app. Do not test only the application that you selected. A split rule is valid only when the selected app uses the intended route and the unselected app uses the other route.
8. Record the working configuration. Note the mode, selected applications, protocol, and any DNS or kill-switch options. This makes future troubleshooting much faster than rebuilding the profile from memory.

When the client offers both “route selected apps through VPN” and “bypass selected apps,” do not enable both at the same time unless the interface explicitly documents how the combination works. Some clients treat them as mutually exclusive modes; others expose separate toggles that can create confusing precedence rules. If the screen shows a priority order, follow that order. If it does not, use one mode only and keep the policy simple.

Test Every Routing Rule in Practice

A checkbox is not proof that routing works. Android applications may use background services, embedded browsers, push connections, or system resolvers that do not behave exactly like the visible app window. Testing should therefore cover both the application path and the surrounding network behavior.

First, connect the VPN and open an IP-checking page inside an included browser. Confirm that the visible public address and approximate region correspond to the VPN route you selected. Then repeat the same check in a browser or application that is supposed to bypass the tunnel. The result should reflect the ordinary connection. Do not rely on a single application because cached pages, account-level region settings, or an in-app proxy can hide the actual path.

Next, test the application’s main function rather than only its home screen. For a browser, open a new private tab and load a fresh page. For a messaging client, send a test message and receive a reply. For a video application, start playback and seek to another position. For an AI tool, begin a new conversation and keep the connection open long enough to confirm that streaming output remains stable.

Repeat the test after turning the screen off and on again. Some Android devices pause background activity, restart the VPN service, or apply aggressive battery controls after the display sleeps. Also test after switching from Wi-Fi to mobile data. A rule that works on Wi-Fi may appear broken on mobile data because the client has not re-established the tunnel or because the mobile network handles DNS differently.

DNS, System Settings, and Client Conflicts

Many apparent split-tunneling failures are not caused by the app list. They come from settings around the VPN. Android’s system VPN page may contain options such as Always-on VPN and Block connections without VPN. These controls can override the behavior you expected from the client.

Always-on VPN attempts to reconnect the VPN service whenever it stops. This is useful for a policy that should remain active, but it can make testing confusing because a manual disconnect may be followed by an automatic reconnect. Block connections without VPN is stricter: it can prevent bypassed applications from using the ordinary connection at all. If an excluded app suddenly has no network access, check this setting before changing the app list.

Private DNS is another variable. Android may use a system-wide Private DNS provider, while the VPN client may offer its own DNS handling. If the application traffic uses the VPN but DNS requests go directly through the local network, region-sensitive services may show inconsistent results. Conversely, forcing every DNS query through the VPN can make local hostnames or local-device discovery fail. Use one clearly understood DNS policy, then test both public domains and local services.

Only one conventional VPN service can normally control Android’s VPN interface at a time. Running two VPN clients together can cause one client to disconnect, replace the other’s tunnel, or leave the application list attached to the wrong profile. This includes security products that provide their own VPN-based filtering. Disconnect other VPN-style services before diagnosing a split-tunneling rule.

Battery optimization can also terminate a client in the background. If the VPN works while the screen is open but stops after a period of inactivity, allow the client to run in the background according to your device manufacturer’s settings. Do not disable every battery safeguard blindly; make the narrowest exception available for the VPN client, then test again.

Fix Common Split-Tunneling Problems

When one application ignores the rule, change one variable at a time. Start by checking whether the VPN key is visible and whether the client reports an active connection. Then reopen the app or force-stop it so that existing sockets do not continue using the previous route. Some applications keep connections alive for a long time and will not reflect a routing change until they are restarted.

• The selected app still uses the normal connection: confirm that the client is in include mode rather than exclude mode, remove and re-add the app, save the settings, and reconnect the VPN. Check whether the app has a work-profile or cloned duplicate.
• An excluded app has no connection: inspect Always-on VPN and Block connections without VPN. These Android-level settings can prevent direct traffic even when the client’s bypass list is correct.
• Only one service inside the app fails: check whether the app uses a separate WebView, download service, or companion process. Add the related component only if the client exposes it and you understand the privacy implications.
• Local devices disappear: review DNS handling and local-network access options. Some clients intentionally prevent local traffic while the VPN is active; others provide a “allow LAN” switch.
• Rules work until the profile is updated: the imported subscription may replace client-side routing preferences. Export or note the app rules, update the subscription, then verify whether the client preserves local settings.
• The VPN disconnects after screen lock: check battery optimization, background activity limits, and the client’s reconnect setting. Test Wi-Fi and mobile data separately.
• Everything stops when one route fails: review the kill-switch or block-without-VPN behavior. A strict block is intentional protection, but it conflicts with the expectation that bypassed apps should continue directly.

Do not immediately delete the profile or clear all application data. That can remove useful evidence and force you to re-import the subscription. Instead, first capture the current mode, app list, protocol, DNS setting, and Android VPN options. Then temporarily reduce the configuration to one included app and one bypassed app. If that minimal setup works, add applications back in small groups until the conflicting rule becomes visible.

Safe Maintenance and Final Checklist

Split tunneling is a policy, not a one-time switch. Android updates, client updates, work profiles, cloned applications, and subscription refreshes can all change how the rule list behaves. Review the configuration whenever an application is reinstalled, a new profile is imported, or the VPN client changes its routing interface.

• ✅ Keep a short note describing which apps should use the VPN and which should remain direct.
• ✅ Re-test after switching between Wi-Fi and mobile data.
• ✅ Confirm both the included path and the bypassed path instead of testing only the VPN address.
• ✅ Review Android’s Always-on VPN and block-without-VPN options before troubleshooting the client.
• ✅ Check whether subscription updates preserve local app-routing rules.
• ❌ Do not run two VPN-based network services at the same time while diagnosing routing.
• ❌ Do not treat a successful app launch as proof that every background request uses the intended path.

For users who need more control than a simple app list provides, a compatible Android client may offer domain rules, IP rules, policy groups, or protocol-specific profiles. These features are useful when one application needs mixed routing, but they also make mistakes easier. Begin with app-based rules, establish a reliable baseline, and only then add domain or IP exceptions. A client that supports subscription links can simplify node updates, but routing decisions should still be reviewed locally after every refresh.

The most dependable Android split-tunneling setup is the one you can explain clearly: which mode is active, which apps are selected, which DNS path is used, and what happens when the tunnel disconnects. Once those four answers are known, troubleshooting becomes a focused routing check rather than a full reset of the VPN profile.