How to Set Up Android VPN Split Tunneling for Each App

What Android VPN Split Tunneling Does

Android VPN split tunneling lets you decide which apps send traffic through a VPN connection and which use the phone’s ordinary network connection. Instead of applying one routing choice to every app, the VPN client applies rules to selected apps. This can be useful when a work tool needs the VPN but a local device app must reach a printer directly, or when you want to keep a particular app outside the tunnel.

The setting is usually part of the VPN client, not a universal Android menu that works the same way on every phone. Many Android VPN apps use the system’s VPN service interface to establish a connection and then offer their own app-selection screen. Android also has per-app VPN capabilities for managed devices, but ordinary consumer setup and available controls depend on the VPN app, Android version, and device configuration.

Two common rule styles are used:

With an inclusion list, apps you select use the VPN and other apps normally use the direct connection. With an exclusion list, the VPN generally covers apps by default except for those you exempt. A client may label these options “Selected apps,” “Only these apps,” “Bypass VPN,” or “Exclude apps.” Read the screen carefully: selecting an app can mean either “route through VPN” or “do not route through VPN,” depending on the mode.

Split tunneling controls routing, not an app’s entire privacy or security behavior. An app excluded from the VPN can still use HTTPS, but its traffic does not receive the VPN tunnel’s network path. An included app may still send data to its own servers, use account identifiers, or be affected by permissions and background restrictions. The setting is a routing decision, not a substitute for reviewing the app’s permissions and privacy settings.

When App Rules Help—and When They Do Not

Per-app rules are most useful when you can name a specific connectivity need. For example, you might want a banking app to use the normal network if it rejects VPN connections, while keeping a browser inside the VPN. Or you may need a local-network app to discover a device while other apps remain routed through the tunnel. These are reasons to test a narrowly scoped rule, not guarantees that an app will work better after bypassing the VPN.

Some problems are caused by more than the route. A service may reject an account sign-in, an app may have a stale session, or Android may restrict its background activity. A split-tunneling change will not fix those conditions. Likewise, excluding an app does not ensure that it can discover devices on a local network: discovery protocols, router settings, Android permissions, and client behavior can all matter.

Check whether the VPN client applies app rules to all traffic generated by an app, including background requests, or whether it documents exceptions. Some clients treat system components, tethered traffic, or apps in a work profile differently. A cloned app or a second copy in a work profile may appear as a separate entry—or may not be selectable at all. Do not assume that a rule for the personal-profile app automatically covers every copy.

If your goal is to protect all device traffic, an exclusion list needs particular care: every exempt app is outside the VPN route. An inclusion list can also leave unselected apps on the direct connection. In either mode, verify the client’s default behavior rather than inferring it from the list alone. You can review the service’s setup and platform information at VPNNeed, then confirm the actual controls in the Android client you use.

Where to Find the Setting in Android VPN Clients

Start in the VPN client that owns the active connection. Open its settings and look for terms such as “Split tunneling,” “Per-app settings,” “App filter,” “Include apps,” or “Exclude apps.” Depending on the client, the option may appear before connecting, in a profile editor, or in advanced connection settings. A profile can have its own rules, so check that you are editing the profile you actually use.

In an official VPN app, the screen may present a list of installed apps with switches or checkboxes. The app may ask whether selected apps should use the VPN or bypass it. Some clients provide only one rule style; others let you change the mode. If you cannot find the control, consult that client’s help material for your Android version. Do not follow instructions for a different operating system: desktop clients often use different terminology and routing mechanisms.

Compatible clients such as Clash-based apps, sing-box clients, or other proxy tools may expose package selection, routing rules, or both. These controls are not necessarily equivalent. A package-level VPN exclusion determines whether an app’s traffic enters the client’s Android VPN interface; domain or IP rules inside a proxy profile decide how traffic already reaching the client is handled. Changing a domain rule does not necessarily exclude the app itself, and an app exclusion may bypass all of the client’s routing rules for that app.

Android normally allows one active VPN connection through its system VPN service at a time. If another VPN app, security product, or work profile is controlling a VPN connection, the client may refuse to connect or its rules may not take effect as expected. Disconnect other VPN connections before troubleshooting, and check Android’s VPN settings to see which app is active. Do not install a second VPN just to test a split-tunneling rule.

App names and package entries can also be confusing. A system component may have a technical label, and a browser may be represented by more than one related app. If the client provides an app-information screen, compare the package or icon with the app you intend to control. Avoid selecting unfamiliar system entries as a shortcut; changing their route can affect services that other apps depend on.

Configure and Test a Rule Step by Step

Make one change at a time and keep a note of the original setting. This makes it easier to undo a rule if an app loses connectivity, and it prevents a test from turning into a confusing mix of profile, DNS, and routing changes.

