Android Split Tunneling Guide: Set App Rules Without VPN Slowdowns

Android split tunneling lets you decide which applications use the VPN route and which applications continue through the ordinary network. This is useful when one phone needs international access for selected services while local banking, payment, casting, smart-home, or workplace applications should remain direct. It can also reduce unnecessary traffic through the VPN route, but only when the app rules, capture mode, and DNS behavior are understood together.

A full-device route is simple: the client attempts to capture most supported traffic and applies one general policy. Split tunneling is more selective. Depending on the Android client and its VPN implementation, you may see options such as “VPN apps only,” “Bypass selected apps,” “Allow LAN traffic,” or “Per-app VPN.” The wording differs, but the decision is similar: create either an allowlist of apps that use the VPN or a bypass list of apps that do not.

The most important distinction is between an application rule and a domain rule. Selecting an app normally affects connections created by that package, including its background requests when the client can identify them. It does not necessarily cover a website opened in another browser, an external login window, a download manager, or a second app used by the same service. Conversely, a domain rule can affect several apps but may not control connections made directly to an IP address. Start with the application boundary, then investigate domains only when the app-level result is incomplete.

Choose the right Android routing mode

Before adding app rules, identify the direction of the setting. An allowlist means only the apps you select use the VPN. A bypass list means most captured apps use the VPN except those you exclude. These two modes can produce opposite results even when the same applications are selected. Many configuration mistakes happen because a user chooses several apps under a bypass setting while expecting those apps to be the only ones using the VPN.

Allowlist or bypass list: which should you use?

Use an allowlist when you can name the applications that need the VPN and want the smallest possible change to the rest of the phone. This is usually easier to audit. For example, you might place one browser, one work application, and one messaging application in the VPN list, while leaving payment and local-service apps direct. If a new application later needs the VPN, add it deliberately rather than allowing every application by default.

Use a bypass list when most of your traffic benefits from the VPN and only a few applications must stay direct. This can be convenient for a travel device or a phone used mainly with international services. However, review the list after installing new applications. Android packages may include separate companion apps, and a service can move authentication, media, or payment tasks into another package.

• ✅ Use an allowlist when only a small number of apps need the VPN.
• ✅ Use a bypass list when most supported apps should follow the VPN.
• ✅ Write down the intended mode before selecting packages.
• ❌ Do not assume the words “selected apps” explain whether selected apps use or avoid the VPN.
• ❌ Do not change several routing settings at once before testing the result.

Set Android app rules step by step

The exact labels depend on the official Android client or compatible client you use. MeeVPN supports Windows, macOS, iOS, Android, and Linux, while subscription links may also be imported into compatible tools that support the relevant configuration format. On Android, the client normally creates an Android VPN profile and asks for permission to establish a VPN connection. Only one VPN service can normally control the Android VPN interface at a time, so close or disable other VPN applications before testing.

Prepare the client and subscription

1. Install the Android client from a trusted source and open it.
2. Sign in or complete the account setup, then locate the subscription or remote-configuration area.
3. Import the subscription link through an option such as “Import from URL,” “Add subscription,” or “Remote configuration.”
4. Update the subscription and confirm that route groups or nodes are visible.
5. Select one route before changing app rules. Start with a known working configuration rather than troubleshooting routing and subscription import at the same time.

A subscription link is a sensitive configuration credential. It may allow a client to retrieve route addresses, ports, protocols, and authentication parameters associated with the account. Do not paste it into a public note, send it in a group chat, or include it in screenshots. If a client shows no routes after import, confirm that the link was copied completely and that the selected client supports the supplied format. Reinstalling the app will not correct an incomplete link or an unsupported format.

Configure the application list

1. Open the client’s routing, VPN mode, or per-app settings.
2. Identify whether the screen offers “VPN apps only” or “Bypass selected apps.”
3. Choose the intended mode and review the package list carefully.
4. Select the applications that should use the VPN, or select the applications that should remain direct, according to the mode description.
5. Save or apply the configuration, then return to the main connection screen.
6. Enable the VPN and accept Android’s system permission prompt if it appears.
7. Open the included applications one at a time and test them after the connection status is stable.

Do not add every application during the first test. Begin with one or two apps that have a clear reason to use the VPN. This makes the result easier to interpret and avoids accidentally sending background synchronization, photo backup, video updates, and large downloads through the selected route. After the first test succeeds, expand the list according to actual needs.

Verify that each app is using the intended route

A connection icon in the status bar confirms that an Android VPN profile is active, but it does not prove that every application follows the same route. Verification should compare an included app, an excluded app, and a local service. Test them separately and record what you intended before interpreting the result.

For an included browser, open a service that displays the public exit address and region. Then close the browser completely, reopen it, and repeat the test after changing the selected route. The address should change only when the browser is actually inside the VPN policy. Avoid relying on a cached page or an already-open connection. A page loaded before the rule change may continue to display old content even though new connections follow a different route.

