Android split tunneling lets you choose which apps use a VPN connection and which connect through your regular network. It can be useful when one app needs a VPN route but another depends on a local service, a nearby device, or a connection that works better directly. The important detail is that an app excluded from the tunnel does not get the VPN’s route or its network protections. Before changing any rules, decide which apps need the tunnel, which genuinely need direct access, and how you will verify the result.

How Android split tunneling works

On Android, VPN apps commonly use the system’s VPN service to direct network traffic through a tunnel. When an app offers per-app rules, you can usually select apps to include in the VPN or select apps to exclude. The available options and labels depend on the client, so check whether its rule is an allowlist (only selected apps use the tunnel) or a denylist (selected apps bypass it). Those choices produce opposite results from the same-looking list of app names.

Per-app routing is not the same as choosing a country or server. A route selection decides where tunneled traffic exits; an app rule decides whether that app’s traffic enters the tunnel at all. Rules also do not necessarily control every connection associated with an app. A browser, for example, may open links handled by a separate application, and the destination app follows its own route. Some apps use background services or additional components that make the observed behavior less obvious.

Android’s system settings do not provide a universal per-app split-tunneling screen for every VPN. In most cases, the VPN client must implement app selection. A work profile, a cloned app, or a second user profile may also be treated separately from the regular app installation. If an app is missing from the list, check which profile it belongs to and whether the VPN client supports that profile before assuming the rule is broken.

Choose apps and the right rule mode

Make a short list before opening the client. Start with apps whose traffic clearly needs a VPN route, such as a browser or a service you deliberately use through the VPN. Then identify apps that must reach a local device or service directly. Avoid selecting every app just because it appears in the list: more exceptions mean more routes to remember and more opportunities for an app to connect outside the tunnel unintentionally.

For an allowlist, selected apps use the VPN and other apps generally connect directly. This can make the intended coverage easy to understand when only a few apps need the tunnel, but it is easy to forget a newly installed app. For a denylist, most apps use the VPN and selected exceptions connect directly. This may be convenient when only a few apps need direct access, but it can route more traffic through the VPN than you intended. Confirm how the client defines its mode; do not infer the meaning from the words “include” or “exclude” alone.

For example, a local printer application may need access to devices on the same Wi-Fi network, while a browser may need the VPN route. Whether bypassing the VPN is necessary depends on the client’s local-network handling and the printer setup. Test the specific task before creating a broad exception. If you use VPN61 or another VPN service, check the Android client and its current settings for per-app routing options; a subscription and a split-tunneling feature are separate things.

Set up and test app rules on Android

Menu names vary across Android versions and VPN clients, so follow the matching controls in your installed app rather than relying on a particular button label. The sequence below gives you a repeatable way to configure and verify the rules without assuming that every client uses the same interface.

  1. Record the starting state. Note whether split tunneling is off, whether the client uses an allowlist or denylist, and which apps are currently selected. If you are troubleshooting, take a screenshot or write down the existing choices before changing them.
  2. Connect the VPN first. Confirm that the client reports an active connection and that an app expected to use the VPN behaves as it did before. This gives you a baseline and helps distinguish a connection problem from a rule problem.
  3. Open the app-routing controls. In the VPN client, look for settings such as split tunneling, per-app routing, app rules, or excluded applications. If no such control exists, do not assume Android’s system VPN page can add the feature for that client.
  4. Choose the rule mode deliberately. Read the explanation shown by the client. Determine whether checked apps use the VPN or bypass it, then choose the mode that matches your list. If the interface does not clearly explain the behavior, test with one non-sensitive app before adding more.
  5. Select only the apps you intend to route differently. Check the displayed app name and, when available, its icon or package details. Similar names can belong to different apps, and a work-profile or cloned copy may appear as a separate entry.
  6. Save the configuration and reconnect if prompted. Some clients apply a rule immediately; others need the VPN connection to restart. Wait for the client to show a connected state again before testing.
  7. Test both sides of the rule. Open an app that should use the VPN and verify its route using a trustworthy IP-checking method. Then test an app that should connect directly, checking the behavior you need rather than relying only on the VPN icon. Repeat after switching Wi-Fi or mobile data if the rule must work on both.

