Android VPN Split Tunneling: Set App Rules the Easy Way

What Android app-based split tunneling does

Android app-based split tunneling lets a compatible VPN client apply different network routes to different apps. You can send selected apps through the VPN while leaving other apps on a direct connection, or—in clients that offer the inverse rule—send only selected apps through the VPN and route everything else directly. The exact choices and labels vary by client, Android version, and configuration.

This is an app-level routing choice, not a promise that every connection from a particular app will behave identically. An app may use another app or Android component for sign-in, downloads, notifications, or links. Those connections may follow their own routing rules. A browser opened by a shopping app, for example, might be a separate browser process with a separate rule. Check each app involved in the task rather than assuming one selection covers an entire workflow.

Split tunneling can be useful when a work tool needs a particular route but a local device app needs to reach nearby devices directly, or when only selected apps should use an international connection. It is not the same as choosing a VPN server, changing an app’s account region, or resolving an app-side restriction. If a service does not permit access from your location or account, changing the network route may not make it available.

Think of each rule as a routing decision, not an app permission. The rule does not grant an app new access to your files or account, and it does not guarantee that the app will use the route you intended. The app still needs to be compatible with the selected network path, and the VPN itself must be connected.

Check the client and Android settings first

Before changing rules, confirm that your Android VPN client actually supports per-app routing. A subscription provides connection and configuration details; it does not determine which app features appear in a particular client. Open the client’s settings and look for a feature such as “Per-app VPN,” “App routing,” “Include apps,” or “Exclude apps.” Names and menu locations differ, and some clients offer only global routing.

Make a short list of the apps that must use the VPN and those that should remain direct. Start with only the apps needed for one task. If you add many apps at once, it becomes harder to identify which rule caused a sign-in, notification, or connection problem. Record the current mode and selected apps before editing so you can restore the original configuration.

• ✅ Confirm that the VPN is connected and that the client exposes app-level routing controls.
• ✅ Decide whether the client’s list means “send these apps through the VPN” or “bypass the VPN for these apps.”
• ✅ Check whether the app exists in a work profile, secure folder, or cloned-app environment.
• ✅ Note any Android Always-on VPN or lockdown setting before changing the client rules.
• ❌ Do not assume that a checked app is included; in an exclusion mode, checked apps may instead use a direct route.

Android may show separate instances of an app in a work profile or another managed space. A personal-profile selection may not automatically apply to the matching work-profile app. Some apps also rely on Android system components that cannot be selected individually. If an app is missing from the list, update the client and check its documentation before trying to change system packages or install an alternate copy.

Check whether another VPN app is already active. Android generally relies on one active VPN service for a user or profile at a time, so a second VPN client may disconnect, replace, or conflict with the first. Pause other VPN-based tools before testing, including security or filtering apps that create a local VPN connection. Do not run multiple clients simultaneously to try to combine their rules.

Set app rules step by step

Use the client’s own per-app controls rather than trying to reproduce the same behavior with Android’s general network settings. The wording below describes a common workflow, not a fixed menu path: manufacturers and client versions can arrange settings differently. If you are reviewing the available platform and subscription information before configuring a device, the VPNGD homepage is a useful place to start.

1. Connect the VPN first. Confirm that the client reports an active connection. This gives you a known starting point and helps distinguish a routing-rule issue from a failure to connect.
2. Open the app-routing control. In the VPN client, open Settings or Connection settings and find the per-app section. If you cannot find it, check the client’s built-in help or version notes; do not assume every Android client has the feature.
3. Read the mode description carefully. Determine whether the list includes apps in the VPN route or excludes them from it. Some clients let you choose between an allowlist and a bypass list. The same selected app can therefore have opposite results in different modes.
4. Select a small test group. Add one app that should use the VPN. If you also need a direct-route app, add just one such app and verify it separately. Avoid changing several unrelated apps in the first test.
5. Save or apply the configuration. Some clients apply rules immediately; others reconnect or restart the VPN tunnel. Follow the client’s prompt and wait until it shows a connected state again.
6. Test the selected apps individually. Open each app, perform the activity that needs the route, and check that it completes. Then test an app expected to stay direct. Close and reopen an app if it keeps an existing connection alive from before the rule change.
7. Keep a rollback path. If the test fails, return to the app list, remove the last change, and reconnect. If you cannot identify the problem, restore the recorded original mode and selections before making another change.

When a client offers separate controls for included and excluded apps, use only the mode that matches your intended policy. Do not create a long include list and a contradictory bypass list unless the client explicitly explains how it resolves overlaps. If the interface does not state which rule takes priority, keep the configuration simple and ask the client provider for clarification.

