Android split tunneling lets you decide which applications use a VPN tunnel and which applications continue through the normal network. This is useful when only selected services need a different network path, while local banking apps, smart-home tools, work resources, or nearby devices should keep using the direct connection. It can also reduce unnecessary routing, but it adds another layer of troubleshooting: the result depends on the VPN client, Android’s VPNService behavior, DNS handling, IPv6 support, and the way each application opens its connections.
The most important point is that “split tunneling” is not one universal Android feature with identical controls everywhere. Some official VPN clients provide an app exclusion list, some provide an inclusion list, and some expose both modes. Compatible clients based on protocols such as WireGuard, OpenVPN, Shadowsocks, VMess, Trojan, or Hysteria2 may implement application rules differently. Before changing settings, identify whether your client routes selected apps through the tunnel, bypasses selected apps, or applies rules only to traffic matching a domain or IP policy.
What Android Split Tunneling Actually Controls
A VPN client on Android normally creates a virtual interface through the Android VPNService API. The system then decides which traffic is presented to that interface, while the client encrypts and sends the selected traffic to a remote entry point. With split tunneling, the client adds application-based rules to that decision. Depending on the mode, the rule may mean “only these apps use the VPN” or “all apps use the VPN except these apps.” The visible app list is therefore only the starting point; routing and name resolution still need to be checked separately.
3
Common rule modes: all, selected, excluded
5
Android platforms supported by HBVPN
90+
Countries available for route selection
200+
Lines available across locations
Include Mode and Exclude Mode
In include mode, only the applications you select are sent through the VPN. This is usually the safer starting point for testing because the scope is small and obvious. A browser, streaming application, or AI tool can be selected while the rest of the phone continues on its regular network. The limitation is that supporting components may not be included automatically. For example, an application may open a web login in a separate browser, use a system download service, or rely on a companion process that is not represented by the main app entry.
In exclude mode, the VPN covers most applications and the selected apps bypass it. This is convenient when nearly everything should use the tunnel, but it can produce surprising results. Excluding a browser does not necessarily exclude every browser-based component, and an application that uses a custom networking library may behave differently from another app. Exclude mode also makes it easier to overlook background traffic that remains protected by the VPN.
Per-App Rules Are Not Domain Rules
An application rule normally identifies traffic by the Android package associated with the application. It does not always distinguish between individual domains visited inside that app. If a social application contacts several service domains, the package rule commonly affects all of them. Conversely, a browser rule may send many unrelated websites through the same path because Android sees one browser package rather than the individual tabs.
Domain-based routing is a separate feature usually provided by advanced clients or rule engines. A sing-box or Clash-compatible configuration may support domain, IP, geolocation, or process-related policies, but the Android client must actually implement those policies. Do not assume that importing a subscription automatically gives you application rules. Subscription import generally supplies server or proxy information; routing behavior is controlled by the client profile and its Android permissions.
Prepare Your Android Client Before Changing Rules
First update the VPN client through its official distribution channel and confirm that the profile is valid. If you use an official HBVPN client, obtain the supported Android version from the service’s normal download or setup flow. Compatible clients such as Clash Verge are generally associated with desktop environments, while Android users should choose an Android-compatible client that explicitly supports the imported subscription format. A configuration that works in one client may expose different rule controls in another.
Open the Android system VPN permission prompt when the client requests it. Android normally displays a warning that the VPN can monitor or control network traffic. This is expected for a VPNService-based application, but you should verify the application publisher and only approve a client you trust. Also check whether another VPN application is already active. Android generally allows only one VPNService connection to control the device at a time, so two competing clients can cause a misleading failure.
Record the current state before editing anything. Note the selected server or region, protocol, DNS option, always-on setting, and whether “block connections without VPN” is enabled. Take a screenshot of the existing application rule if the client supports it. If the new rule behaves unexpectedly, restoring the previous state will be much faster than trying to remember every switch.
- ✅ Confirm the client is Android-compatible and has the required VPN permission
- ✅ Disconnect other VPN, firewall, or traffic-filtering applications before testing
- ✅ Record the current server, protocol, DNS, IPv6, and kill-switch settings
- ✅ Start with one foreground app instead of selecting an entire category
- ❌ Do not assume a subscription import also imports per-app routing behavior
- ❌ Do not enable Always-on VPN and block-without-VPN during the first test unless you understand the consequence
Choose a Useful Test Application
Pick an app whose network behavior you understand and whose result is easy to compare. A browser is useful for checking the visible public IP and DNS, but it can hide background traffic and may cache results. A media or AI application can show whether the required route is being used, although service availability also depends on account and platform rules. A local-device application, such as a printer or smart-home controller, is useful for verifying that the bypass side still reaches devices on the local network.
Do not test only by opening the app. Android may keep an existing connection alive, and the app may display cached content. Force-stop the app, reconnect the VPN, and open it again. If the client has a “reconnect” or “reload configuration” control, use it after changing rules. Some clients apply changes immediately; others apply them only after the tunnel is restarted.
Step-by-Step Android Split Tunneling Setup
The names of menus vary by client, but the workflow is broadly similar. The following process is designed to make each change observable and reversible rather than treating the rule list as a collection of switches.
Step 1: Open the Routing or Per-App Settings
Connect to the VPN client and look for a menu named Split tunneling, Per-app VPN, Application routing, App proxy, or Bypass apps. In a protocol-focused client, the option may be inside the active profile rather than in the main connection screen. If you imported a profile, edit the profile that is actually selected; changing an unused profile will have no effect on the current tunnel.
Read the explanation beside the mode selector. “Selected apps,” “VPN apps,” and “Proxy only” commonly indicate inclusion behavior, but labels are not standardized. If the interface uses wording such as “exclude selected apps,” treat it as bypass mode. When the meaning is unclear, select one harmless test app and verify the public IP before adding more applications.
Step 2: Select Inclusion or Exclusion Mode
For a focused setup, choose inclusion mode and add the application that needs the alternate route. If your goal is to keep most traffic protected while allowing a few local or work applications to use the direct path, choose exclusion mode instead. Avoid switching modes repeatedly while troubleshooting, because a change from inclusion to exclusion can make the same app appear to work for the opposite reason.
Search the list by package or application name. Some clients show duplicate entries for the same vendor, separate work-profile copies, or system components. Select the exact installed app you intend to test. If an application has a personal and a work-profile copy, configure the copy you actually open. Android treats those profiles as separate application identities for many VPN rules.
Step 3: Restart the Tunnel and the Application
Save the rule, stop the VPN tunnel, and start it again. Then force-stop the test app from Android’s app settings or recent-apps screen before reopening it. This clears connections that were created under the previous routing state. If the client supports a configuration reload without disconnecting, still restart the application because existing sockets may remain attached to the earlier path.
Test both sides of the rule. The selected app should follow the intended VPN route, while an excluded or unselected app should follow its intended direct or alternate route. A single browser window is not enough evidence if the browser is the selected app; test a second application with a different rule status as well.
Step 4: Check IP, DNS, and Local Access
Check the public IP from the selected app and from an app that should bypass the tunnel. If both show the same result, the client may be using full-device routing, the rule may not have been applied, or the test app may be using a connection that was not restarted. If neither app works, inspect the protocol, server availability, Android permission, and kill-switch state before changing the application list again.
DNS deserves a separate check. A VPN may route application traffic through the tunnel while DNS requests use the system resolver, or it may force all DNS requests through the VPN regardless of the application rule. This behavior differs by client. Private DNS, encrypted DNS inside the application, and DNS-over-HTTPS in a browser can also bypass the client’s expected resolver path. If a service detects the wrong region or a domain fails to resolve, compare the client’s DNS setting with Android’s Private DNS setting and the app’s own secure-DNS option.
Finally, test local access. If the bypassed app must reach a device on your home or office network, confirm that local addresses remain reachable. Some clients enable a setting such as “allow LAN traffic,” while others block local traffic when the VPN is active. Enabling LAN access can solve printer or router-management problems, but it also changes the security boundary, so use it only when needed.
| Observation | Likely Area to Check | Next Action |
|---|---|---|
| Selected app shows the direct public IP | Rule mode, profile selection, or stale connection | Confirm inclusion mode, reload the active profile, and force-stop the app |
| Excluded app cannot connect | Kill switch, direct-network restriction, or Android system policy | Review block-without-VPN and bypass settings, then test after disconnecting |
| Websites open but region detection is wrong | DNS path, browser secure DNS, or exit-IP classification | Compare DNS settings and verify the public exit location |
| Local printer or device is unreachable | LAN access or private-network routing | Enable the client’s LAN option only if the local service requires it |
| Connection works until the screen locks | Battery optimization or background restrictions | Allow the VPN client to run in the background and test again |
Fine-Tune DNS, Protocols, and Background Traffic
Once the basic application rule works, review the traffic that the app creates beyond ordinary HTTPS. Many modern applications use HTTP/3 over QUIC, which is carried over UDP. A client or network that handles TCP reliably may treat UDP differently. If the selected app repeatedly reconnects, loads text but not media, or shows unstable behavior, check whether the client offers UDP support or a protocol preference. Do not change several protocol settings at once; otherwise you will not know whether the improvement came from the app rule or the transport change.
IPv6 is another possible source of inconsistent results. If the VPN covers IPv4 traffic but does not correctly handle IPv6, an application may reach part of a service through a different path. This can look like a random DNS or region problem. Check whether the client supports IPv6 tunneling, whether Android is receiving an IPv6 address on the current network, and whether the client provides an IPv6 leak-prevention option. Disabling IPv6 at the device or router level is not always appropriate, so prefer the client’s documented handling when available.
Background traffic can complicate app-based rules. Notifications, analytics, account synchronization, downloads, and embedded web views may connect when the main screen is closed. If the application appears to use the desired route in the foreground but reports a session error later, inspect Android battery restrictions, background data permission, and the client’s application list. A work-profile copy or companion app may need its own rule. On the other hand, adding every system component to the VPN list can create a much broader tunnel than intended.
When using an advanced rule client, distinguish between a global mode, rule mode, and system proxy mode. A global mode often sends all proxy-capable traffic to one outbound route. Rule mode evaluates domains or IPs according to a configuration. System proxy mode may affect applications that honor Android proxy settings but not applications that open their own sockets. A per-app VPN rule at the Android VPNService layer and a domain rule inside the proxy core can work together, but their order matters. Confirm which layer makes the final decision.
Common Failures and Safe Recovery
The Application Does Not Appear in the List
Refresh the application list, restart the client, and check whether the app is installed in a work profile or secondary user profile. Some VPN clients hide system applications or only list packages that can be routed through their current mode. If the application is delivered as a web wrapper or uses a companion service, selecting the visible icon may not cover every related process. In that case, consult the client’s documentation rather than selecting random system packages.
The Selected Application Has No Network
First confirm that the VPN itself works in full-device mode. If full routing also fails, inspect the selected server, protocol, authentication, and Android VPN permission. If full routing works but inclusion mode fails, the application may depend on a service that was not selected, or the client may have a compatibility issue with that app. Temporarily use a simple browser test, then add the target app again. Avoid disabling security features permanently merely to make one application connect.
The Bypassed Application Still Uses the VPN
Check whether the client defines bypass as “exclude from proxy” rather than “exclude from VPN.” In some products, the app bypasses the proxy core but remains inside the Android VPN interface. The public IP may therefore remain the VPN exit even though the app is not processed by the same rule engine. Also check whether Always-on VPN or block-without-VPN is enforcing a device-wide policy. Android system settings can override the user’s expectation of a simple app exclusion.
The Rule Breaks After Wi-Fi or Mobile Data Changes
Switching between Wi-Fi and mobile data can recreate the VPN interface and alter DNS, IPv6, or captive-portal behavior. Reconnect the tunnel, reopen the selected application, and test each network separately. Battery optimization may also suspend the VPN client when the phone is idle. Granting the client suitable background permission can improve persistence, but it may increase battery use. Keep the rule list small so that a reconnect is easier to diagnose.
- ✅ Test on Wi-Fi and mobile data as separate network conditions
- ✅ Reconnect after changing the active profile or protocol
- ✅ Check both selected and bypassed applications
- ✅ Review Android Private DNS, battery optimization, and Always-on VPN
- ❌ Do not treat a cached webpage as proof that the current route is active
- ❌ Do not add unknown system packages as a first response to a connection failure
Privacy and Security Considerations
Split tunneling creates two network paths. Applications using the VPN are handled according to the VPN client’s tunnel and DNS policy, while bypassed applications may expose their connections to the local network, mobile operator, or ordinary ISP path. This may be exactly what you want for local services, but it is not a neutral change. If a bypassed application handles sensitive account data, confirm that its own encryption and security controls are adequate.
A VPN does not make every application anonymous, and it does not replace account security. Applications can still identify users through login details, device identifiers, cookies, advertising IDs, and behavior. Split tunneling also does not remove platform restrictions or authorize access to content that your account or region is not permitted to use. Follow applicable law, service terms, and organizational policies when deciding which applications should use each path.
Consider whether the kill switch matches your goal. A block-without-VPN policy can prevent selected traffic from falling back to the direct network if the tunnel disconnects, but it may also stop bypassed apps from working. If uninterrupted local access is more important than strict tunnel enforcement, an always-on block may be unsuitable. If protection against accidental direct transmission is the priority, test the failure behavior before relying on it.
How to Revert and Maintain the Configuration
To return to a simple full-device setup, open the client’s application-routing menu and choose the default mode, remove all inclusion and exclusion entries, or disable split tunneling. Save the profile, reconnect the tunnel, and force-stop the apps that were previously tested. Then review Android’s system VPN settings and remove an Always-on or block-without-VPN policy only if you no longer want it. Finally, restore the DNS, IPv6, and LAN settings you changed during testing.
If the client has become difficult to diagnose, export or note the current profile before resetting it. A clean profile can reveal whether the issue comes from a complicated rule set or from the underlying connection. Re-add applications one at a time. Keep a short record of the intended behavior, such as “browser through VPN, local printer direct, banking app direct,” rather than relying on memory of symbols in the client interface.
Review rules after installing a new application, creating a work profile, changing the Android version, or switching VPN clients. Package names and available controls can change, and a newly installed application may not inherit the behavior you expect. A periodic check is especially useful when a service changes its DNS, transport, or login flow. The goal is not to create the most elaborate configuration, but to keep the routing decision understandable.
Android Split Tunneling FAQ
Does split tunneling route only one app through the VPN?
It can, if the client provides inclusion mode and the application is selected. However, supporting services, browser-based login windows, and work-profile copies may use separate package identities. Test the complete workflow instead of assuming that selecting one icon covers every connection related to that service.
Will DNS automatically follow the same app rule?
Not always. DNS may be handled by the VPN client, Android Private DNS, the application itself, or a browser’s secure-DNS feature. Check the client’s documented behavior and compare DNS settings when an IP-based test appears correct but region detection or domain resolution remains inconsistent.
Can I use local printers or smart-home devices while the VPN is active?
Often yes, but the client may need an “allow LAN traffic” option. The exact behavior depends on the Android network, client, and local address range. Enable local access only when required and verify that the VPN still protects the applications intended to use it.
What should I do if nothing connects after enabling the rules?
Return temporarily to full-device routing or disable split tunneling, reconnect the VPN, and confirm that the base profile works. Then add one application in inclusion mode and test again. If the problem returns, inspect the active profile, Android VPN permission, DNS, protocol support, battery restrictions, and Always-on or kill-switch settings before building a larger rule set.
For platform-specific client instructions and subscription import guidance, consult the setup guide. A careful Android configuration should remain easy to explain, easy to test, and easy to undo: begin with one application, verify the route and DNS behavior, document the result, and expand only when the earlier rule is stable.