Use an app that does not expose private account or payment details for an initial route test. An IP-checking page can show the apparent public address for the browser that opened it, but it cannot prove how every other app is routed. To test another app, use that app’s own connection or diagnostic feature where available. Also remember that IP results can be affected by network changes, cached pages, DNS behavior, and the app’s own proxy settings.

Practical rule: change one app rule at a time, reconnect if needed, and verify the selected app and a control app separately. A connected indicator alone cannot confirm per-app routing.

Test DNS, local access, and lockdown settings

App routing and DNS behavior are related but not identical. A client may use its own DNS settings for tunneled traffic, while an excluded app uses the network’s ordinary DNS path. Some apps also use encrypted DNS or a built-in proxy, which can make their behavior differ from the device-wide expectation. If a site fails after changing a rule, first confirm which app is making the request and whether that request is meant to travel through the tunnel.

Local-network access needs particular care. A device on the same Wi-Fi, such as a printer or media receiver, may be reachable only when traffic to local addresses is allowed. Some VPN clients provide a separate local-network option; others require a routing exception or do not offer the same behavior. Prefer a narrow, documented setting over excluding an unrelated app. If access works only after disabling the VPN, re-enable it and test the client’s local-network controls before leaving the app permanently outside the tunnel.

Android may offer always-on VPN and a setting that blocks connections outside the VPN. These controls can interact with app exclusions, and the exact result can depend on Android version and client implementation. An app you deliberately exclude may fail to connect when lockdown is active, because its traffic is not using the VPN. Do not disable lockdown casually if your goal is to prevent unprotected traffic. Instead, check the client’s explanation, test the expected behavior, and decide whether the exception is compatible with your security requirements.

Battery management can also interrupt a VPN or delay its reconnection, particularly when the app is restricted in the background. If rules appear to work only while the VPN app is open, check Android’s battery and background activity settings for that client. Change only the relevant restriction and test again. Battery settings do not replace a correct route rule, and a route rule cannot guarantee that an app stays connected when Android suspends it.

Troubleshoot rule conflicts and unexpected routes

When an app stops working, avoid changing several settings at once. Confirm that the VPN itself connects, check that the app is listed in the intended rule mode, and then test with the rule temporarily removed. If the app works without the rule but fails with it, the issue is likely related to the selected route, DNS, local-network access, or a conflict with another setting. Restore the rule only after identifying which behavior you need.

Check for other software that can establish a VPN connection or modify network traffic. Android generally has one active VPN service at a time, so a second VPN, firewall, ad blocker, or security app that uses the VPN interface may prevent the intended client from operating normally. A browser’s own proxy setting can also make its traffic appear inconsistent with the Android app rule. Disable competing network tools one at a time for a controlled test, then re-enable the tools you need.

Also consider whether the app has more than one route to the same task. A link opened from a mail app may launch a browser; a media service may use a separate helper app; and a work-profile copy may not share the personal app’s settings. Test the app that actually makes the connection rather than only the app where you tapped the link. If you cannot identify the component, temporarily return to a simple configuration and add exceptions back individually.

If the rule list becomes difficult to understand, use the client’s reset or restore-defaults option rather than deleting Android system data. Record the current configuration first if you may need to restore it. After a reset, reconnect the VPN, establish that ordinary routing works, and rebuild only the exceptions you can explain. A smaller rule set is easier to audit and less likely to send sensitive traffic outside the route you intended.

Keep a clear and safe configuration

Review app rules when you install, replace, or clone an application, change Android profiles, or switch VPN clients. A rule that made sense for an old app may no longer match the task you perform. Keep a brief note of why each exception exists—for example, “needs access to a local printer”—rather than relying on memory. Remove exceptions that no longer serve a purpose.

Split tunneling is a routing choice, not a general privacy switch. Apps routed through the VPN use the VPN path, subject to the client and service configuration. Apps routed directly use the ordinary network path instead. Neither choice hides account activity from the service you sign in to, and a VPN does not replace secure app practices, HTTPS, or careful handling of permissions. If an app handles sensitive information, consider whether direct routing is acceptable on the network you are using.

Before relying on a setup, verify the main app’s route, the direct exception’s behavior, local access if required, and the effect of any always-on or lockdown setting. If a test gives an unexpected result, simplify the rules and repeat the check rather than assuming that the connection status explains every app’s path.

Bottom line: use the narrowest app rules that meet your needs, confirm whether selected apps are included or excluded, and test the actual app connection after every meaningful change.