Android VPN Split Tunneling: Set App Rules With This Guide

Android split tunneling lets you choose which apps use a VPN connection and which connect through your regular network. It can be useful when a work app needs a VPN but a local device app does not, or when you want selected apps to use a different network route. The exact controls depend on both Android and the VPN client: one app may call the feature “split tunneling,” another may describe it as app exclusions or per-app VPN. This guide explains how to understand those options, set a rule, test what it actually does, and narrow down problems without changing several network settings at once.

Understand what Android split tunneling changes

A VPN app creates a network interface on the device and sends traffic through it according to the client’s settings. With app-based split tunneling, the client uses the apps you select to decide which traffic follows the VPN route. The rule usually applies to an app as a whole rather than to individual websites inside that app. For example, choosing a browser may route its connections through the VPN, but it generally does not mean you can send one website through the VPN and another directly using the same browser.

Most clients offer one of two selection styles. With an include selected apps rule, only the apps you choose use the VPN, while other apps use the regular connection. With an exclude selected apps rule, selected apps bypass the VPN and other eligible apps use it. These approaches can produce similar results for a small set of apps, but the default behavior is different. Read the description in the client before saving the rule; do not assume that tapping an app always means “send it through the VPN.”

Include selected apps: useful when only a few apps need the VPN. Check what happens to apps that are not selected.
Exclude selected apps: useful when most apps should use the VPN but a few need a direct connection. Check whether newly installed apps are included by default.
All apps through the VPN: this is not app-based split tunneling, even if the client provides a list of apps elsewhere in its settings.

App rules are not the same as domain rules. A per-app rule generally routes the app’s network traffic together, while domain or IP rules require a client that supports those types of routing. Similarly, Android’s system proxy setting, when present, is not necessarily equivalent to a VPN tunnel. A proxy-aware app may follow a proxy setting while another app does not. Check the selected mode and the client’s own explanation rather than inferring coverage from a single successful website.

Key distinction: First establish whether the selected apps are meant to use the VPN or bypass it. Then test both a selected app and an unselected app; testing only one side can hide a reversed or incomplete rule.

Check client support and plan your app list

Before changing settings, confirm that your Android VPN client supports app-based routing in the mode you intend to use. Some clients show app selection only after a profile is loaded or a compatible connection mode is active. Others may expose the option in a profile editor rather than on the main connection screen. The names and menu locations vary by client version, so use the client’s own help text if the control is not obvious. Do not copy instructions for a different app and assume the menus behave identically.

Make a short list of the apps that need a particular route and why. Include only apps you can identify and test. A list based on real use is easier to maintain than selecting many apps “just in case.” For instance, you might need one collaboration app to use the VPN while a local-network utility stays direct. If you are unsure which app provides a feature, check its Android app name and icon, and verify it by opening the feature after applying the rule.

✅ Write down whether each app should use the VPN or connect directly.
✅ Choose either an include-selected or exclude-selected policy and confirm its default behavior.
✅ Keep a note of the original setting so you can restore it if an app stops working.
❌ Do not select an app simply because its name sounds similar to the service you use.
❌ Do not use split tunneling to bypass your employer’s, school’s, or network owner’s access rules.

Also check Android’s VPN status before troubleshooting the app list. Android generally permits one active VPN service for a given user or profile at a time. If another VPN client, a work profile, or a security app is managing a VPN connection, it can conflict with the client you are configuring. Disconnect the other VPN service through its normal controls before testing, and follow your organization’s instructions on managed devices. A work profile can separate apps and settings from the personal profile, so selecting a personal-profile app may not control its work-profile counterpart.

Some apps include companion processes, sign-in components, or browser-based authentication that may not behave like their main screen. Avoid assuming that selecting one app will also route every related component in the same way. Start with the app you need, test its main task, and add another app only if you can identify a separate part of the workflow that needs a different route.

Set app rules on Android

Menu labels differ, but the process is broadly similar across clients. Connect to a profile only when the client requires an active connection to edit its rules. If you can edit the rules while disconnected, do so first; that makes it easier to confirm the intended configuration before traffic is routed. Keep the Android VPN permission prompt in view and approve it only for the VPN app you intended to use.

Open the VPN client. Confirm that you are editing the Android profile or connection you actually use, not an unused profile saved in the app.
Find app-based routing. Look for a control named split tunneling, app routing, app exclusions, or similar. Read the explanatory text before opening the app list.
Choose the policy. Decide whether selected apps should go through the VPN or bypass it. If the client uses an allowlist or blocklist label, check what that list allows or blocks.
Select only the apps in your plan. Use the displayed app name and icon, then review the selected list before saving. If the client offers search, use it to locate an app rather than scrolling quickly through similarly named entries.
Save and reconnect if required. Some clients apply changes immediately; others require you to reconnect or reload the profile. Follow the client’s prompt and wait for its connection status to confirm the new session.
Test both sides of the rule. Open a selected app and an unselected app and check whether each behaves as intended. Repeat the test after changing only one rule.

