v2rayNG Per-App Proxy Setup: How to Configure Android App Rules

v2rayNG can route every Android connection through a selected node, but that is often more than you need. If only a browser, messaging client, or work application requires the proxy, per-app rules can reduce unnecessary traffic and keep other applications on their normal network path. The important detail is that v2rayNG’s application-routing options work through Android’s VPN interface, so the result depends on the selected mode, the apps included in the list, Android’s battery restrictions, and the routing policy used by the core.

This guide uses v2rayNG 1.10.x as the reference and explains how to build a per-app proxy configuration from a clean baseline. You will learn the difference between proxy-list and bypass-list modes, how to select applications, how to avoid common DNS and VPN conflicts, and how to verify that the intended apps are actually using the proxy instead of relying only on the VPN icon.

How Per-App Routing Works in v2rayNG

When v2rayNG starts a VPN connection, Android creates a system VPN interface and sends captured application traffic to the client. v2rayNG then passes the traffic to the selected Xray or compatible core, where routing rules determine whether the connection goes through a proxy outbound, a direct outbound, or another configured route. The application list is therefore a traffic-capture filter, not a replacement for VMess, VLESS, subscription, DNS, or server settings.

v2rayNG commonly presents two ways to interpret the application list. In a proxy-list or allow-list style mode, the applications you select are sent through the VPN while applications outside the list remain outside the VPN. In a bypass-list or exclude-list style mode, the selected applications avoid the VPN while the remaining applications use it. The exact wording can differ between releases and translations, so read the description beside the switch instead of choosing a mode only from its short label.

Per-app routing is most useful when the desired set is small and stable. For example, if two applications need access through the node and ten other applications should remain direct, a proxy-list mode is easier to audit. If almost every application needs the proxy and only a few local services should stay direct, a bypass-list mode usually requires less maintenance.

• Proxy-list mode: Only selected applications enter v2rayNG’s VPN path. This is usually the safer starting point for testing.
• Bypass-list mode: Selected applications are excluded, while other applications are captured. This is convenient for a small direct-access exception list.
• Full-device mode: v2rayNG captures supported traffic from all applications, subject to Android and routing limitations.
• Local proxy mode: Applications must be configured to use a local HTTP or SOCKS listener; this is not the same as Android VPN per-app routing.

Choose the Right App-Selection Mode

Before changing any setting, write down the intended result in plain language. “Only the browser uses the proxy” means the browser must be in the captured list and unrelated applications must be excluded from capture. “Everything uses the proxy except banking and local-device tools” means most applications should be captured and the exceptions should be placed in a bypass list. This simple statement prevents the most common mistake: selecting the correct applications while using the opposite interpretation.

Application identifiers are more reliable than visible names. Android may show several similarly named entries, system components, cloned applications, or work-profile copies. If the list contains a package name, compare it with the application’s page under Android “Settings” → “Apps” → the relevant application. Selecting a system component by mistake can create confusing symptoms, such as broken notifications, failed captive-portal checks, or applications that appear to connect but cannot resolve domains.

Do not select v2rayNG itself as a substitute for selecting the traffic that should be proxied. The client needs to run the VPN service regardless of whether its own package appears in the application list. Also avoid adding every system process during the first test. Components such as Android System, the VPN permission service, or a device-management package may behave differently from normal user applications and can make diagnosis harder.

• Record the exact applications that should use the proxy.
• Check whether each application has a personal-profile and work-profile copy.
• Remove duplicate, old, or cloned entries from the list.
• Keep local-device tools direct unless they specifically require the proxy.
• Leave the list short until connectivity has been verified.

Configure v2rayNG App Rules Step by Step

First confirm that the selected node works in ordinary v2rayNG operation. Update the subscription, select a VMess or VLESS profile, start the connection, and open a test website. If the node cannot connect before application filtering is enabled, per-app routing will not fix the underlying problem. It is also useful to note the current core type, local DNS choice, and whether another VPN service is already active.

1. Verify the node

   Open v2rayNG, update the subscription if needed, select a known-good VMess or VLESS profile, and tap the main connect button. Confirm that the connection remains active for at least 30 seconds before changing app rules.

2. Open app settings

   Open the side menu or settings screen and locate the application-routing or per-app VPN option. Depending on the build, it may appear under VPN settings, routing settings, or an application list entry.

3. Select the mode

   Choose the mode whose description matches your plan: selected apps through VPN for a proxy list, or selected apps outside VPN for a bypass list. Do not rely on the word “allow” or “bypass” alone if the translation is unclear.

