v2rayNG Per-App Proxy Setup: How to Configure App Routing

What per-app proxy routing actually changes

v2rayNG normally creates a local VPN interface and captures traffic from Android applications. The Xray or v2fly core then receives those connections, applies the selected node and routing rules, and sends the request either through the proxy server or directly to its destination. Per-app proxy is an additional filter before the ordinary domain, IP, and outbound rules are applied: Android identifies the application that created the connection, and v2rayNG decides whether that application is included in the VPN route.

This is different from selecting a node or changing the global proxy mode. A node defines how an allowed request reaches the remote server. A routing rule decides where that request goes after it enters the core. The per-app list decides which applications are allowed to enter the VPN tunnel in the first place. If an application is excluded, its traffic normally uses the Android network path directly and will not be affected by the selected VLESS, VMess, or Trojan profile.

There are two practical list modes. In a bypass-style mode, the applications selected in the list are excluded from the VPN, while other applications use v2rayNG. In a proxy-only mode, only the applications selected in the list use v2rayNG, while all other applications remain outside the tunnel. The exact labels may appear as an inverse or bypass option depending on the build and translation, so read the description beside the switch rather than relying on the position of the toggle.

Choose the correct app mode before selecting packages

Open v2rayNG and first confirm that a usable profile already exists. On the main screen, tap the profile entry you intend to use, run a latency test if your build provides one, and make sure the profile contains the expected server address, port, UUID or password, transport, and security settings. Per-app routing cannot repair an invalid node. If the core cannot establish the remote connection, an application may appear selected correctly while every request still times out.

Next open the application settings from the main screen. In common v2rayNG builds, the path is Menu → Settings → VPN settings, followed by an item named Allowed apps, Per-app proxy, or Application routing. Some releases place the app list directly under Settings. Android may display a system VPN confirmation the first time the profile starts; approve it only after checking that v2rayNG is the application you launched.

• Use proxy-only mode when you want to route a single browser, a test utility, or one work application while leaving Android services unchanged.
• Use bypass mode when nearly all applications should use the proxy but selected local-network tools, games, or payment applications should remain direct.
• Do not select v2rayNG itself by default. The client needs to maintain its VPN service and core process; excluding or including it unnecessarily can make troubleshooting more confusing.
• Include the complete package when an application has separate companion packages. A browser, download helper, or work profile may appear as a different package in the list.
• Remember Android profiles. A personal application and its work-profile copy can be listed separately, so selecting one does not always select the other.

The app list is not a domain allowlist. Selecting a browser does not mean that only one website inside that browser is proxied. Every connection created by that application may enter the VPN, including DNS requests, update checks, media connections, and connections to local addresses. If you need website-level control inside the selected application, combine per-app selection with the core’s routing rules rather than expecting the package selector to distinguish individual domains.

After saving, stop any previous VPN service before starting the new configuration. Android generally permits one active VPN service at a time, and an older profile can remain active even when the visible v2rayNG screen has changed. Wait until the status shows connected, then open the target application. If the app was already running, force-close it or remove it from recent tasks before testing so that persistent sockets do not produce a false result.

Configure and start a controlled test

A controlled test should begin with one selected application, one active profile, and one known destination. For example, select a browser in proxy-only mode, start a VLESS + TCP + REALITY profile, and visit a service that displays the public address. Do not begin by selecting ten applications and changing DNS, routing mode, and node at the same time. If the result is wrong, too many variables will be involved.

In the VPN settings, review whether Route all, Bypass LAN, or a similar local-network option is enabled. These controls are separate from the package list. A selected browser may enter the VPN, but a private address such as 192.168.1.1 can still be sent directly when LAN bypass is active. That behavior is often desirable for router panels and local printers, but it should be understood before diagnosing it as a failure.

Also check the DNS choice. A proxy-selected application can still resolve a hostname using Android’s ordinary resolver if the configuration does not redirect DNS through the core. This may create inconsistent results: the TCP connection uses the proxy, while the name lookup follows the local network. For ordinary testing, use the DNS behavior supplied by the imported profile first. Only change remote DNS, fake-IP mode, or domain strategies after confirming that the package selection itself works.

Start the service and watch the status for at least 10 seconds. A connected indicator only confirms that the VPN service and core are running; it does not prove that the intended application is included. Open the selected app, create a fresh request, and then open an excluded app to create a second request. This pair of tests gives you a baseline for both sides of the package rule.

Verify that each application follows the intended route

Verification should test more than whether one webpage opens. First record the public IP shown by the selected browser, then stop v2rayNG and record the same result over the ordinary network. Restart v2rayNG and compare again. If proxy-only mode is working, the selected browser should show the node’s egress address while an excluded browser or application should continue to use the ordinary network path. The addresses may occasionally be shared by a carrier or gateway, so repeat the test with a second destination when the results look identical.

Next test an application that uses a persistent connection, such as a messaging client or streaming tool. Force-close it, start v2rayNG, and launch it again. Background connections created before the VPN started may remain outside the new route, and an application can cache DNS answers or maintain an existing QUIC session. A clean relaunch is therefore more reliable than observing an already-open screen.

1. Selected-app test: Open the selected browser and visit an IP-check page plus a normal HTTPS page.
2. Excluded-app test: Open an unselected application and confirm that its behavior matches the direct network baseline.
3. DNS test: Check whether the selected application resolves the expected hostname consistently; compare after reopening the app.
4. LAN test: If LAN bypass is enabled, access a private router or storage address and confirm that local access remains available.
5. Restart test: Stop the VPN, wait five seconds, start it again, and repeat the selected-app request to rule out a stale session.

Troubleshoot common per-app routing mistakes

When the expected split does not appear, begin with the simplest explanation: the wrong mode was selected. A bypass list and a proxy-only list can contain exactly the same packages while producing opposite results. Take a screenshot or write down the mode before changing the checkboxes. Then reduce the list to one package, save it, restart the VPN, and test again.

Another frequent cause is testing the wrong process. Android applications can include a main package, a work-profile copy, a browser helper, or a separately installed beta package. The visible application name may not identify the package that creates the connection. Select the package shown by v2rayNG, relaunch the application, and avoid adding every similarly named entry until you know which one is responsible.

If the VPN connects but the selected application cannot load anything, inspect the core log and compare the error with the local network state. A port conflict is more common when another VPN or proxy service is active. A handshake error points to the node’s address, port, SNI, UUID, public key, short ID, transport, or server availability—not to the app checkbox. A DNS error suggests resolver or domain-strategy settings. Separate these layers before editing the profile.

Battery optimization can also interrupt routing after the screen turns off. If traffic works immediately after connection but stops later, open Android’s app battery settings for v2rayNG and permit the background behavior required by your device. Do not disable every power restriction without reason; make the smallest change that keeps the VPN service alive. Also check whether the system automatically disables VPN applications, restricts background data, or switches networks between Wi-Fi and mobile data.

Once the single-app test succeeds, add applications gradually and record whether each one should be proxied or bypassed. Keep a small written inventory of the selected packages, the active mode, the profile name, and any LAN exception. This is especially useful after importing a new subscription, clearing v2rayNG data, or moving between personal and work profiles. A predictable list is easier to audit than a large collection of unchecked entries.