Android split tunneling lets you decide which apps use a VPN connection and which apps use the ordinary network. This is useful when a full-device VPN affects banking applications, local printers, workplace tools, nearby services, games, or apps that already depend on a regional network. Instead of treating the VPN as an all-or-nothing switch, you can create an app-based routing profile and test the result one application at a time.

The exact menu names vary between Android versions and VPN clients. Some clients call the feature “split tunneling,” while others use “app rules,” “per-app proxy,” “include apps,” or “exclude apps.” The underlying logic is usually one of two models: include only selected apps in the VPN, or exclude selected apps from the VPN while sending the rest through it. Understanding that distinction is more important than memorizing a particular button location.

VPN Split Tunneling on Android: Rules Setup Guide 2026

What Android split tunneling actually changes

A conventional Android VPN creates a system-managed VPN interface. Applications send traffic toward that interface, and the VPN client then applies its routing, DNS, protocol, and node settings. With split tunneling enabled, the client adds per-application decisions to that process. The rule may be based on the Android package installed on the device rather than on a domain name or a web address.

In an include model, only the applications you select are routed into the VPN tunnel. This is often the safer starting point when you need the VPN for one or two work tools, an AI application, a browser, or a streaming service while keeping banking and local-network applications on the regular connection. In an exclude model, every application uses the VPN except the ones on your bypass list. This can be convenient for a device where most traffic should use the same route, but one forgotten exception may continue to use the tunnel.

App-based routing is not the same as domain-based routing. Selecting a browser does not necessarily route every related service in the same way as selecting a specific domain rule. A single application may also contact several domains, use background services, open an external browser, or rely on a separate Android component. Likewise, excluding a shopping or banking app does not automatically exclude every browser session opened from that app.

There is also an important privacy boundary. An app excluded from the VPN generally uses the local internet connection, local DNS behavior, and local network policy. An app included in the VPN generally follows the selected tunnel and route, but the exact handling of DNS, IPv6, captive portals, and local-network access depends on the client. Split tunneling changes traffic selection; it does not automatically make every application private or guarantee that all related traffic follows the same path.

Before you start: prepare the device and client

Start with a stable baseline. Disconnect other VPN clients, ad-blocking VPNs, firewall applications, and network filters that create their own Android VPN interface. Android normally allows one active VPN service to control the system tunnel at a time, and two tools competing for that role can produce confusing symptoms. A browser extension or a normal HTTP proxy is a different mechanism, but it can still affect testing, so disable it temporarily if you need a clean comparison.

Check whether Android is connected through Wi-Fi or mobile data, and note whether the network requires a sign-in page. Captive portals, enterprise Wi-Fi, and restricted public networks may prevent a tunnel from connecting until the local sign-in step is complete. If you are testing a work tool, confirm whether the organization requires a separate certificate, private DNS setting, device management profile, or always-on VPN policy. Those controls can override or limit what a third-party client is allowed to do.

Use a current Android client from a trusted source. If you use YJVPN, the account panel provides access to the supported Android client and subscription import entry. A subscription link should be treated like an access credential: do not post it publicly, paste it into an unknown converter, or send it to a third-party configuration service. If you prefer a compatible client, first confirm that it supports the subscription format and protocol offered by the service. Shadowsocks, VMess, Trojan, Hysteria2, and WireGuard are not interchangeable settings; importing one format into a client that does not support it will not produce a working profile.

• ✅ Record the current VPN mode and take a screenshot of the app-rule page.
• ✅ Disconnect other applications that create an Android VPN interface.
• ✅ Finish Wi-Fi captive-portal login before testing the tunnel.
• ✅ Keep the subscription link private and import it only into a trusted client.
• ✅ Confirm whether you need include mode or exclude mode for your actual use case.
• ❌ Do not change protocol, DNS, route, and app rules at the same time.
• ❌ Do not use a banking or work account as the only test case.

