Android VPN Split Tunneling: Route Apps With Simple Rules

What Android split tunneling actually changes

A VPN client on Android can establish a system VPN connection and apply routing decisions to app traffic. With app-based split tunneling, the decision is associated with installed applications rather than only with a destination such as a domain or IP address. Depending on the client, you may be able to send only selected apps through the VPN, or send most apps through it while excluding a selected group.

These two modes are easy to confuse. An “include apps” or “only these apps” option commonly means that the selected apps use the VPN and other apps connect directly. An “exclude apps” or “bypass selected apps” option commonly means that most traffic uses the VPN except for the selected apps. Read the explanatory text on the settings screen before you save the list. If the interface does not explain the effect, make a small test with one nonessential app rather than selecting many apps at once.

App selection is not the same as choosing a VPN server, changing a subscription, or setting a domain rule. It also does not guarantee that every network request made by an app follows the same path. An app may delegate work to another installed app, use a browser or system component, or rely on a separate connection setting. Some clients handle DNS and local network traffic according to additional options, so app selection should be treated as one part of the routing configuration rather than a complete explanation of every request.

Android’s VPN framework allows clients to configure application-level routing, but the controls exposed to users depend on the client and the device. A system VPN profile may provide per-app rules in one environment, while another client may keep the list inside its own settings. A managed work profile can also maintain a separate copy of an app from the personal profile; selecting one does not necessarily select the other.

Choose a routing mode for the job

Start with the task you want to accomplish, not with the longest possible app list. If just a few apps need the VPN, an include-selected-apps mode can make the intended behavior easy to review. If most apps should use the VPN and only a few need direct access, an exclude-selected-apps mode may be more convenient. The best fit depends on the client’s implementation and your own test results.

• Selected apps through the VPN: Use this when you want a short, deliberate list. Confirm that the client describes unselected apps as direct or excluded from the VPN.
• Selected apps direct: Use this when the VPN should cover the broader app set but a particular app needs the device’s ordinary network path. Check whether the client calls this bypass, exclusion, or direct connection.
• All apps through the VPN: This is usually the simplest baseline for checking whether the VPN connection works. It may not be available as a distinct choice if the client starts in an include-only mode.
• Rules by destination: If you need different routes for websites or address groups within the same app, app-based selection may not be enough. Look for a client that separately documents domain or IP routing rules.

Consider whether an app is used for a single purpose or relies on shared components. A messaging app may open links in an external browser; the browser then follows its own app rule. A media app may use an operating-system service for downloads or authentication. If the initial screen appears to work but a later action does not, test the related app separately before concluding that the main app’s rule failed.

Local devices are another consideration. Printing, casting, file sharing, and access to a router’s local interface may depend on the client’s LAN or local-network setting, not solely on the per-app list. If a local feature stops working, check whether the client has a documented local-network bypass option. Do not assume that excluding a browser or utility app will automatically create a route to every device on the Wi-Fi network.

Before selecting a mode, write down the expected result in plain language: for example, “the browser should use the VPN; the banking app should connect directly.” This gives you a testable expectation and makes it easier to notice a reversed include/exclude interpretation.

Configure and test app rules step by step

Menu names vary across clients and Android releases, so use the following process as a map rather than expecting identical labels. The controls may appear under settings such as “Routing,” “Per-app proxy,” “App filter,” “Split tunneling,” or the details of a VPN profile. The VPNGF service overview can help you distinguish the service account from the Android client that applies routing rules; the actual app-selection controls remain in the compatible client you are using.

1. Confirm the active connection. Open the client and check that it reports an active connection before changing app rules. If the client has a connection log or status detail, note any existing error first so a routing change is not mistaken for a connection failure.
2. Find the app-selection control. Open the client’s settings or the active profile’s options. Look for wording about included apps, excluded apps, bypass, or per-app routing. If you are using Android’s system VPN settings, verify that the profile shown there is the one the client currently uses.
3. Read the mode description. Establish whether checked apps are sent through the VPN or excluded from it. Some interfaces place a mode toggle above the list; others describe the meaning in a short note. Do not infer the behavior from the checkbox alone.
4. Choose one easy-to-test app first. Select one app whose connection behavior you can observe without changing account, privacy, or payment settings. Avoid editing a large group of apps until you have confirmed how the selected list works.
5. Save or apply the change. Some clients apply a rule immediately; others require you to reconnect, restart the profile, or confirm a system VPN permission prompt. Follow the client’s prompt and wait for its connection status to settle.
6. Test the selected app and a control app. Open the target app, then check an app that should follow the opposite route. Testing both helps reveal whether the selection mode was interpreted backwards or whether the change did not apply.
7. Record the result before expanding the list. Note the mode, selected app, and observed behavior. Add the remaining apps in small groups only after the basic rule works, then repeat the checks.

