Android VPN Split Tunneling: Set App Rules With This Guide

Understand the two routing choices

Most per-app split-tunneling screens use one of two approaches. An include list sends only the apps you select through the VPN; apps not on the list connect directly. An exclude list sends most traffic through the VPN but lets selected apps bypass it. The labels vary: a client might say “Selected apps,” “Bypass VPN,” “Apps not using VPN,” or “Route all apps except.” Read the screen’s description carefully before changing anything.

These choices reverse the default route for apps you have not selected. With an include list, forgetting to add an app usually means that it goes direct. With an exclude list, forgetting to exclude an app usually means that it goes through the VPN. If privacy is the priority, confirm which default applies rather than relying on the list’s name or visual layout.

Per-app selection is different from a domain or website rule. An Android VPN client typically applies the rule to an app’s network traffic, not just to one website inside that app. If you exclude a browser, its connections to all sites may bypass the VPN. If you include a messaging app, the rule may affect its background connections as well as messages you send manually.

It is also different from choosing a global or rule-based mode in a proxy client. Per-app routing determines which Android apps enter the VPN connection. Rules inside a proxy client may then decide how traffic that reaches the client is forwarded. A domain rule cannot necessarily capture traffic from an app that bypasses the VPN entirely.

Check whether your client supports app rules

Before building a list, check the installed client’s settings for an app-routing or split-tunneling section. Depending on the client and Android version, the controls may appear under connection, routing, advanced settings, or a profile-specific menu. Some clients expose a list of installed apps; others provide a package-name field or a switch to bypass selected apps. Follow the instructions for the client version you actually use, because option names and supported modes can change.

Android’s VPN framework can support per-app allowlists or disallowlists, but a VPN app has to provide an interface for configuring them. The presence of a VPN connection on Android does not mean every client provides split tunneling. If you cannot find an app list, check the client’s documentation or ask its support team whether the feature is supported. Avoid installing a second VPN app just to get a different routing control: Android generally allows only one active VPN connection at a time, and switching clients can replace the existing connection.

Some Android manufacturers also add battery, background-data, or network controls that can affect an app independently of the VPN. Those controls are not a substitute for the client’s routing list. If an app behaves differently after changing a rule, check its Android network permissions and background restrictions as well as the VPN settings.

Before editing the list, write down the current mode and selected apps, or take a screenshot for your own reference. That gives you a straightforward way to restore the previous setup if an app stops working. Also decide what you want each app to do: access a private work service, use the VPN for public connections, or reach a device available only on the local network. A clear goal makes the right list easier to choose.

• ✅ Confirm whether the client uses an include list or an exclude list.
• ✅ Check what happens to apps that are not selected.
• ✅ Save a record of the existing mode and app choices before editing.
• ❌ Do not assume that a proxy rule and an Android per-app rule are the same setting.

Set and test your Android app rules

Make one change at a time, then test the specific app or service that motivated the change. This keeps troubleshooting manageable: if you change the mode, add several apps, and switch servers together, it is much harder to tell which change affected the result. These steps are a general workflow; the labels and screen order will differ between clients.

1. Choose the routing goal. Decide which apps should use the VPN and which should connect directly. If only a small number of apps need the VPN, an include list may be easier to review. If most apps should use it and only a few need direct access, an exclude list may be simpler. Neither approach is automatically safer; the default route matters.
2. Open the VPN client’s app-routing screen. Connect first only if the client requires an active profile to edit its rules. Find the installed apps list and select the appropriate include or bypass mode. If the client shows separate settings for different profiles, confirm that you are editing the profile you intend to use.
3. Check every selection before applying it. Read the app names carefully, especially when an app has a companion app or more than one entry. Select only the apps needed for your stated goal. If a client requests permission to create or manage a VPN connection, review the Android prompt and allow only the connection you intend to use.
4. Reconnect and test a direct app. Open an app expected to bypass the VPN and use a feature that makes a network request. If the app offers a connection status or account page, confirm that it can reach its service. A page loading successfully does not by itself prove which route it used, so use a route-checking method if that distinction matters.
5. Test an app expected to use the VPN. Open a browser or other selected app and check an external service that reports the public IP address. Compare the result with the expected route, bearing in mind that a site may be cached or treated differently by the app. If the client provides connection logs or per-app traffic information, check whether the request appears there too.
6. Test the real feature, then keep a record. Try the actual work connection, local device, or service that prompted the change. Once it works as intended, note the selected mode and apps so you can restore them later. A single successful test does not establish that every background request from an app follows the same route.