Make a small test plan before editing the profile. Choose one application that should use the VPN, one that should bypass it, and one ordinary browser or utility application as a control. If the client supports multiple profiles, duplicate the default profile or export its configuration before making changes. If it does not, write down the original node, protocol, DNS, kill-switch, and app-rule settings so you can restore them manually.

Set up app-based routing step by step

Open the Android VPN client and connect with the default profile first. Confirm that the profile itself works before touching split tunneling. If the subscription has not been imported, use the client’s subscription or profile section to add it, refresh the node list, and select a route. The route type may be direct, relay, or a dedicated line such as IEPL, depending on what the client and subscription expose. For this guide, the key requirement is not a particular route label but a working baseline that can be compared after each rule change.

Find the app-rule menu

Look under Settings, Routing, VPN mode, or Advanced settings for a control named Split tunneling, App rules, Per-app VPN, or similar. Read the description carefully. Some clients show two radio buttons such as “VPN selected apps” and “Bypass selected apps.” Others use a switch called “Exclude apps from VPN.” The list may display friendly application names, package names, or both.

Before selecting anything, identify the actual application that generates the traffic. A work shortcut may open a browser. A banking widget may depend on the main banking application. A media app may use Android System WebView or an external sign-in component. Add the application you intend to test, not merely a related icon that happens to appear on the home screen.

Choose include or exclude mode

Use include mode when only a small number of apps need the VPN. For example, select a browser used for a particular research task or a work tool that requires a different route, while leaving local services and financial apps outside the tunnel. Use exclude mode when nearly all applications should use the VPN and only a few clearly identified apps must stay on the ordinary network.

After choosing the mode, add one application. Save or apply the profile, disconnect, and reconnect the VPN. Some clients apply rules immediately; others require a full reconnect or an Android VPN permission confirmation. If Android displays a prompt asking whether the application may create a VPN connection, verify that the prompt belongs to the client you opened and accept it only when appropriate.

Do not enable a kill switch until the basic rule behavior is understood unless your security policy requires it. A kill switch can prevent excluded applications from using the regular network, depending on how the client implements “block connections without VPN.” That may be desirable for privacy, but it can also make local services, banking applications, or emergency connectivity appear broken. Treat the kill switch as a separate setting and test it independently.

Test each rule instead of trusting the label

Force-close the selected application, reopen it, and perform a simple action that generates fresh traffic. Then repeat the same action with the bypassed application. Test on the network you actually use, because Android may behave differently across Wi-Fi and mobile data. Also check whether the application has background data enabled, whether battery optimization has paused the VPN client, and whether Android’s Data Saver is restricting the app.

A useful test records five observations: whether the VPN connects, whether the selected app reaches its service, whether the bypassed app reaches its service, whether local devices remain visible, and whether DNS-dependent functions behave normally. This does not require publishing an IP address or sharing personal account details. You can use a non-sensitive page, a public service status page, or the application’s sign-in screen rather than testing with confidential transactions.

Keep a simple note of each change: application added, rule mode, profile used, network type, and observed result. If several apps fail after one change, return to the previous profile immediately rather than adding more exceptions. A short change log makes it easier to tell whether the problem is caused by routing, DNS, the selected node, or the application itself.

Common Android split-tunneling problems

The most common mistake is reversing the rule meaning. A user intends to bypass a banking application but selects it in an include list, so the application is forced into the tunnel. The second common mistake is selecting a browser while expecting every application opened from that browser to follow the same path. Android handles applications independently; an external app normally uses its own package and its own rule.

If a banking or work app refuses to open, first check whether it is actually bypassed. Then temporarily disable the kill switch and reconnect. Some applications reject a changed network identity, a proxy path, or a DNS response even when the VPN itself is operating correctly. Do not repeatedly submit login attempts while troubleshooting. Close the app, restore the baseline profile, and use the service’s normal recovery process if it continues to reject access.

If local devices disappear, look for an “Allow LAN,” “Bypass private networks,” or “Local network access” option. A VPN client may intentionally prevent access to private address ranges, while the Wi-Fi router may also isolate wireless devices from one another. Excluding the controlling app from the VPN is not always enough; the client’s interface-level firewall or Android permission can still block discovery.