4. Choose applications

   Open the application list, search for the required package or visible app name, and select only the applications needed for the first test. Save the selection before leaving the page.

5. Restart the VPN

   Stop the current VPN connection, wait two or three seconds, then start it again. Accept Android’s VPN permission prompt if it appears, and check that the notification identifies v2rayNG as the active VPN.

6. Test each app

   Open one selected application and perform a repeatable action, then test an unselected application. Record the result before adding more packages or changing the node.

The application-list change may not affect an already established socket immediately. A browser can keep an existing HTTP/2 or QUIC connection, while a messaging application may retain a persistent connection for several minutes. Close the test application from Android’s recent-apps screen, reopen it, and repeat the test. If the result remains unchanged, stop and restart the v2rayNG VPN rather than repeatedly editing the list.

Some applications use UDP, background services, or several processes for one visible interface. A selected app may therefore show partial behavior: the main page loads through the proxy, but notifications or media transfer use a separate service. This is not necessarily proof that the rule failed. Check whether the secondary service is a separate package, whether the core supports the traffic type, and whether Android has restricted the client in the background.

Verify Both Proxy and Direct Results

A successful connection icon proves only that v2rayNG started a VPN service and that at least part of the core is running. It does not prove that the selected application used the proxy, nor does it prove that an unselected application stayed direct. Verification should therefore include three separate observations: the selected app’s external address, the unselected app’s route, and the v2rayNG log or traffic counter.

Begin with a controlled test. Close both applications, start v2rayNG, and open the selected application first. Visit a reliable address-check page or use the application’s own connection diagnostic. Note the displayed public address and region. Then close it, stop the VPN, reopen the same application, and record the baseline. The address should change if the selected app is genuinely using the remote node and the node’s egress address differs from the local connection.

Next test an unselected application. A direct application should normally show the local network’s public address, but the result can be affected by carrier NAT, Wi-Fi gateways, cached sessions, application proxy settings, or a separate encrypted DNS feature. For that reason, a matching address is useful evidence but not a complete proof. Combine it with v2rayNG’s connection statistics and the core log when available.

• Selected app shows proxy address: The application is probably captured, but confirm that the request generated traffic in the v2rayNG statistics.
• Selected app shows local address: Recheck the list mode, restart the VPN, close the app completely, and check for an in-app proxy or separate work-profile copy.
• Unselected app also shows proxy address: You may be using bypass-list mode, full-device mode, or an existing application-level proxy.
• Both apps fail: Return to the known-good node test and inspect DNS, routing, battery restrictions, and core logs before modifying the list again.

DNS deserves a separate check. Per-app capture can route an application’s IP traffic while the application still uses its own encrypted DNS endpoint, or Android may handle some resolver activity outside the expected path. A browser’s Secure DNS setting can also create results that look different from another app. Compare the client’s DNS configuration, the browser’s private DNS or Secure DNS setting, and the routing mode before calling the result a leak.

Recover When App Rules Stop Working

Rules often appear to “break” after an Android update, an application reinstall, a profile migration, or a change from proxy-list to bypass-list mode. Android may assign a new package entry, v2rayNG may retain an old selection, or a previously excluded application may now be included because the list interpretation changed. Battery optimization can also stop the VPN service in the background, making a correct rule look unreliable.

Use a controlled recovery instead of deleting the subscription or changing every routing parameter. Stop the VPN, open the application-routing settings, switch temporarily to full-device mode, clear the selected application list if the interface provides a reset option, save, and restart v2rayNG. Test the known-good node again. If full-device mode works, the node and core are probably healthy and the problem is limited to app selection or Android capture behavior.

After recovery, rebuild the rule list in small groups. Add one application, restart the VPN, and test it. Then add the next group of two or three applications. Keep a written note of the selected mode and package names; this is especially useful after reinstalling an app or moving it into a work profile. If an application remains incompatible with VPN capture, use its own proxy setting when available or leave it outside the per-app design rather than weakening the working rules for every other app.

For a clean final configuration, use proxy-list mode for a small number of required applications, keep the list limited to verified packages, leave Android battery management permissive for v2rayNG, and retest after every major Android or application update. If the goal changes from “a few apps” to “almost everything,” switch deliberately to bypass-list mode and document the direct exceptions. Clear rule naming and repeatable tests are more reliable than repeatedly changing nodes or reinstalling v2rayNG.