Android VPN Split Tunneling: Set App Rules for Proxy or Direct

Android VPN split tunneling lets you choose which apps send traffic through a VPN connection and which apps keep using the device’s regular network. It can be useful when some apps need a different exit region or an encrypted tunnel, while local services, banking apps, or devices on your home network work better with a direct connection. The exact controls depend on the VPN client: some offer an app list, some expose include or exclude rules, and others provide only domain- or IP-based routing.

Before changing anything, check whether your client actually supports per-app routing on Android. A VPN subscription or protocol does not determine whether the feature appears; it is generally a capability of the client and its Android VPN implementation. Names also vary: look for terms such as “Split tunneling,” “Per-app proxy,” “App routing,” “Included apps,” or “Excluded apps.” If none appears, do not assume that a system setting or a different node will provide the same control.

How Android app routing works

On Android, many VPN clients create a local system tunnel using Android’s VPN framework. When the connection is active, the client can direct eligible traffic through that tunnel. Per-app split tunneling adds a selection layer: depending on the client’s design, you choose apps that are allowed through the tunnel, or apps that should bypass it. The client then applies that selection while the tunnel is running.

These two list styles are easy to confuse. An “include” or “VPN apps only” list usually means that listed apps use the tunnel and other apps go direct. An “exclude” or “bypass these apps” list usually means that listed apps go direct and the remaining apps use the tunnel. However, labels and defaults are not standardized, so verify the client’s own description before saving. A wrong assumption can reverse the result for every app.

Per-app routing is not the same as choosing a proxy node. A node controls the route or exit used by traffic that enters the tunnel; an app rule controls which apps enter it in the first place. Likewise, global, rule-based, and direct modes may be separate controls. A client can have an app list and a global mode, but the mode may affect or override the list. Check both settings rather than treating the app selection as the only routing control.

App selection is usually based on Android package identity rather than a screen name typed by the user. Some clients show installed applications with icons; others may list work-profile apps separately or display only apps they can discover. If an app is missing, first check whether it is installed in a different Android profile, has been disabled, or was installed after the client loaded its app list. Refresh or reopen the list before assuming the app cannot be routed.

Also distinguish the client’s routing configuration from Android’s own VPN controls. Android may let you designate an always-on VPN or block connections when no VPN is active. Those system options govern the device’s VPN behavior, not the meaning of a particular client’s app list. If a client’s split-tunnel rules conflict with an always-on or lockdown configuration, an app intended to go direct may be blocked rather than allowed onto the regular network.

Choose which apps use the VPN

Start by describing the desired result in plain language. For example: “These selected apps must use the VPN; all other apps should stay direct,” or “Most apps use the VPN, but these named apps should stay direct.” That sentence tells you whether to look for an include list or an exclude list and helps prevent a reversed configuration.

Then consider how each app behaves. An app may use more than one network component: the visible app, a companion service, a browser opened from a notification, or a background process can make separate connections. A rule for one app does not necessarily cover a different app that handles sign-in, media playback, links, or notifications. If an app’s behavior changes only in the background, inspect the relevant companion apps and Android profile as well as the main app.

• ✅ Use an include list when only a clearly defined set of apps should enter the tunnel.
• ✅ Use an exclude list when most apps should use the tunnel and only a few should bypass it.
• ✅ Read the client’s explanation of what happens to unlisted apps before applying the selection.
• ✅ Keep local-network or work-profile requirements in mind when deciding whether an app should go direct.
• ❌ Do not assume that selecting a destination node automatically selects which apps use it.
• ❌ Do not add every app to a list just to make the configuration look complete; list behavior differs by client.

Direct routing can be appropriate for an app that needs to communicate with a local printer, a home device, or a service that expects the network connection available on the device. It may also be useful when an app behaves poorly through a proxy route. On the other hand, bypassing the tunnel means that app’s network traffic uses the ordinary connection, subject to the network and service in use. Do not put an app on a bypass list if your reason for using the VPN is to keep that app’s traffic within the tunnel.

For apps that should use the VPN, remember that “selected” does not guarantee that every connection will succeed. The app still needs working network access, the client must have a usable connection, and the route must support the traffic the app requires. Some services make requests to multiple hosts or use embedded components, so a destination-based rule can behave differently from a package-based app rule. If a client offers both kinds of control, test one method at a time to identify which layer is responsible for the result.

Configure and test the rules

The steps below use generic interface names because Android clients arrange their settings differently. Keep your current selection in mind or note it before editing, especially if you already have routing rules that work. Change one setting at a time so that you can identify what actually affected the connection.

1. Open the client’s routing settings. Start the VPN client and look for per-app, split-tunneling, or application-routing controls. If the feature is not present, check the client’s help information or settings search rather than changing unrelated protocol or node options.
2. Identify the list mode. Read whether the list contains apps that use the VPN or apps that bypass it. If the wording is unclear, do not save a large selection yet. Look for a short description, an information icon, or an explicit option such as “Only selected apps” or “Exclude selected apps.”
3. Set a small, recognizable test group. Choose one app that should use the tunnel and, if needed, one app that should remain direct. Avoid changing several unrelated routing settings at the same time. A small test makes it easier to spot a reversed list or an unexpected default.
4. Save the selection and reconnect if requested. Some clients apply changes immediately; others require the VPN connection to restart. Follow the client’s prompt. If no prompt appears but the old behavior remains, disconnect and reconnect once before troubleshooting more broadly.
5. Confirm the tunnel state in Android. Check that the client reports a connected state and that Android shows the VPN indicator when the client is expected to be active. This confirms that a tunnel is running, but it does not by itself prove that a particular app is using it.
6. Test each selected app separately. Open the app and perform the action that normally needs network access. If the client provides per-app traffic information or logs, use it to see whether the app generated traffic through the tunnel. Do not infer routing solely from an app loading screen or from the VPN indicator.
7. Verify the direct app and the VPN app independently. Use a suitable connection or exit check from the app or browser being tested, if the client and service make that information available. A browser’s result describes that browser’s traffic; it does not prove how a separate app is routed. Compare the result with the intention of your rule, not with an assumption that every app shares the same route.
8. Restore the intended full selection. After the test, add the remaining apps or remove temporary selections, save again, and repeat a brief check. If the result is worse, restore the note you made before editing rather than changing several settings at random.