Use a controlled test rather than relying on a connection icon alone. If the selected app should use the VPN, check a service that can report the connection’s apparent public IP from inside that app, where practical. Then repeat with an app that should bypass the VPN. A browser-based IP check tests the browser’s route, not automatically the route used by a separate streaming, messaging, or work app. The result is meaningful only when you run the check in the app whose traffic you are trying to verify.

For a direct-route app, try the specific function that needs local access, such as discovering a device on your home network. For a VPN-routed app, try the sign-in or connection task that requires the tunnel. Record the outcome and the exact app rule. If a test fails, revert that one change before trying another. This makes it easier to distinguish a routing issue from an app outage, account problem, or ordinary network failure.

Test and troubleshoot common problems

If the result is the opposite of what you expected, first reopen the app-routing screen and check the policy type. An include list and an exclude list can look similar while producing opposite defaults. Confirm that the intended app is selected, save the rule, and reconnect if the client asks you to. Avoid changing DNS, protocol, and route settings at the same time; those changes make it harder to find the cause.

The selected app cannot connect: check whether it is meant to use or bypass the VPN, then test the other policy style only if the client’s wording is unclear. If the app is supposed to use the VPN, try another available route or profile before changing unrelated Android settings.
A supposedly excluded app still appears to use the VPN: verify that the client is in exclude mode, that the correct app was selected, and that the active profile contains the saved rule. Disconnect and reconnect to ensure the updated profile is in use.
A supposedly included app connects directly: confirm that the client is in include mode and that the app appears in the saved list. Make sure you are testing the same Android user or profile in which you changed the rule.
Only part of an app works: test the precise feature that fails. Sign-in pages, embedded browser windows, downloads, and notifications may involve different app components or connection timing. Add a companion app only when you can identify it and test the result.
Local devices disappear: check whether the VPN client has a LAN or local-network bypass setting. App exclusions and local-network access are separate controls in some clients; changing one does not necessarily change the other.
Rules stop working after an update: reopen the rule list, check whether the app is still installed under the same profile, and confirm that the client has retained the setting. Re-test after any client or Android update that changes VPN permissions or profiles.

DNS settings deserve separate attention. Android Private DNS, a browser’s secure-DNS option, and a VPN client’s DNS handling are different parts of the connection. Their interaction depends on the Android version, the client, and the app. If an app reaches the expected destination but name lookups fail, temporarily compare the app with and without the VPN and review the client’s DNS settings. Do not disable Android security features as a first response, especially on a device managed by an organization. Change one setting only when you understand what it controls, and restore the original value if the test does not help.

Battery restrictions can also affect background behavior. An app may work while open but appear disconnected when Android suspends it or limits background activity. Check the VPN client’s connection status after returning to the foreground, and consult the Android battery and background settings if the client is being stopped. Menu names vary by manufacturer. Prefer the client’s documented recommendation over broad changes that allow every app to run unrestricted.

Some apps can use network behavior that is not obvious from their main interface, and an IP check is not a complete audit of all traffic. DNS requests, a separate browser window, or background connections may follow different paths depending on the client and device configuration. Use the client’s logs or diagnostic tools when available, but do not treat a single IP result as proof that every connection from the app is routed identically.

Choose a rule you can maintain

The best rule is the simplest one that meets your need. If only a few apps require the VPN, an include-selected policy may be easier to review, provided you understand how all other apps connect. If nearly everything should use the VPN except a small number of local or network-sensitive apps, an exclude-selected policy may be more convenient. Neither choice is universally safer or faster; the right default depends on which traffic you intend to route and how carefully you can keep the list current.

Review your list when you install, remove, or replace an app, and whenever you switch VPN profiles. Recheck it after a major Android or client update if the behavior changes. If a rule is no longer needed, remove it rather than leaving an unexplained exception. Keeping a brief note of the policy, selected apps, and test results is particularly helpful if you use multiple profiles or share troubleshooting with a support team.

✅ Use the fewest app rules needed to achieve the intended routing.
✅ Verify one VPN-routed app and one direct-routed app after saving changes.
✅ Recheck the active profile and Android user when behavior differs from your notes.
❌ Do not infer an app’s route from another app’s test result.
❌ Do not leave experimental exclusions enabled if you no longer know why they were added.

Finally, remember that app-based routing controls the route, not the permissions or privacy practices of the app itself. A direct connection still uses the network available to your device, and a VPN-routed connection still depends on the VPN client, its configuration, and the app’s own behavior. If you need predictable results, make one deliberate change, test the actual task, and keep the rule list understandable.

Practical takeaway: Confirm the meaning of the app list, apply a small rule set, and test each app on its own. A clear policy and repeatable checks are more dependable than assuming the VPN toggle covers every app the same way.