For a practical check, compare a request that the client can identify in its connection log, if such a log is available, with the expected route. A log entry may show that a connection matched a proxy, direct, or other outbound rule, but the exact terminology depends on the client. Avoid relying on one generic “connected” indicator: it can confirm that a VPN session exists without proving that a particular app used it.

When testing, keep other variables steady. Do not switch servers, change DNS options, and edit app rules in the same test. If you change several settings together, a successful or failed result will not tell you which change mattered. Where possible, close and reopen the target app after applying a rule, since an existing connection may persist until the app starts a new request.

• ✅ Confirm the include or exclude meaning before editing the app list.
• ✅ Test one selected app and one app expected to use the opposite route.
• ✅ Apply the rule using the client’s reconnect or confirmation prompt.
• ❌ Do not treat a connected VPN status as proof that every app uses the tunnel.
• ❌ Do not change app selection, DNS, and server settings all at once while diagnosing.

Troubleshoot rules that do not behave as expected

If an app appears to ignore its rule, check the list’s mode first. A checkbox can mean “route through VPN” in one client and “bypass VPN” in another. Reopen the settings and read the descriptive text rather than relying on a remembered convention. Also check whether the rule is attached to the active profile. A client can store separate routing settings for different profiles or configurations.

Next, check whether the app was selected in the correct Android profile. Work-profile apps, cloned apps, and manufacturer-provided dual-app features can appear as separate installations. The list may show a work-badged icon, a duplicate name, or a profile label. If the app exists in more than one profile, test the copy you actually opened and select that copy in the routing control.

If one app works but a feature inside it does not, identify which component makes the failing connection. Opening a link may hand it to a browser; sign-in may call a system web component; downloads may be handled by a separate service. Give the related component its own test rather than repeatedly toggling the main app. Similarly, a browser’s built-in secure DNS or an app-specific proxy setting can affect the observed result and should be checked independently when relevant.

Android may also have system-level VPN options that interact with the client. “Always-on VPN” and options that block connections without a VPN can prevent traffic from using a direct route, even if the client’s app list appears to exclude that app. These settings are designed to enforce connection behavior, so review them carefully before changing them. If the device is managed by an organization, some VPN controls may be set by an administrator and unavailable for personal adjustment.

Only one Android VPN service is generally active for a device at a time. If another VPN, firewall, local filtering tool, or security app attempts to create its own VPN connection, the two may conflict or one may disconnect the other. Close the competing tool during a controlled test, then restore your normal setup and check compatibility guidance from the apps involved. A per-app rule in one client does not create two independent Android VPN connections.

For a failure limited to local devices, inspect the client’s local-network or LAN handling separately from the app list. For a failure limited to name resolution, examine the client’s DNS configuration and any app-level DNS setting. For a failure after switching between Wi-Fi and mobile data, reconnect the VPN and repeat the same app test before changing the routing mode. These checks isolate different causes instead of treating every symptom as a bad server.

Reset and maintain the app list

If the rules have become difficult to understand, return to a simple baseline. Take note of the current mode and selected apps, then clear the list or restore the client’s default routing option if the interface provides one. Reconnect the VPN and confirm the baseline behavior with a small test. After that, add only the apps needed for a specific purpose and record whether each one should use the VPN or connect directly.

Some clients save application rules locally, while others associate them with a configuration profile. Updating a subscription does not necessarily preserve, replace, or synchronize those rules; behavior varies by client. Before removing a profile, reinstalling the client, or importing a new configuration, check whether the client offers an export or backup option for local settings. Do not assume that a subscription update is a backup of your app list.

Review the list when you install a replacement app, add a work profile, or change how you use a service. A newly installed app may not be selected automatically, and an updated app can rely on a different companion component. Keep the rule names understandable and remove selections you no longer need. A short, intentional list is easier to audit than a collection of old exceptions whose purpose is unclear.

When a rule still fails after resetting, test with the client’s simplest supported routing mode and consult its own documentation for the current menu names and limitations. Record the Android device profile, the client version, the selected mode, and the observed behavior when asking for support; avoid sharing private account credentials or subscription links. This information helps distinguish a client-specific limitation from a mistaken selection or a system-level VPN setting.