Android Split Tunneling Guide: Set VPN App Rules in 2026

Understand how Android split tunneling works

Android normally allows one active VPN service to create a virtual network interface. The VPN client uses that interface to receive traffic from selected applications, forward it through a remote route, and return the responses to the device. Split tunneling changes which applications are attached to that interface. Depending on the client, the setting may be labelled Per-app VPN, App proxy, Include apps, Exclude apps, or Bypass selected apps.

There are two common models. In an inclusion model, only the applications you select use the VPN and everything else stays direct. In an exclusion model, most applications use the VPN while the selected applications bypass it. These models are not interchangeable. If you intend to route only a browser and an AI application through the VPN, an inclusion list is usually easier to audit. If you want nearly all traffic protected but need a local banking or printer app to remain direct, an exclusion list may be more convenient.

Application selection is based on Android package identity rather than merely the name shown on the home screen. A browser may have separate stable, beta, and work-profile packages. A streaming app may launch a second package for playback or authentication. A game may use an external login component, while an email application may hand links to a separate browser. If only the visible app is selected, a related component can still connect directly.

Split tunneling also does not automatically separate DNS from application traffic. Some clients send DNS through the VPN, some apply DNS rules according to the selected route, and some applications use encrypted DNS inside their own process. Consequently, an app can appear to use a desired exit address while resolving a domain through a different resolver, or it can fail because the selected DNS path does not match the application’s expectations.

Choose a client and confirm its traffic mode

Start with a client that officially supports your Android version and the configuration format you intend to use. An official GreenVPN client may provide a subscription import flow and a built-in application rule screen. Compatible clients may support formats or protocols such as Shadowsocks, VMess, Trojan, Hysteria2, or WireGuard, but support for a protocol does not prove that the client supports Android per-app routing for that protocol. Read the client’s current documentation and use the configuration type it is designed to parse.

A subscription link is a private account credential in practical terms. Import it directly into the intended client rather than pasting it into a public converter, online diagnostic page, or chat. After importing, check whether the client has created a usable route profile, whether the server list is visible, and whether the selected protocol is compatible with the client. If an import succeeds but no route can connect, the issue may be a format mismatch rather than an Android split-tunneling problem.

VPN mode and proxy mode are different

Android system VPN mode normally creates a local virtual interface and displays a VPN indicator after you approve the connection request. This mode can apply per-app rules more consistently because traffic is selected at the operating-system VPN layer. A local HTTP or SOCKS proxy, by contrast, depends on applications accepting proxy settings. Some Android apps ignore system proxy values, some use certificate-pinned connections, and some open their own transport channels.

If the client offers both proxy mode and TUN mode, understand what each option does before enabling it. TUN mode usually means the client uses a virtual interface to handle a broader range of IP traffic. It may require an additional permission, may conflict with another VPN or firewall application, and may expose routing mistakes more clearly than a simple application proxy. Do not enable multiple VPN services at the same time and expect their per-app rules to combine; Android generally gives one VPN service control of the active tunnel.

Configure Android app rules step by step

Make the first rule set deliberately small. Select one ordinary test application, such as a browser, rather than immediately adding every application on the phone. A small rule set makes it easier to identify whether the client, route, DNS, or application itself is responsible for a failure.

1. Import or select the route profile. Open the client, update the subscription if necessary, and choose a route that you have already tested in global mode. Avoid changing the route and the application list at the same time.
2. Open the per-app rule screen. Look for application routing, split tunneling, app proxy, or a similar setting. Record whether the screen is currently using an inclusion list or an exclusion list.
3. Select the intended package. Read the complete application name and check for duplicate versions, work-profile copies, or related helper applications. If the client shows package identifiers, keep a note of the selected identifier.
4. Save and apply the configuration. Some clients apply changes immediately; others require a reconnect. Disconnect the current session if the client asks you to do so, then reconnect and approve Android’s VPN request.
5. Check the Android VPN indicator. The indicator confirms that a VPN service is active, but it does not confirm that the selected application matched the rule. Continue with an app-level test.
6. Test the selected app first. Fully close and reopen the app so that old sockets, cached DNS results, and existing sessions do not obscure the result.
7. Test an unselected app. Use a second application to confirm that the rule is actually split rather than global. The unselected app should follow the expected direct or VPN path according to your rule model.

For a browser test, close private DNS tools, browser proxy extensions, and other network utilities that could affect the result. Visit a trusted IP-checking page before and after enabling the rule, and compare the public address and network ownership. The visible region is only supporting evidence because geolocation databases can be inaccurate. The key question is whether the selected app’s connection changes while the unselected app behaves according to the opposite rule.

For an application that does not expose its network details, compare a controlled action such as loading a page, signing in, or retrieving a small data set. Keep the route, Wi-Fi or mobile network, and client mode unchanged while testing. A test that changes all of these variables at once cannot show which setting fixed or caused the problem.

Use inclusion and exclusion lists intentionally

Do not select both “include” and “exclude” assumptions at the same time. In some clients, choosing an application in an exclusion screen means that it bypasses the VPN. In others, a similarly named list may mean that only the selected applications are proxied. Read the explanatory text near the switch and perform a two-application test after saving.

