Android VPN Split Tunneling: Complete Rules Setup Guide

Android VPN split tunneling lets you decide which applications use a remote route and which applications keep their normal network connection. This is useful when one app needs access to a different region while another app must continue reaching local services directly. It can also reduce unnecessary routing, simplify troubleshooting, and prevent local applications from being affected by a proxy that they do not need.

However, split tunneling is not a single universal switch. Different Android clients implement it in different ways. Some use an application list, some provide “VPN apps” and “bypass apps” modes, and others apply rules through a compatible core such as sing-box or another routing engine. The result also depends on whether the client uses Android’s VPNService, a system proxy, or a virtual network interface. This guide explains how to build rules, test them, and diagnose cases where an application appears to bypass the rule or continues to use the wrong DNS path.

What Android Split Tunneling Actually Does

On Android, many VPN and proxy clients create a virtual interface through the system VPNService. The client receives traffic from selected applications, examines the destination and rule set, and then sends the traffic either through the remote route or directly to the local network. The Android VPN icon confirms that a VPN interface is active, but it does not prove that every application is using the same path or that DNS requests are following the intended policy.

There are two common designs. In an allow-list or “VPN apps only” design, only the applications you select are sent into the VPN. Every other application remains direct. In a bypass-list design, most applications use the VPN and the applications you select are excluded. These modes can look similar in the settings screen, but they produce opposite results if the list is interpreted incorrectly.

Some clients also provide rules based on domain, IP address, process, or rule provider. App-based rules are usually the easiest starting point because they do not require you to identify every destination used by an application. Domain-based rules are useful when one application connects to several services with different domains, while IP-based rules can be difficult to maintain because addresses may change or be shared by unrelated services.

When using 05VPN, the service supplies the account, subscription, and route configurations. The Android client imports those configurations and applies its own routing policy. A subscription may contain profiles based on protocols such as Shadowsocks, VMess, Trojan, VLESS, or Hysteria2, but protocol support depends on the client and the imported format. The protocol determines how the connection is authenticated and transported; it does not determine which Android applications are included in the tunnel.

Choose the Right Rule Model

Use an app-only VPN mode when you want a small number of applications to use the remote route and everything else to remain direct. This is usually easier to verify because the intended traffic scope is narrow. Use a bypass mode when most of your applications should use the route and only a few local applications need to remain direct. Before saving the setting, read the client’s description carefully and check whether the list means “included apps” or “excluded apps.”

• ✅ Start with one test application instead of adding a large group at once.
• ✅ Record whether the list is an include list or an exclude list.
• ✅ Keep banking, payment, work, and local-device applications direct unless you have a specific reason to route them.
• ❌ Do not assume that the Android VPN icon means every application is using the remote route.
• ❌ Do not run two Android VPNService clients at the same time.

Prepare the Android Client and Subscription

Before creating rules, install a client that matches the configuration format you intend to use. The official 05VPN Android client is the simplest option when you want the service’s normal login, subscription, and route management flow. Compatible clients may provide more detailed rule controls, but they require you to understand whether they expect a Clash-style configuration, a sing-box profile, or individual node links.

A subscription link is sensitive configuration data. It may identify your account or allow a client to retrieve route information, so copy it only from the service dashboard. Do not paste it into public chats, screenshots, browser bookmarks that are synchronized to shared accounts, or unknown conversion websites. If the link is exposed, refresh or replace it through the available account management process rather than continuing to treat it as private.

For a first setup, use the client’s normal import function. Open the subscription or configuration section, paste the link, update the profile, and confirm that a route list appears. If the client reports an unsupported format, the issue may be the client rather than the route. Clash-compatible clients expect Clash configuration structures, while sing-box expects its own JSON structure. A client that supports Shadowsocks does not automatically support every VMess, Trojan, VLESS, or Hysteria2 field in a subscription.

Do not enable several advanced options before the basic connection works. First select a route and connect without split tunneling. Open the target application and confirm that it can establish a fresh connection. Then disconnect, create the application rule, reconnect, and repeat the test. This order separates subscription problems, route problems, permission problems, and rule problems.