For an excluded app, check whether its normal local service remains reachable. A payment application may require a local network identity, while a smart-home app may need access to devices on the same Wi-Fi network. If it stops working, check both the app rule and any “allow LAN traffic” or local-network option. Do not assume that excluding the app from the VPN also guarantees every local connection will be permitted; the client and Android permissions may apply additional restrictions.

Background traffic requires a separate check. Android may pause an application, delay synchronization, or restrict background activity through battery optimization. If a selected app works while open but fails to synchronize in the background, the problem may not be split tunneling. Review battery restrictions, background-data permission, and the app’s own account state before changing the VPN policy.

Testing DNS is important because the route used for an application’s connection and the resolver used to look up its domain may not be identical. A split policy that sends the app through the VPN but leaves name resolution on a path that cannot resolve the required host can look like an application failure. On the other hand, changing DNS alone does not make an application part of the VPN route. Treat capture, routing, and DNS as three related but separate checks.

Fix ignored app rules and broken connections

When an app rule appears to be ignored, first confirm that the client saved the setting and that the VPN was restarted afterward. Some clients read the application list only when the VPN profile is created or restarted. Force-closing the client, reconnecting, and then opening a fresh app session can distinguish a stale connection from a wrong rule.

The selected app does not use the VPN

Check whether the app was selected under the correct mode. In an allowlist, it must be included; in a bypass list, it must not be included. Then check whether the application uses a companion package. Login, media playback, downloads, and notifications may be handled by different packages. If the client offers package names rather than familiar application names, compare the icon and package details carefully.

Also check whether the client is operating in a mode that captures Android application traffic. A rule list cannot control traffic that the client does not capture. Some proxy-only modes work for applications that honor the system proxy but do not cover programs using their own network stack. If the client supports a TUN or VPN-based capture mode, use it only after considering battery use, local-network access, and conflicts with other network tools.

The connection breaks after switching modes

Switching from full routing to app-based routing can leave existing sockets in an inconsistent state. Stop the affected app, disconnect the VPN, apply the new policy, reconnect, and launch the app again. If the issue remains, restart Android’s VPN profile by disabling the client’s connection and enabling it again. Do not repeatedly switch between several clients while diagnosing the problem, because each client may leave a separate VPN permission or route state behind.

Battery optimization can also stop a client in the background. If the VPN disconnects when the screen turns off, review the Android battery settings for the client and allow the background behavior required by your use case. This may increase battery consumption. A stable configuration should balance continuous protection, selected-app access, and the phone’s normal power-management behavior.

Local services, DNS, and protocol differences

If local casting, printers, or smart-home devices stop responding, look for a LAN bypass option and confirm that Android has granted the required local-network permissions. Some clients apply a strict route that sends private-address traffic into the VPN unless an explicit exception exists. Add only the local exceptions you need rather than disabling all routing controls.

Protocol behavior can also affect the result. Shadowsocks, VMess, Trojan, Hysteria2, and WireGuard are connection protocols or protocol families, while the Android app rule is a local traffic-selection policy. Changing from one protocol to another does not automatically repair a wrong allowlist or bypass list. First verify the app policy, capture mode, and DNS path; then compare protocol compatibility if the selected route still fails.

• ✅ Reconnect after saving an app-rule change.
• ✅ Test with a newly opened application session.
• ✅ Check companion packages when login or media functions behave differently.
• ✅ Confirm that only one Android VPN client is active.
• ✅ Review battery optimization when background connections disappear.
• ❌ Do not treat a browser result as proof that another app uses the same route.
• ❌ Do not expose a subscription link while asking for configuration help.

Keep split tunneling reliable over time

App-based rules are not a one-time setting. Android updates, application updates, cloned apps, work profiles, and newly installed companion packages can change which package creates a connection. Review the list whenever an application is replaced, reinstalled, or moved into a work profile. A work-profile copy may appear as a separate entry even though it has the same visible name as the personal version.

Keep a simple record of the intended policy: which apps use the VPN, which apps stay direct, whether local-network access is allowed, and which route group is preferred. This record makes troubleshooting faster after a client update or phone migration. If the client supports configuration export, protect the exported file in the same way as the subscription link because it may contain route and authentication information.

Update the subscription when routes or policy groups change, but avoid updating immediately in the middle of a critical session. After an update, confirm that the expected groups remain available and that the app policy still points to the intended mode. If a route disappears, select another available route and test again rather than editing protocol parameters without documentation.

For everyday use, keep the policy as narrow as practical. Route only the applications that require it, exclude local services deliberately, and use full routing temporarily when you need to determine whether a problem is caused by the application list. This approach reduces guesswork and helps separate account, route, Android, and application problems.