When the app list becomes large, group your decisions by purpose: applications that require the VPN, applications that must remain direct, and applications that should follow the default. Avoid adding system components unless the client documentation specifically recommends it. Android system packages can change across devices, and routing a helper process without its parent application may create an incomplete or unstable result.

Check rule priority, DNS handling, and TUN mode

App selection is only one layer of a routing decision. Many clients evaluate rules in an order that includes application identity, domain rules, IP or geographic rules, mode selection, and a final fallback. A broad rule placed above a specific application rule can capture traffic before the app exception is reached. Other clients use the application list as a separate switch, so the list may take priority over ordinary domain rules. You should read the client’s rule-order description rather than copying a configuration from a different client.

TUN mode deserves a separate check because it can change how applications reach both remote and local addresses. After enabling it, confirm that Android shows one active VPN service, the client reports that the virtual interface is running, and no other firewall or VPN application is competing for control. If the client offers a kill switch, understand whether it blocks only VPN-selected apps or all device traffic when the tunnel drops. A kill switch with the wrong scope can look like an application failure.

DNS behavior is especially important for applications that use several hostnames. A login page may load while an API endpoint, image host, update server, or telemetry endpoint fails. If the client provides separate options for remote DNS, local DNS, fake-IP handling, or DNS hijacking, change one setting at a time and reconnect after each change. Avoid adding random domains to a bypass list merely because one request failed; first determine whether the failed name should resolve through the VPN or the local network.

IPv6 can create another apparent exception. If an application receives an IPv6 address and the client handles only IPv4 traffic, the application may connect directly or fail depending on the device and network. This does not mean every Android phone has an IPv6 problem. It means that IPv4 and IPv6 behavior should be considered when the public address observed by an app does not match the expected route.

Test both paths and diagnose failures methodically

A reliable test has a baseline, a controlled change, and a rollback point. First disconnect the client and record how the target application behaves on the regular connection. Note whether it can sign in, resolve content, reach local devices, and maintain a session. Then connect the client with only the intended app selected. Repeat the same actions without changing the network type or route profile.

Next, test an application that was not selected. This negative test is essential because a successful target-app connection only proves that the target can connect; it does not prove that split tunneling is active. Compare the public exit address from both applications where possible. If the applications use different browsers or embedded web views, remember that cached sessions and encrypted DNS may produce different observations.

Separate client errors from application errors

If the selected app cannot connect but the client log shows no handshake or transport problem, inspect the application rule and package selection first. If the client cannot establish any route in global mode, investigate the imported profile, protocol support, route availability, and system permission instead. If only one service inside the app fails, inspect DNS, helper domains, account restrictions, and the app’s own proxy or network settings.

• Restart the selected app after applying a rule so old connections are discarded.
• Reconnect the VPN after changing TUN, DNS, or rule-order settings.
• Temporarily disable Android’s battery restriction for the client if it disconnects in the background.
• Check whether mobile data and Wi-Fi produce different results; carrier filtering and local DNS can differ.
• Do not run another VPN, firewall tunnel, or proxy application during the first test.
• Keep a copy of the previous working configuration before making a broader change.

Performance should also be evaluated by use case. Split tunneling can reduce unnecessary load on the VPN route because unrelated updates, local services, and ordinary traffic remain direct. However, it can make troubleshooting more complex because two applications on the same phone may resolve names and reach services through different paths. Stability, DNS consistency, and correct application matching are usually more important than a brief speed peak.

Roll back safely when a rule causes connection problems

When a new rule breaks connectivity, return to the last known working state instead of adding more exceptions immediately. Open the client, disable the per-app rule or restore global mode, save the profile, and reconnect. If the application still cannot connect, stop the VPN service and test the regular connection. This separates a stale tunnel or cached socket from a persistent application problem.

If Android’s VPN permission appears stuck, remove the active VPN connection from the client and reopen it so the system can issue a fresh request. Do not repeatedly approve several VPN applications at the same time. If another VPN service is active, disconnect it before testing the intended client. On some phones, battery management, vendor security tools, or always-on VPN settings can restore a previous service after you think it has been disabled.

For a cautious rollback, use this order:

1. Save or write down the current route profile and application list.
2. Disable the newest rule and return to the previously tested mode.
3. Reconnect once and test the target application from a clean launch.
4. If the failure remains, stop the VPN and test the regular network.
5. Re-enable only the smallest working rule, then add applications one at a time.
6. Keep the failing package and error behavior recorded for later support or documentation.

When you need local access to printers, casting devices, smart-home equipment, or a company resource, check whether the client has a documented LAN bypass. A local-network exception is different from excluding an application. Excluding a casting app may prevent its internet requests from using the VPN, but it may not restore discovery traffic from another application or system service. Apply the narrowest exception that solves the actual problem.

Finally, treat split-tunneling rules as part of your privacy and security configuration. An excluded application may reveal the regular network address, while an included application may depend on a remote DNS path and a stable route. Review the list after Android updates, app replacements, work-profile changes, or client migrations. Delete old entries for applications you no longer use, keep the subscription link private, and avoid assuming that a rule copied from Windows, macOS, iOS, or another Android client has the same meaning.