After an Android update or a client update, review the rule list again. App names can change, an app may be reinstalled under a different profile, or the client may reset a setting. A saved list is not proof that each app still follows the intended route.

Verify the route with real app behavior

A connection indicator in the VPN client confirms that the tunnel is active, but it does not by itself confirm that every app is using the route you expect. Test from the target app and the relevant profile. If the app has a built-in connection check or displays which account or service it reached, use that information alongside the VPN client’s status.

For a browser-based check, use a browser that is actually included in the VPN rule. A result from one browser cannot prove that a separate email, messaging, or work app uses the same route. Likewise, a web page opened inside another app might use the browser’s route rather than the originating app’s rule. Compare results only after identifying which application made the network request.

Also test the direct-route apps while the VPN remains connected. Confirm that the specific feature you need works, not just that the app opens. Local-device discovery, casting, printers, and services on a home network can depend on local routing or multicast behavior that an app-level bypass does not necessarily fix. The client may route the app directly while Android or the local network still blocks a separate connection.

For sensitive accounts, follow the service’s own access guidance and use a trusted network. If a bank or employer flags a sign-in, do not repeatedly switch routes to work around its security checks. Confirm the account’s official requirements and contact its support team when needed.

Troubleshoot problems and restore normal connectivity

If an app stops working after a rule change, first determine whether the problem affects one app or the whole device. If every app loses access, check the VPN connection and the underlying Wi-Fi or mobile data connection. If only one app fails, temporarily remove its rule or switch the client back to its previous mode, then reconnect and test again.

• Nothing works after enabling the rule: Confirm that the VPN is connected, verify that you did not select a mode that sends all unlisted apps to a route they cannot use, and check whether another VPN service was disconnected.
• The wrong app uses the VPN: Recheck whether the list is an include list or an exclusion list. Look for a duplicate instance in a work profile or secure folder, and confirm that you selected the correct entry.
• An app opens but a feature fails: The app may use a separate sign-in, browser, download, or notification component. Test those parts individually and consult the client’s notes on system-app handling.
• A local device disappears: Check whether the app is on a direct route and whether local network access is supported by the VPN client. App exclusion alone may not restore every local discovery method.
• The app list does not save: Reopen the settings after reconnecting, check for a pending Apply or Save action, and make sure the client has the required Android VPN permission.

Android’s Always-on VPN and “Block connections without VPN” or lockdown options need particular care. Depending on Android and client behavior, a lockdown policy can block traffic that is not carried by the VPN—including apps deliberately excluded by a split-tunnel rule. If an excluded app cannot connect, check the Android VPN settings and the client’s explanation of lockdown compatibility. Do not disable a protection setting on a managed device or a device subject to workplace requirements; ask the administrator or follow the organization’s policy.

To return to a simpler setup, open the client’s app-routing settings, restore the mode and selections you recorded, apply the change, and reconnect. If the original state is unknown, turn off app-specific routing using the client’s documented control, then verify ordinary connectivity before recreating any rules. Avoid clearing app data or resetting network settings as an early troubleshooting step: those actions may remove saved credentials or other useful configuration without addressing the routing problem.

When reporting a persistent issue to the client provider, include the Android version, client version, whether the affected app is in a personal or work profile, the selected routing mode, and the steps that reproduce the failure. Do not send passwords, authentication codes, or private account details. A clear description of the rule and the app’s behavior is more useful than a screenshot containing sensitive information.

Use simple rules and review them over time

App-based routing is easiest to maintain when each rule has a clear purpose. Start with the smallest set of apps that needs a different route, document why each one is there, and revisit the list when you remove an app or change how you use the device. A rule left behind after a temporary test can affect future sign-ins or expose traffic to a route you no longer intended.

• ✅ Use app rules to solve a specific routing need, then verify the behavior in the app itself.
• ✅ Keep separate notes for personal and work-profile apps when both are involved.
• ✅ Recheck the selected mode after updating or reinstalling the VPN client.
• ✅ Restore the previous configuration if the cause of a problem is unclear.
• ❌ Treat app routing as a substitute for account permissions, local network configuration, or service support.
• ❌ Assume that every background service, embedded browser, or system component inherits the parent app’s route.

The practical choice is not “VPN for everything” versus “VPN for nothing.” Decide which apps need the VPN route, which ones must stay direct, and whether your client and Android settings can support that split safely. Then make one change at a time and test both expected paths. If the results remain unclear, return to the simplest working configuration and check the client’s documentation before adding more rules.