Android split tunneling lets you choose which apps send traffic through a VPN connection and which connect directly. It is useful when only a few apps need a different network route, or when a local app works better without the tunnel. The setting is usually controlled by the VPN client, not by Android’s ordinary Wi-Fi settings, and the labels differ between clients.
The important part is understanding the rule before you save it. “Only selected apps use the VPN” and “all apps use the VPN except selected ones” sound similar, but they produce opposite results. This guide explains how to choose between them, set the rule, and check what actually happened.
Understand the two rule modes
Most Android VPN clients offer one of two per-app modes. Depending on the client, these may be labelled include apps, only selected apps, exclude apps, or bypass selected apps. Read the explanatory text on the settings screen rather than relying on the label alone: different apps sometimes use different wording for the same behavior.
- Include selected apps: apps on your list use the VPN; other apps generally use the device’s ordinary network connection.
- Exclude or bypass selected apps: apps on your list connect outside the VPN; other apps generally use the tunnel.
Think of the list as a routing rule, not a way to choose a server for each app. The selected apps are directed either into or outside the VPN connection. A per-app rule normally applies to an app’s network traffic as a whole; it does not usually let you route one website inside an app through the VPN and another website outside it.
2 modes
Include selected apps or bypass selected apps
1 tunnel
Android normally uses one active VPN service per user or profile
Per app
Rules target apps, not individual websites inside an app
Before changing a rule, write down the result you want in plain language. For example: “the browser and streaming app use the VPN; banking and local-network apps connect directly.” Then choose the mode that describes that outcome. If you start from the wrong mode and merely add the apps you care about, you can accidentally send the opposite group through the tunnel.
Also remember that app-based routing is not the same as a browser proxy, a DNS filter, or a firewall. An app that uses a separate companion process or hands a task to another app may involve more than one package. If the client’s list shows both the main app and a related service, check its documentation before assuming that selecting just one will cover every connection.
Choose apps and check the trade-offs
Build the list around the specific problem you are solving. A small, intentional list is easier to test and maintain than a long list assembled by trial and error. Decide first which apps need the VPN and which need a direct connection, then select the corresponding include or bypass mode.
- For selected apps through the VPN: use include mode and choose only the apps that need the tunnel. Check that any app required for sign-in, media playback, or a handoff is included too.
- For selected apps outside the VPN: use bypass mode and choose only the apps that should use the ordinary connection. Keep the rest covered by the VPN if that is your intended default.
- For local-network access: first check whether the client has a separate local-network or LAN option. App bypass may be broader than necessary, because it can direct all traffic from that app outside the tunnel, not just traffic to a printer or local device.
- For work or managed apps: check whether a work profile, device-management policy, or always-on VPN controls the route. A personal-profile setting may not govern apps installed in a separate work profile.
There is a real privacy and reliability trade-off. In bypass mode, the chosen apps do not receive the VPN’s tunnel route. That may help an app reach a local service or behave as expected on the direct connection, but it also means its network traffic is not carried by that VPN. In include mode, apps omitted from the list may connect directly, so do not assume that every app is protected simply because the VPN indicator is visible.
For a simple setup, use the VPN client’s own per-app control and avoid running multiple VPN-style apps at the same time. Android generally allows one active VPN service per user or profile; starting another VPN client can disconnect or replace the first one. A firewall, filtering app, or work-profile VPN may also affect what you see, so temporarily simplify the setup while diagnosing an unexpected result.
If you are comparing client options or checking which platforms and network features are available, the VPNWu home page is a useful place to start. The routing behavior still depends on the Android client you actually use, so confirm that client’s wording and available controls before importing or changing a configuration.
Set the rule on Android
The exact screens vary across official VPN apps and compatible clients, but the workflow is usually similar. Make the change while the VPN is disconnected if the client does not allow editing its app list during a session. Keep the client open so that you can see whether it applies the updated configuration after saving.
- Open the active VPN profile. In the client, select the profile or subscription you normally connect with. If there are several profiles, make sure you are editing the one that is actually in use.
- Find per-app routing. Look in settings for a section called split tunneling, app routing, app filter, included apps, or excluded apps. It may be under a profile’s advanced options rather than the main settings screen.
- Choose the mode first. Decide whether the list means “these apps use the VPN” or “these apps bypass the VPN.” Read any note shown beside the selector. Do not start selecting packages until the mode is clear.
- Select apps deliberately. Search or scroll the installed-app list and select the intended apps. Some clients show a checkbox, while others place apps into separate allow and bypass lists. Check for duplicate entries or similarly named apps, especially when a work profile is present.
- Save or apply the change. Use the client’s save, confirm, or apply control. If it says the profile must be reconnected, disconnect and reconnect rather than assuming the current tunnel has already picked up the new rule.
- Run a controlled test. Test one app that should use the VPN and one that should bypass it. Keep the test focused: open the app, perform the action that previously failed, and compare the result with the expected route.
Some clients provide an application picker based on Android’s installed packages. If an app is missing from the list, check whether it is disabled, installed only in another user or work profile, or represented by a companion app. Installing or updating an app can also change the available package list. Reopen the picker or restart the client before concluding that split tunneling is unsupported.
Do not change several unrelated options at once. First establish that the VPN connects normally with the default rule. Then change the per-app mode, select the apps, reconnect if requested, and test. If the result is wrong, you will know which change to undo instead of having to guess whether the problem came from a server, DNS setting, protocol, or app rule.
Verify which route each app uses
A VPN key icon or a “connected” status confirms that a VPN service is active; it does not prove that every app uses the tunnel. Verify the intended behavior at the app level. Choose an app you placed in the VPN group and another you placed in the bypass group, then test them separately while the rule is enabled.
- Check the client first. Confirm that the correct profile is connected and that the saved app list still shows the intended mode and selections.
- Check the app’s behavior. Open the selected app and repeat the action that matters, such as loading a service or reaching a local device. A cached page or an already-open session is weak evidence; refresh or start a new connection.
- Compare the two groups. Test at least one app intended for the tunnel and one intended to bypass it. If both behave the same way, that may be correct for the service you are testing, but it can also indicate that the mode or profile is not the one you intended.
- Repeat after reconnecting. If the client applies rules only when a tunnel starts, disconnect and reconnect, then retest. A result from before the rule was applied does not validate the saved setting.
Network checks need careful interpretation. An app may use cached data, its own encrypted DNS, a system service, or a companion package, so a single website result cannot always identify the route for every connection. Likewise, a public IP check in one browser only describes that browser’s request; it does not automatically tell you how a different app is routed.
If you need to confirm an app’s public route, use a test the app itself can perform or a service you trust, and compare results only after starting a fresh request. Avoid treating location-based content alone as proof: an account region, app cache, device location, or service policy can affect what appears without changing the network route.
A reliable check has three parts: confirm the correct profile is connected, verify the app’s saved include-or-bypass assignment, and test a fresh connection from that app. The VPN status icon alone is not enough to validate per-app routing.
Fix common split-tunneling problems
When an app does not follow the rule, work from the simplest checks to the less obvious ones. Avoid deleting a profile or changing protocol settings until you have confirmed the selected mode and the active profile.
The wrong apps use the VPN
Reopen the split-tunneling screen and read whether the selected list is an include list or a bypass list. A list of selected apps has no fixed meaning unless you know which mode is active. Confirm that the profile you edited is the one connected, save the setting, and reconnect if the client requires it. If the result is still inverted, switch modes only after recording the current selections so you can restore them.
An app stops working after being bypassed
First confirm that the app really is supposed to use the direct connection. Some apps may depend on access to a service or route that is unavailable on the current network. Remove that app from the bypass list for a controlled test. If it works through the VPN but not directly, the difference points to the network path or the service’s access policy rather than proving that the app itself is broken.
A local service is still unreachable
Check whether the client has a dedicated LAN-access setting before bypassing an entire app. Also verify that the phone and local device are on a network that permits communication between them; guest Wi-Fi and network isolation can block local access regardless of the VPN rule. If you test app bypass, remember that it changes the route for that app’s traffic more broadly than simply allowing access to one local address.
Android shows a VPN warning or reconnects
Review Android’s system-level VPN settings as well as the client. Always-on VPN and “block connections without VPN” options can restrict traffic that the client is trying to bypass. Their labels and availability vary by Android version and device manufacturer. If you intentionally need direct traffic for selected apps, check whether those system restrictions conflict with that design; do not disable a security control unless you understand the effect.
Also check for another VPN client, firewall, private DNS configuration, or managed work profile. Change one setting at a time, then reconnect and test again. If the problem appears only on a particular network, compare it with another network where the VPN can connect normally; that helps separate a per-app rule problem from a network-specific restriction.
The app is missing from the picker
Refresh the app list, restart the VPN client, and confirm that the app is installed in the same Android user or profile where the VPN is active. Work-profile apps can be separate from personal-profile apps even when their icons look alike. If the app delegates connections to another installed component, check the client’s guidance for whether that component also needs a rule.
- ✅ Confirm the active profile before editing its app rules.
- ✅ Read whether the list includes apps or bypasses them.
- ✅ Reconnect after saving if the client asks you to apply the change.
- ✅ Test one app from each intended routing group with a fresh request.
- ❌ Do not assume the VPN icon means every app is using the tunnel.
- ❌ Do not run competing VPN clients while diagnosing per-app routing.
- ❌ Do not bypass an entire app when a narrower LAN-access option would solve the problem.
Once the rules work, keep a short note of which apps are included or bypassed and why. Revisit the list when you install a replacement app, change Android profiles, or update the VPN client. That small check prevents an old exception from silently becoming the default behavior you did not intend.