v2rayNG Android Guide: VpnService permissions, battery optimization and per-app proxy settings
This guide explains the v2rayNG VPN permission prompt, how to exempt the client from Android battery optimization to prevent background disconnects, and how to configure bypass and proxy-only per-app modes.
For v2rayNG users who have imported VMess, VLESS, Trojan or Shadowsocks nodes but are unsure about the first authorization prompt, lose the connection after locking the screen, or need certain apps to bypass the proxy. After completing the permission, background-policy and per-app rule settings below, you can build a predictable Android proxy path that is easy to troubleshoot step by step.
VpnService permission determines whether traffic can enter v2rayNG
When v2rayNG starts a connection on Android, it calls the system-provided VpnService interface. The first connection usually triggers a system confirmation dialog explaining that the app wants to establish a VPN connection. Here, “VPN” means a network-control capability Android grants to an app: the system creates a virtual network interface, sends traffic from eligible apps to v2rayNG, and lets the Xray core process it according to the selected node and routing rules.
This permission is separate from the subscription URL, node protocol and server authentication. Granting it only means v2rayNG can receive device traffic; it does not mean a VMess or VLESS node will work. Conversely, even perfectly correct node parameters cannot create a device-wide proxy without VpnService permission. When troubleshooting, first confirm that the system VPN indicator appears in the status bar, then check the node handshake and core logs.
Android normally allows only one active VpnService channel at a time. If the connection button briefly shows that it started and then resets, or the system displays a message such as “Replace existing VPN,” first disable other network tools using the interface. A work profile, the system always-on VPN policy, or enterprise device-management rules may also prevent a regular app from creating a channel.
- No VPN indicator in the status bar: check system permission, other VPN channels and device-management restrictions first.
- VPN indicator present but no app can connect: check the current node, DNS, routing rules and core logs.
- Only certain apps cannot connect: check the per-app proxy selection, the app’s own network settings and whether bypass mode is enabled.
- Wi-Fi works but mobile data fails: reconnect, then inspect DNS resolution, IPv6 and transport settings instead of immediately blaming permission.
Complete permission and node verification in order for the first connection
The steps below refer to the common Chinese interface in the v2rayNG 1.9.x series. System variations may move the buttons in the permission dialog, but the workflow is the same. Before starting, import a subscription or a single node and make sure the configuration list contains at least one selectable node.
-
Select a node
Tap a configuration on the main screen to make it the current node. Subscription users can open the top-right menu, choose Update subscription, and confirm that the list is not an old cache or an empty group.
-
Start the connection
Tap the Connect button at the bottom of the main screen. When the system VPN request appears on the first run, verify that v2rayNG is the requesting app and confirm the connection.
-
Check the status
Wait for the status on the main screen to change, and check whether the VPN indicator appears in the status bar. If the button resets immediately, open Logs from the top-right menu and inspect entries around the failure time.
-
Test connectivity
First open a reliable site in a browser, then test the destination that requires the proxy. Do not rely only on node latency; a successful latency test and a successful full web request are different checks.
-
Run a lock-screen test
Keep the connection active, lock the screen for 30 minutes, then unlock it and access the network immediately. If you must reconnect manually every time, continue by reviewing system battery policies and background-activity permissions.
v2rayNG can receive nodes from a Base64 subscription or vmess, vless, trojan or ss share links. The import method does not change what VpnService permission does. The subscription delivers configurations in bulk, the core handles protocol connections, and the system interface collects app traffic; assess these three layers separately.
If the connection shows a VPN indicator but nothing is reachable, check the core logs instead of repeatedly revoking system permission. For a domain-resolution failure, inspect Private DNS and the node address; for a connection timeout, check the server address, port and current network; for an authentication failure, verify the UUID, password, encryption method or transport parameters.
Troubleshooting order
1. Is the system VPN indicator present?
2. Is the current node selected?
3. Do the logs show a DNS or connection error?
4. Is the test app excluded by the per-app proxy?
5. Is the process still running after the screen is locked?
Use a battery-optimization exemption to prevent background disconnects after locking the screen
Android’s power-saving system can restrict processes that remain in the background. After v2rayNG connects, it must maintain the virtual interface, protocol sessions and network-change listeners. If the system freezes or reclaims the process after the screen is locked, common symptoms include a disappearing status-bar indicator, delayed messages, brief loss of connectivity after unlocking, or a button that still appears active even though traffic has stopped.
Start with the system’s built-in battery settings. A common Android 14 path is Settings → Apps → v2rayNG → App battery usage → Unrestricted. Another path is Settings → Apps → Special app access → Battery optimization → All apps → v2rayNG → Don’t optimize. Menu names vary by system UI, but the goal is the same: allow the app to keep running background tasks while the screen is locked.
Unrestricted
RecommendedLets v2rayNG maintain VpnService and the core process after the screen is locked or the network changes; this is the preferred setting for long-lived connections.
Best for: continuous daily connections, message syncing, and frequent switches between mobile data and Wi-Fi
Optimized or automatic
The system allocates background resources based on usage. Short tests are usually fine, but recovery may be delayed after a long period with the screen locked.
Best for: occasional manual connections and opening the client before each use
Restricted
The system sharply limits background execution, so the proxy path can stop when the screen is locked, the device is idle or memory is low.
Best for: temporary diagnostics when background proxying is not needed
Some devices also offer lists for auto-start, background activity, locked background tasks or sleeping apps. These controls are not part of v2rayNG’s own settings and must be handled in system app management. If the device automatically cleans up background tasks, remove v2rayNG from that list and allow it to run after boot or when the network changes.
Bottom line: stabilize the system’s background policy before tuning node parameters
If the connection drops only after the screen is locked while it remains stable with the screen on, first set v2rayNG to Unrestricted and repeat the 30-minute lock-screen test. Changing VMess, VLESS or the transport usually will not fix a process reclaimed by the system.
- Use the same node during testing; do not change the protocol, routing and battery policy at the same time.
- After 30 minutes with the screen locked, unlock the device, check the VPN indicator and make a web request immediately.
- Switch from Wi-Fi to mobile data, then wait 10 seconds to confirm whether the connection recovers automatically.
- Repeat the test twice; an interruption that can be reproduced under fixed conditions is much easier to trace to a specific system policy.
Per-app proxy: bypass mode vs. proxy-only mode
Per-app proxying uses an Android app’s UID to decide whether its traffic enters VpnService. This happens before protocol handling, so it is independent of whether the current node uses VMess, VLESS, Trojan or Shadowsocks. With the wrong app selection, the node can remain online while the target app connects directly or misses the intended route.
In v2rayNG, open the sidebar or main menu and go to Settings → Per-app proxy. Enable per-app proxying, then select apps and check the Bypass mode state. The most common source of confusion is that the same checked list has completely opposite meanings depending on whether bypass is enabled.
-
Stop the connection
Return to the main screen and stop the current connection. Stop before changing the app scope so the old virtual interface cannot continue using the previous selection.
-
Enable the feature
Go to Settings → Per-app proxy, enable the main per-app proxy switch, and wait for the installed-app list to finish loading.
-
Choose the mode
To proxy only a small number of apps, turn off Bypass mode and check the target apps. To proxy most apps while letting a few connect directly, turn on Bypass mode and check the apps to exclude.
-
Save the selection
Return to the settings page, reopen the per-app screen and review the checked apps. After an app update, reinstall or work-profile change, its previous app identity may need to be selected again.
-
Reconnect
Return to the main screen, start v2rayNG and establish VpnService again. Test one checked app and one unchecked app separately to confirm that both traffic paths match expectations.
Proxy-only mode suits clearly defined cases, such as sending only a browser and selected messaging apps through the proxy while leaving everything else on the system’s default network. Its benefit is a small, easy-to-audit scope; its drawback is that newly installed apps are not added automatically and must be selected manually.
Bypass mode suits cases where most apps need the proxy but banking apps, local-network controllers or internal enterprise tools must connect directly. The checked apps are exceptions, so new apps will usually use the proxy. When managing local-network devices, also check v2rayNG’s LAN bypass option; excluding an app and routing by IP are separate layers.
Troubleshoot common problems by symptom
After completing permission and per-app settings, if behavior is still unexpected, fix one test node, one test app and one network environment, then check each item. Changing several switches at once makes it impossible to match logs to actions.
The permission dialog disappears as soon as you tap Connect?
Open system Settings → Network & internet → VPN, stop other active connections, then return to v2rayNG and try again. If an always-on VPN policy is enabled, the device administrator must remove the restriction first.
Messages stop updating after the screen has been locked for several minutes?
Go to Settings → Apps → v2rayNG → App battery usage and select Unrestricted. Also check sleeping apps, auto-start and background-cleanup lists. Reconnect and run a lock-screen test for at least 30 minutes.
The checked app bypasses the proxy instead?
Check Bypass mode under Settings → Per-app proxy. When bypass is enabled, checked apps are excluded; to proxy only the checked apps, turn bypass off. Stop and restart the connection after changing it.
The browser works, but another app keeps timing out?
First confirm that the app is included in the current per-app scope, then check whether it uses its own DNS, QUIC or work-profile network. Temporarily disable per-app proxying and test again to determine whether the issue is app filtering or the node path.
The connection appears active after switching Wi-Fi, but nothing is reachable?
Wait 10 seconds, send the request again, and inspect the first error in Logs after the network change. If timeouts continue, stop and restart the connection; if the issue recurs, check whether background networking is restricted and whether the node domain resolves correctly.
The local port can also affect integration tests. v2rayNG commonly listens for SOCKS on port 10808, but use the actual value shown under Settings. Only apps that explicitly support manual proxies need a local address and port; with full VpnService capture, ordinary apps do not need 127.0.0.1:10808 entered separately.
If a subscription update fails, do not adjust the per-app list first. Check that the subscription URL is complete and the system time is accurate, then confirm whether the update request must use the current proxy. A successful update only means the configuration was read; node connectivity still depends on the server address, port, authentication parameters, TLS domain and transport settings.
- For permission issues, check the system VPN status—not node latency.
- For lock-screen issues, check battery policy and background permissions before changing protocols.
- For a single-app issue, check the per-app scope before resetting the entire configuration.
- For all-app issues, check node logs, DNS and routing instead of repeatedly tapping Connect.
- For network-switching issues, record the switch time and compare it with the first error in the logs.
Stable-configuration review checklist
Stable operation does not depend on one switch; it comes from system permission, background execution, node parameters and app scope working together. After setup, keep a simple baseline: one verified node, default routing, a clearly defined per-app mode and an Unrestricted background policy. When something fails, return to the baseline before restoring custom rules one by one.
- Confirm permission: The VPN indicator appears in the status bar after startup, and the system VPN page lists v2rayNG as the current connection.
- Confirm the node: The active configuration is complete, with no persistent authentication failures, DNS failures or connection timeouts in the logs.
- Confirm background access: App battery usage is set to Unrestricted, and v2rayNG is not listed among sleeping apps or automatic cleanup targets.
- Confirm the mode: With bypass off, only checked apps use the proxy; with bypass on, checked apps connect directly.
- Confirm reconnection: Stop and re-establish the connection after changing the per-app scope, routing or other critical network settings.
- Confirm the scenarios: Test with the screen on, after 30 minutes with the screen locked, and after switching from Wi-Fi to mobile data.
v2rayNG uses the Xray core for node connections and routing, while v2flyNG targets the v2fly core. Both must follow Android VpnService and background policies, but their supported protocol combinations, configuration fields and log output are not identical. Do not apply every advanced configuration exported by one client to the other without checking it first.
After these settings are complete, daily maintenance comes down to three checks: whether nodes still work after a subscription update, whether a system upgrade reset the battery policy, and whether the per-app list still matches expectations after an app is installed or reinstalled. Checking each layer is more effective than repeatedly reinstalling the client.