For clients that support a system proxy and a virtual network interface, prefer the mode that covers the application you are testing. Many mobile applications do not consistently follow the Android system proxy setting. A VPNService-based tunnel generally provides broader application coverage, but it may interact with private DNS, other security tools, enterprise profiles, or device-specific network management.

Step-by-Step App-Based Rule Setup

The labels differ between clients, but the workflow is broadly similar. The following procedure is designed for an Android client with an application list or per-app routing option.

1. Update the profile. Open the client and refresh the imported subscription. Confirm that the profile is current and that at least one route can be selected.
2. Connect without split tunneling. Choose a suitable route and connect in the client’s ordinary mode. Test the application that you want to route before adding a rule.
3. Open per-app settings. Look for names such as “App proxy,” “Per-app VPN,” “VPN apps,” “Bypass apps,” or “Application routing.” Read the description before selecting a mode.
4. Choose one rule model. Select either the applications that should use the VPN or the applications that should bypass it. Do not interpret an exclusion list as an inclusion list.
5. Add the primary application. Select the application from the installed-app list. If the client shows system applications, avoid adding them until you understand their network role.
6. Save and reconnect. Disconnect the VPN, save the rule, and connect again. Some clients apply application changes only after the VPN interface is recreated.
7. Test a fresh request. Close and reopen the target application. Use a page or function that requires a new network request rather than relying on cached content.
8. Add exceptions carefully. If the main application works, add a second application that should remain direct. Test both applications after every change.

Keep the first rule set simple. For example, route one browser or media application through the VPN, while leaving a local payment application and a home-network utility direct. This arrangement gives you three useful observations: whether the included application reaches the expected route, whether the excluded application keeps local access, and whether Android has accepted the rule after reconnection.

Rule Order, Processes, and Application Families

An application may use more than one process. The visible package name can launch a main process, a background service, a download process, or a separate authentication component. Some clients list the parent application only, while others expose individual packages. If login works but media playback, notifications, or downloads fail, check whether the related process is covered by the same rule.

Rule order matters when a client combines app rules with domain or final policies. A broad rule placed above a specific exception may capture the traffic before the exception is evaluated. A typical policy might be: selected application through the proxy, local application direct, private address ranges direct, and a final default rule for everything else. The exact syntax depends on the client, so do not copy configuration fields from another core without checking its documentation.

Also distinguish between an app-based rule and a destination-based rule. An app rule answers “which process is making the request?” A domain rule answers “where is the request going?” If an application uses a third-party login provider, content delivery network, and API domain, routing only one known domain may produce partial functionality. App-based routing is often more predictable for an initial setup, while destination rules are better for fine-grained policies after you understand the application’s traffic pattern.

Test Application Routing and DNS Separately

A successful connection requires more than opening an application. Test the route and DNS behavior separately because an app can appear to use the correct path while resolving some domains locally, or it can fail because its DNS requests are blocked even though the proxy route itself is available.

Start by checking the client status, Android VPN indicator, and the application’s freshly loaded content. Then compare an application intended for the VPN with an application intended to remain direct. Use functions that make a new request: sign in again, refresh an uncached page, load a new image, or open a section that was not previously stored. A cached page, an offline screen, or an already authenticated session cannot prove that the current request used the intended route.

• ✅ Confirm the VPN permission dialog was accepted for the current client.
• ✅ Disconnect and reconnect after changing the application list.
• ✅ Test a new request in the included application and a local function in the excluded application.
• ✅ Check whether the client log identifies the matched application or rule.
• ✅ Compare behavior on Wi-Fi and mobile data if the issue appears only on one network.
• ❌ Do not use only the status-bar icon as proof of correct split tunneling.
• ❌ Do not change protocol, route, DNS, and application rules in one step.

DNS can create confusing results. In direct mode, Android may use the network’s DNS resolver or the system Private DNS setting. In tunnel mode, the client may send DNS requests through the remote route, use an encrypted resolver, or answer from a local cache. Some clients support fake-IP or synthetic-address modes, where the application receives an internal address and the client translates it later. This can improve rule processing for supported clients, but applications that expect literal IP responses may behave differently.