For example, someone who needs a local printer might first test whether it is reachable with the VPN connected, then adjust the relevant app rule only if the client’s routing setup is blocking that connection. If the cause is a separate local-network setting, excluding an entire app may be broader than necessary. In the same way, an app that needs a direct connection for one service may also send unrelated traffic; an app-level exclusion can affect all of that app’s network activity.

If you are comparing a direct route with a VPN route, keep the test consistent. Use the same app and feature, change only the relevant routing rule, and reconnect if the client requires it. The YiYiVPN homepage can help you identify the service context before you choose a setup, but the final behavior still needs to be checked in your Android client and the app you use.

Understand privacy, DNS, and local-network effects

An app excluded from the VPN can connect using the network path provided by the phone’s current Wi-Fi or mobile connection. Its destination services may therefore see the public IP address associated with that direct connection rather than the VPN exit address. If your reason for using the VPN is to keep a particular app’s traffic on that route, do not exclude it without checking the consequence.

DNS behavior needs careful interpretation. A VPN client may handle DNS as part of its tunnel, while an excluded app may use the device’s normal network path. The exact behavior depends on the client, Android version, and how the app makes its requests. A browser-based DNS test only reports what happened for that test; it cannot prove how every other app resolves names. If the client offers DNS or connection logs, use them alongside an app-specific test rather than treating one webpage as a complete audit.

Android routes VPN traffic at the app level, but an app can rely on system components, embedded web views, or companion apps for parts of its activity. The list may show the main app without making every related component obvious. A sign-in screen opening correctly does not necessarily show that the app’s background service uses the same route. Test the specific feature that matters, including notifications or syncing if those are part of your use case.

Local-network access is another separate concern. A VPN connection can alter how traffic reaches devices on the same Wi-Fi network, but app exclusions are only one possible remedy. Look for a client option that specifically allows local or LAN access, if available, before excluding an app that should otherwise use the VPN. On a trusted network, a direct local connection may be useful; on an unfamiliar network, it is worth considering whether that exception is appropriate.

Some Android configurations can block traffic when the VPN is unavailable, particularly when Android’s always-on VPN or “block connections without VPN” controls are enabled. An excluded app may not behave as expected under those settings, because the system may enforce a broader rule than the app list. Review Android’s VPN settings and the client’s own documentation before combining lockdown controls with bypass rules. Do not assume that an app exclusion guarantees direct access if a system-level block is active.

Troubleshoot or undo a routing change

If an app cannot connect after you edit the list, first identify whether it was supposed to use the VPN or bypass it. Reopen the routing screen and check the mode, selected app, and active profile. A common mistake is applying an exclusion while thinking the list contains apps that should use the VPN, or changing a profile that is not currently connected.

Next, restore a known starting point. Remove the last app you added or return to the saved mode, reconnect the VPN, and test again. If the app works after restoring the previous configuration, the new rule is likely involved. If it still fails, temporarily test without the VPN only when appropriate for your security needs, then reconnect and compare. Avoid leaving a temporary direct connection enabled if the app is expected to use the VPN in normal use.

• App fails only when excluded: Put it back on the VPN route and test the feature again. The service may require a network path that differs from your direct connection.
• App fails only when included: Check whether the app can operate through the selected server and whether the client shows a connection or DNS error. Try restoring the prior route before changing other settings.
• Local device is unreachable: Check the client’s local-network or LAN option and confirm that the phone and device are on the expected network. An app rule may not be the most precise fix.
• Notifications or syncing stop: Review Android battery and background-data restrictions, then check whether a related app component needs network access. Do not assume the foreground app is the only process involved.
• Nothing matches the expected route: Confirm that the VPN is connected, the correct profile is active, and the target app is actually selected. Use client logs or a suitable route test instead of relying only on the connection badge.

To undo the change completely, restore the original include or exclude mode, clear the changed selections, and reconnect if required by the client. Then test one app that should use the VPN and one that should connect directly. If the client has a reset option, read what it resets before using it; it may clear other profile settings as well as app rules.

Keep the rule set as narrow and understandable as possible. A small list is easier to verify, explain, and restore than a collection of exceptions added to solve unrelated issues. Recheck it after switching profiles, reinstalling an app, or changing VPN clients, because saved selections and app identifiers may not carry over in the way you expect.