Per-app proxying in v2rayNG lets you decide which Android applications may enter the VPN tunnel and which applications should continue using the ordinary network. This is useful when a browser, messaging app, work tool, game, or local-service application needs a different route from the rest of the phone. Instead of changing the proxy configuration every time you switch tasks, you define the application scope once and let Android’s VPN service enforce it.
The important detail is that per-app proxying is not a second proxy protocol. v2rayNG still uses the selected VMess, VLESS, Trojan, Shadowsocks, or other supported outbound; the per-app setting only changes which application traffic is captured by the local VPN interface. A selected application can therefore fail because of a bad node, an incorrect VPN mode, an incomplete package selection, Android battery restrictions, or a routing rule inside the core. The guide below separates those layers and provides a practical setup path.
This guide explains v2rayNG’s two application-routing modes, shows how to select Android packages, compares VPN behavior and bypass options, and gives concrete checks for the two most common symptoms: a selected app still connects directly, or an excluded app loses network access.
Understand the two per-app routing modes
Open v2rayNG and first confirm that a usable configuration is selected. The per-app controls normally appear under the application’s settings or VPN-related settings, although the exact label can differ between v2rayNG releases and Android versions. Look for entries such as Per-app VPN, Apps, Allow bypass apps, or an application selection list. Do not begin by selecting dozens of packages. First decide what the list means in the current mode.
Only the applications checked in the list are captured by v2rayNG. Applications not selected continue through the normal Android network path.
Suitable for: a small number of apps that need proxy access
Most application traffic enters the VPN, while the applications checked in the list are excluded from the tunnel and use the ordinary network.
Suitable for: broad coverage with a short direct-access exception list
These modes are easy to confuse because the same package list may be displayed in both. In proxy selected apps mode, checking an application means “include this package in the VPN.” In bypass selected apps mode, checking an application means “exclude this package from the VPN.” Always test with one package first. If the result is opposite to what you expected, return to the mode selector instead of changing core routing rules.
Practical decision
Use proxy-selected mode when only two or three applications need the tunnel. Use bypass-selected mode when nearly every application should be proxied and you can clearly identify the few packages that must remain direct.
Prepare Android and v2rayNG before changing app rules
Per-app behavior depends on Android’s VPN permission and on v2rayNG remaining alive in the background. Before editing the package list, connect v2rayNG with the current configuration in ordinary VPN mode and confirm that one browser can open a known reachable page through the selected node. If the full-device connection already fails, application selection will not repair it. Check the node address, port, UUID or password, transport, TLS or REALITY parameters, and the core log first.
It is also useful to record the application’s package identity. Android may show a friendly name such as “Browser,” while v2rayNG internally works with the package name, for example com.example.browser. Cloned applications, work profiles, and separately installed regional editions can have different package IDs even when their visible names are similar. Select the exact installed entry rather than assuming that two matching names represent the same package.
Proxy-selected setup
- List meaning
- Checked apps use VPN
- Unchecked apps
- Normal network path
- Best default
- Small proxy scope
Start with one test application, then add packages gradually.
Bypass-selected setup
- List meaning
- Checked apps skip VPN
- Unchecked apps
- VPN path by default
- Best default
- Broad proxy scope
Keep system and local-service exceptions as small as possible.
Review Android’s battery and background controls as well. Set v2rayNG to an unrestricted or not-optimized battery mode when the operating system repeatedly stops the VPN service. On some devices, an additional background-start permission or network-assistant exception is required. These settings are manufacturer-specific, so the names can vary. The observable requirement is simple: v2rayNG must remain connected after the screen turns off and after you switch to another application.
Configure package selection step by step
The following sequence is intentionally conservative. Menu labels may be translated or moved in a particular v2rayNG build, but the order remains useful: establish a working tunnel, choose the routing mode, select one package, reconnect, and test before adding more applications.
Connect one node
In the main v2rayNG screen, select a known working profile and tap the connect button. Accept Android’s VPN permission prompt, then verify that the status changes to connected.
Open VPN settings
Open the side menu or settings page and enter the section containing
Per-app VPN,Apps, or application routing. Read the mode description before touching the package list.Choose the mode
Select proxy-selected mode if only specific apps need the tunnel. Select bypass-selected mode if most apps should use the tunnel and only a few require direct access.
Select one package
Search for the target application, check its package entry, and save the setting. Avoid selecting Android system packages, the VPN service itself, or unknown entries during the first test.
Reconnect the VPN
Stop the current connection and start it again so Android rebuilds the VPN interface with the new application list. If Android displays a VPN confirmation dialog, approve the requested connection.
Test and expand
Open only the selected application, test its login and one ordinary request, then add packages one at a time. Keep a note of the last package added when a failure appears.
Testing should include more than opening the application’s home screen. A cached page can appear normal even when new traffic is going direct. Sign out and back in only if necessary, refresh a page, start a new media request, or perform another action that creates a fresh connection. For a messaging application, send a small test message or refresh the conversation list. For a browser, compare a new private tab with a previously cached tab, while remembering that browser DNS, QUIC, and connection reuse can affect the result.
If the application supports multiple processes, selecting its visible package may not capture every related process. Some applications use a separate download package, web-process package, or companion service. Begin with the main package, inspect the behavior, and only then consider related entries. Selecting unrelated system packages to “make sure everything is covered” can create boot-time network problems and makes later troubleshooting difficult.
Verify VPN capture, routing, and DNS behavior
Application selection answers only the question “which packages enter the VPN.” Once traffic is captured, the core still applies DNS handling, sniffing, routing rules, and outbound selection. A selected application may therefore enter v2rayNG correctly but still reach a destination through a direct outbound. Conversely, an excluded application may use a direct path that cannot resolve or reach the service from the current network.
Use the v2rayNG log as the boundary between these possibilities. First reconnect and generate one fresh request from the target app. If no corresponding connection appears in the log, the package probably did not enter the VPN, the mode is reversed, the VPN permission is inactive, or Android excluded the app. If the connection appears but the request fails, inspect the destination, DNS result, routing decision, and outbound error instead of changing the package list again.
DNS deserves special attention. A per-app VPN does not automatically force every DNS request to use the same route in every configuration. Some applications issue ordinary DNS requests, some use encrypted DNS, and some cache answers for a long time. If the application connects directly despite being selected, temporarily test with a simple TCP request and inspect whether the core sees the domain. If the application loses access only to certain domains, check the configured DNS server, domain strategy, and routing rules.
| Observation | Likely boundary | Next check |
|---|---|---|
| No VPN icon or no connection state | Android permission or service | Reconnect and approve the VPN request |
| Selected app has no core log entry | Package list or mode | Reverse-mode interpretation and verify the package |
| Core sees the request but it fails | Node, DNS, or outbound | Read the first core error and test another profile |
| Only excluded app is offline | Direct path or blocking option | Disable strict block-outside-VPN protection temporarily |
Do not use an external address display as the only proof of application routing. Android may reuse sockets, a service may connect through a companion process, and a browser may use its own DNS or transport behavior. Combine three observations: the selected mode and package, a fresh request from the application, and the v2rayNG log during that request. This combination gives a much more reliable result than checking one web page after switching settings.
Fix the two common per-app failures
The first common failure is that a selected application still connects directly. Confirm that you selected proxy-selected mode rather than bypass-selected mode. Then check that the application was fully closed before reconnecting the VPN; Android may leave a background process running with an existing socket. Force-stopping the application for one test, reconnecting v2rayNG, and opening the application again removes much of that ambiguity.
Next, verify that the checked entry is the correct package. Work-profile applications, cloned applications, and vendor-specific duplicate entries can look identical in the list. If the application has a built-in secure DNS, proxy, or “direct connection” option, disable that feature temporarily for diagnosis. Also check whether the application uses a separate companion package. The v2rayNG log should show a new connection when the test request is made; if it does not, the problem remains at Android VPN capture rather than the remote node.
The second common failure is that a selected or excluded application loses network access. In bypass-selected mode, the application may be intentionally outside the VPN and therefore subject to local DNS filtering, firewall policy, or a network that cannot reach its service directly. In proxy-selected mode, the opposite can happen: the application enters the VPN, but its traffic matches a block rule, uses an unsupported UDP path, or cannot complete TLS through the chosen node.
Error: VPN permission was denied
Cause and fix: Android did not create the VPN interface. Open v2rayNG again, tap connect, approve the system VPN request, and remove any competing VPN service before retrying.
Error: selected app still uses the direct network
Cause and fix: The mode may be reversed or the wrong package may be checked. Confirm the mode meaning, force-stop the app, reconnect v2rayNG, and test a fresh request.
Error: app has no network after bypassing VPN
Cause and fix: The direct path or local DNS may be unavailable, or outside-VPN blocking may be active. Temporarily disable strict blocking, then test direct DNS and the ordinary network.
Error: connection refused or handshake timeout
Cause and fix: The application reached the core but the selected outbound failed. Test another node, inspect the protocol and transport fields, and compare the first error in the core log.
When UDP-dependent applications fail, do not immediately conclude that per-app selection is broken. Some nodes, transports, or routing configurations handle TCP successfully but do not provide a usable UDP path. Games, real-time calls, discovery functions, and some media services may depend on UDP. Test the same application with another profile and check whether the failure is limited to UDP. If only one service fails, review the node’s UDP support and the core’s routing behavior before adding system packages to the app list.
Frequently asked questions
Why does checking an app make it go direct?
You are probably using bypass-selected mode. In that mode, checked packages are excluded from the VPN. Switch to proxy-selected mode when the checked applications are the ones that should use v2rayNG.
Do I need to select the Android system package?
Usually no. Start with the visible application package only. Selecting system components can capture unrelated traffic and can make Android services or local network functions harder to diagnose.
Why does the app work until the screen turns off?
Android may stop v2rayNG in the background. Set its battery policy to unrestricted or not optimized, allow background activity where available, and check whether another power-saving feature is terminating the VPN service.
Why does the app enter the VPN but still fail?
Per-app capture does not guarantee a successful outbound. Check the node, DNS, routing rule, TLS or REALITY parameters, and UDP support. The first relevant core-log error is more useful than repeatedly changing the package list.
Once the first application works, add the remaining packages according to a clear policy: proxy only the applications that need it, or proxy most applications and maintain a small bypass list. Save the working mode and package names somewhere secure so a reinstall or phone migration does not require guessing. For the current v2rayNG package, use the site’s download page, then repeat the one-app test before restoring the complete list.