If only one application fails while others work, inspect its protocol and connection style. Some apps use IPv6, UDP, background services, certificate pinning, or a separate login component. A change from a UDP-friendly protocol to a TCP-oriented profile may alter behavior, but protocol changes should be tested separately from app rules. Shadowsocks, VMess, Trojan, Hysteria2, and WireGuard each have different client support and transport behavior, so a compatible import does not guarantee identical results in every application.

Battery optimization is another frequent cause of apparent instability. Android may pause the VPN client when the screen is off or when background activity is restricted. Exempting the client from aggressive battery optimization can help, but follow your device manufacturer’s settings carefully. Do not grant unrelated permissions merely because an app requests them, and do not disable Android security controls that are unrelated to VPN operation.

• ✅ Recheck whether the list means “use VPN” or “bypass VPN.”
• ✅ Apply a browser rule and an external application rule separately.
• ✅ Review LAN access when printers, casting devices, or local servers disappear.
• ✅ Test DNS and IPv6 behavior independently from the selected route.
• ✅ Inspect battery optimization if the VPN disconnects after the screen locks.
• ❌ Do not diagnose a rule by changing several protocols and nodes together.

Restore the default profile safely

When a new rule causes connection issues, start with the smallest rollback. Open the app-rule screen, remove the last application you added, save the profile, and reconnect the VPN. If the problem remains, switch back from exclude mode to include mode or vice versa according to the original screenshot. Then restore the original node, protocol, DNS, LAN, and kill-switch settings one at a time.

If the client offers “Reset routing,” “Clear app rules,” or “Restore defaults,” use that option before clearing all application data. Clearing Android app data may remove the imported subscription, account session, downloaded profiles, and custom preferences. It should be a later troubleshooting step, not the first response to a single bad rule. After a reset, import the subscription again only through the trusted client interface and verify the profile before adding any app exceptions.

Also check Android’s system VPN settings. Remove an old always-on VPN setting if it belongs to a client you no longer use, and review whether “Block connections without VPN” is still enabled. These system-level controls can make a correctly configured application appear offline. If the device is managed by an employer or school, an administrator may have set policies that you cannot override; in that case, contact the administrator rather than repeatedly reinstalling the client.

Once the default profile works, recreate the split-tunneling configuration gradually. Add one app, reconnect, test, and record the result. This slower process is more reliable than importing a large rule set whose meaning is unclear. If you need a broader setup tutorial covering client installation and subscription import, use the setup guide before rebuilding the profile.

A practical workflow for daily use

For a personal Android phone, include mode is usually easier to audit when only a few applications need a different route. Keep ordinary local services outside the tunnel and add only the apps that have a clear reason to use it. For a device used mostly for international services, exclude mode may be more convenient, but maintain a short bypass list and review it after installing a new banking, work, or smart-home application.

Use separate profiles when the client supports them: one conservative default profile, one profile for a specific work or media task, and one clean troubleshooting profile. Do not duplicate a rule across several clients. If you switch between the official Android client and a compatible client such as Clash Verge on another device, sing-box, or Shadowrocket on supported platforms, remember that their rule syntax and subscription handling may differ. A rule copied from one client may not carry the same meaning in another.

Finally, judge the configuration by repeatable behavior rather than by a single successful connection. Test after changing from Wi-Fi to mobile data, after Android restarts, after the client refreshes its subscription, and after a major application update. Confirm that the apps requiring the VPN still work, the apps intended to bypass it still use the regular network, and local functions remain available. If the result changes, return to the documented baseline and isolate one variable at a time.

YJVPN supports Windows, macOS, iOS, Android, and Linux, with 90+ countries and 200+ lines available through supported clients. Android split tunneling is not a substitute for careful testing, but it gives you a practical way to keep different applications on the route that fits their purpose. The most dependable setup is the one you can explain, reproduce, and undo without guessing.