If a domain resolves incorrectly, first check whether Private DNS is enabled at the Android system level. Temporarily compare automatic and client-managed DNS modes, then reconnect before testing. If only one application fails, inspect its own encrypted DNS setting, custom resolver, or built-in network stack. Some applications ignore the client’s DNS policy by opening their own encrypted DNS connection. In that case, an app rule alone may not control every lookup.

When using a third-party client such as a compatible sing-box-based Android application, confirm that the profile contains a DNS section and that the routing rules reference the correct application package where supported. A Clash-style configuration imported into a non-Clash client may lose app-specific behavior during conversion. The safest troubleshooting method is to inspect the generated profile inside the client and verify that the intended rule was actually retained.

Fix Common Bypass and Connection Problems

If the selected application still uses the direct connection, check the rule direction first. Many failures come from selecting “bypass these apps” when the intention was “proxy these apps.” Next, confirm that the application was added after installation and that the client recognizes its current package. Reinstalling or cloning an application can change the package identity shown to the client.

If the excluded application cannot connect, the policy may be using a block-all or VPN-only mode rather than simple bypass behavior. Android’s “block connections without VPN” option is designed to prevent traffic outside the VPN interface. It can be useful for strict protection, but it conflicts with a plan that deliberately requires selected applications to connect directly. Disable it while testing split tunneling unless every required application is intended to use the tunnel.

Battery management is another common cause. Android device manufacturers may freeze background processes, disable autostart, or clear the client when the screen locks. Allow suitable background activity for the client and keep its persistent notification enabled if the application uses one. Avoid assuming that an uninterrupted VPN icon means the proxy core is still processing traffic; wake the device and perform a fresh request after a lock-screen test.

When the VPN connects but one application shows no network, test without the application rule. If it works in broad mode but fails in split mode, the rule or DNS policy is the likely cause. If it fails in both modes, investigate the route, protocol compatibility, application restrictions, or local network. Shadowsocks, VMess, Trojan, VLESS, and Hysteria2 each require matching client support and correct parameters; changing between them without confirming compatibility can create a second problem instead of solving the first.

Network changes also deserve a separate test. Moving from Wi-Fi to mobile data can cause the old virtual interface or DNS state to become stale. Disconnect the client, wait for Android to complete the network change, and reconnect. If the problem occurs only on a managed Wi-Fi network, captive portal authentication, UDP restrictions, or local DNS interception may be involved. Complete the Wi-Fi login directly before starting the VPN, then test the application again.

Finally, remove unused rules. A long list copied from another device can contain duplicate applications, outdated package names, or exceptions that override the intended policy. Keep a small written record of the desired behavior: application A through the VPN, application B direct, DNS managed by the client, and default traffic handled by the selected mode. This makes later profile updates easier to review.

Maintain Rules After Setup

Split tunneling is a policy, not a one-time installation step. Applications update their package behavior, add new services, or change how they resolve domains. Subscription profiles can also receive new routes or rule groups. After refreshing a profile, verify that the client has not replaced your local application policy with a new default profile. Some clients store local overrides separately, while others require you to save a customized profile.

Review the application list whenever you install a new client, duplicate an application, change the default DNS mode, or enable Android Private DNS. If a previously reliable application suddenly behaves differently, test the same rule with another route before rewriting the entire policy. A route-specific failure and a rule-specific failure can look identical from inside the application.

For everyday use, choose the narrowest rule set that solves the actual problem. Route only the applications that need it, leave local services direct when appropriate, and avoid adding system processes unless you understand their purpose. If you need broader coverage for a game, command-line tool, or application that ignores system proxy settings, use a VPNService or virtual-interface mode supported by the client and test its DNS behavior separately.

05VPN supports Windows, macOS, iOS, Android, and Linux, with subscription-based configuration import and route selection. The available service coverage is 90+ countries and 200+ routes, while simultaneous online device use is not limited by a fixed device count. These are service-level capabilities; the practical result on Android still depends on the client, selected protocol, network, application behavior, and rule design.