For a reliable test, make sure the app is not simply displaying cached content. Trigger a network-dependent action, such as refreshing content or loading a page that was not already open. If the client offers logs, inspect the relevant timestamp and app entry. Avoid sharing logs that contain account identifiers, server addresses, subscription data, or other credentials; redact sensitive information before asking for support.

Network checks can also be misleading if the app delegates a task to another app or a system service. For instance, tapping a link may open a browser, and that browser follows its own app rule. A sign-in flow may use an external browser or a system component. Test the app’s own traffic separately from the component it launches, and add a second app to the routing list only when you have confirmed that it needs a different route.

DNS, local networks, and Android settings

Per-app routing concerns which app’s traffic is sent through the tunnel, but name resolution and local-network behavior can involve additional settings. DNS requests may be handled by the VPN client, the Android system, or a configured resolver, depending on the client and connection mode. Therefore, an app that appears to use the intended route can still fail to resolve a name, and a successful browser lookup does not prove that every app uses the same resolver.

When a hostname fails but a direct connection works, avoid immediately changing several DNS or routing controls. First confirm whether the problem affects only one app or multiple apps, whether the VPN itself remains connected, and whether the client reports a resolution or connection error. If the client has separate DNS settings, read their descriptions and change only the setting relevant to the observed symptom. A domain-based route and an app-based route may also interact, so note which rule you changed.

Local devices introduce another distinction. A phone may be connected to Wi-Fi and still have its traffic routed through a VPN tunnel. Access to a printer, media device, router page, or other local service can depend on the client’s LAN-access option and Android’s network handling. If only local access fails, test that behavior separately from internet access. Do not disable the whole tunnel as a permanent workaround if your goal is to keep selected apps on the VPN; look for a narrowly scoped local-network option in the client.

Android battery management can affect a VPN client that is paused or closed in the background. If the connection drops after leaving the client or locking the screen, check the client’s connection state and Android’s battery or background-activity settings. Menu names vary by Android version and device manufacturer. Change only the restriction that applies to the VPN client, and avoid disabling system protections for unrelated applications.

Android can generally maintain one active system VPN connection at a time. If another VPN app, security tool, or filtering app tries to create its own VPN connection, Android may ask you to disconnect the existing one or the clients may compete for the same system tunnel. Close or pause the competing connection before testing split tunneling. This is different from using a proxy feature inside a browser, which may have its own app-specific behavior and may not control traffic from other Android apps.

Always-on VPN and “block connections without VPN” settings deserve particular care. They can be useful when you want traffic blocked whenever the tunnel is unavailable, but that goal conflicts with apps that are supposed to use a direct connection. If a bypassed app cannot connect, inspect these Android-wide controls as well as the client’s list. Do not turn off a security restriction without understanding the trade-off; decide first whether that app should be permitted to use the ordinary network.

Troubleshoot without losing your setup

When an app does not behave as expected, identify the scope before changing the configuration. Is the problem limited to one app, every app on the VPN, only apps marked direct, or only local services? Is the tunnel connected, and did the client ask for a restart after the rule change? These observations narrow the cause more effectively than reinstalling the client or importing the subscription again.

• ✅ If all VPN-selected apps fail, check the connection state, selected node, and client error before editing per-app rules.
• ✅ If one selected app fails, confirm that the app is actually on the include list and that its required companion components are not being routed differently.
• ✅ If a direct app is blocked, check whether the list is an exclude list and whether Android’s always-on or lockdown behavior blocks non-VPN traffic.
• ✅ If local devices fail but internet access works, inspect LAN access and local-network handling rather than switching every app to direct.
• ✅ If the app works only while the client is open, inspect background restrictions and whether the VPN remains connected after the screen is locked.
• ❌ Do not run multiple VPN clients simultaneously while trying to isolate a routing issue.
• ❌ Do not publish a subscription link, authentication details, or an unredacted diagnostic log while requesting help.

If the app list looks correct but results remain inconsistent, review broader routing modes next. A global direct mode can prevent app rules from using the tunnel; a global VPN mode can route more traffic than expected. Some clients also apply domain or IP rules before or alongside app rules. Restore a known working mode, reconnect, and test again before altering protocol settings. The purpose is to isolate the layer responsible, not to make unrelated changes until the symptom disappears.

Updates can also change the available labels or behavior. After a client update, revisit the split-tunneling screen and verify the list mode rather than assuming that a saved selection has the same meaning. If the client supports exporting or backing up its configuration, use that feature before making broad changes and store the backup privately. A screenshot of the rule screen can help you remember a selection, but hide account names and any sensitive connection details before sharing it.

Finally, distinguish a routing failure from an app’s own policy. Some services may reject a connection for reasons unrelated to whether it is direct or tunneled, and a different app or destination can behave differently on the same Android device. Test with the same app action under a clearly recorded configuration, then compare the result after changing only one rule. If you contact the client or service provider, include the Android version, client version, selected routing mode, and the exact symptom. Do not include your subscription address or password.