1. Identify the problem app. Write down what it needs to reach, such as a sign-in service, a local device, or a company resource. Confirm that the problem occurs while the VPN is connected, rather than assuming that the VPN is the cause.
2. Check the current mode. Open the active VPN profile and note whether the list is an inclusion list or an exclusion list. Check the default behavior for apps that are not selected. If the interface is unclear, do not guess; look up the client’s explanation before applying a rule.
3. Select only the intended app. Add it to the relevant list, save the profile, and reconnect if the client asks you to. Avoid changing several apps at once, so you can tell which change affects the result.
4. Test a simple action. Open the app and repeat the action that failed. Check both the app’s intended function and whether other apps still behave as expected. A successful app launch alone does not prove that its traffic followed the route you intended.
5. Compare the route where practical. Use a reputable IP-checking page or a service you trust to compare the apparent network path with the VPN on and off. An IP check is a limited diagnostic: it may show the route used for that request, but it does not prove that every app request, DNS query, or background connection uses the same path.
6. Undo or refine the rule. If the app still fails, remove the rule and reconnect to restore the previous behavior. Then investigate the app, profile, DNS, or network separately. Do not keep adding broad exemptions simply because one test did not resolve the issue.

Test on the network where the issue matters. Wi-Fi and mobile data can have different captive portals, DNS behavior, and local-device access. If a network requires a sign-in page, connect to it before enabling the VPN when necessary, then test the app again. A result on one network should not be treated as proof that the same rule will behave identically everywhere.

When comparing routes, avoid sending sensitive information to unfamiliar diagnostic websites. Do not post screenshots of the client’s configuration or logs without checking them first; they may expose server addresses, account details, subscription information, or other private configuration data. A short note of the app, profile, rule mode, network type, and observed symptom is often enough for methodical troubleshooting.

Troubleshoot Apps That Lose Connectivity

If an app stops working after you enable a rule, first confirm what the rule means in that client. A selected app in an exclusion mode may be bypassing the VPN, while a selected app in an inclusion mode may be the only one sent through it. Reopen the list, check the mode label, and verify that the correct app entry is selected. If uncertain, remove the rule, reconnect, and see whether the earlier behavior returns.

Next, separate an app problem from a route problem. Try the same action with the VPN disconnected, then with the VPN connected and the rule removed. If it fails in both cases, investigate the app’s account, permissions, update status, or service availability rather than changing more VPN settings. If it works only when the VPN is disconnected, the service may be reacting to the VPN route, but that does not by itself identify whether the cause is the exit address, DNS, a proxy setting, or another policy.

Check whether Android has paused the app or restricted its background network use. Battery optimization and data-saver behavior can delay background connections, which may look like a routing failure. Also check whether the app uses a work profile, a managed configuration, or a second installation. Make sure the client’s selected entry corresponds to the copy you are opening.

DNS can complicate diagnosis. The VPN client may handle DNS through the tunnel, while an excluded app uses the device’s ordinary network path; exact behavior varies by implementation. A domain lookup failure is not the same as a blocked connection to an IP address. Avoid changing private DNS, custom DNS, and app routing all at once. Change one setting, reconnect if needed, and repeat the same test so that you can identify which variable mattered.

For local devices, check whether the VPN client has a separate “allow local network” option. App exclusion and local-network access are related but distinct controls: an app may bypass the VPN without gaining permission to discover a device, or a client may handle local subnets specially. Confirm that the phone and device are on the intended network and that the app has the Android permissions it needs.

• ✅ Verify whether the list includes apps in the VPN or excludes them from it.
• ✅ Test one app and one rule change at a time, then reconnect if the client requires it.
• ✅ Check work-profile copies, Android background restrictions, and local-network permissions.
• ❌ Do not assume an IP-checking page proves the route for every app or every request.
• ❌ Do not leave an app bypassed if your intention is for all of its traffic to use the VPN.

Privacy, Limitations, and Reverting Changes

Every split-tunneling rule creates a boundary between traffic that uses the VPN route and traffic that does not. An app outside the tunnel uses the network path provided by the current Wi-Fi or mobile connection, subject to Android and the network’s own behavior. That may be appropriate for a specific compatibility need, but it changes what network operators can observe about that app’s connections. A VPN does not make an excluded app private from the underlying network.

An app routed through the VPN is not automatically anonymous. The app may identify you through an account, cookies, device identifiers, or information you choose to provide. The VPN route also does not prevent phishing, malware, or unsafe permissions. Think of app routing as one network control among several, and use the smallest rule that meets your need.

Before relying on a configuration, test after a client update or a significant Android update if the app’s routing behavior matters to you. Updates can change menu labels or app-list presentation, and a profile switch can apply a different set of rules. Recheck the active profile and mode rather than assuming that a previous selection remains in effect.

To return to the default behavior, remove the selected app entries or disable split tunneling, save the profile, and reconnect. If the client still behaves unexpectedly, disconnect it, review Android’s VPN settings for another active connection, and restart the client before testing again. Keep a record of the rule you removed only if you may need to restore it; do not retain screenshots that reveal sensitive configuration details.