v2rayNG Android Setup Guide: VpnService Permissions, Battery Optimization Exclusions, and Per-App Proxy Settings
Three key settings for using v2rayNG reliably on Android: grant VpnService permission, exclude the app from battery optimization to prevent disconnects in the background, and use per-app proxying for selected apps.
First, verify the v2rayNG connection path
After v2rayNG starts, it runs the Xray core locally and uses Android's VpnService to take over network traffic that matches the configured conditions. Connections from apps first enter the system VPN interface, then the client processes them according to the active configuration, routing rules, and node parameters. A VPN icon in the status bar only confirms that the system interface is established; it does not by itself prove that the remote node is reachable.
Before changing system settings, complete a basic check. Make sure the subscription has been updated, the intended configuration is selected, and the server address, port, transport, and security settings all come from the same valid configuration. Parameters for protocols such as VMess and VLESS cannot be mixed and matched. If the node requires TLS, REALITY, or a specific transport path, the corresponding fields must also remain consistent.
- Open v2rayNG and update the subscription manually.
- Select a node in the configuration list that is known to work.
- Start the connection and accept the system VPN permission prompt.
- Test a regular webpage in a browser first, then check the target app.
- Lock the screen for a few minutes, wake it again, and confirm that the connection still works.
VpnService permission and system VPN conflicts
When you start a connection for the first time, Android displays a system-level VPN connection confirmation dialog. This dialog is provided by the operating system and is not a regular notification permission. v2rayNG can create a virtual network interface only after permission is granted. If you tap Cancel, the client may briefly show that it is starting and then stop, while the target app will not enter the proxy path.
The correct first-time authorization steps
- Select a configuration in v2rayNG and tap the start button.
- When the system connection request appears, verify that v2rayNG is the requesting app.
- Tap Allow and wait for the VPN icon to appear in the status bar.
- Return to the client and check whether the bottom status and live traffic have changed.
After some system upgrades, app reinstalls, or changes to a work profile, permission may need to be confirmed again. If tapping Start shows no confirmation dialog and no connection is established, stop the current connection first, then open the system VPN settings and check whether another VPN service is already active.
Usually, only one active VPN can exist in the same user profile
Android manages VpnService centrally. Within the same user profile, an active VPN service may be replaced by a new connection, or the new connection may fail to start. Some security tools, enterprise networking tools, and built-in network features also occupy the VPN interface. During troubleshooting, disable other active services first, then start v2rayNG on its own.
If the system VPN settings have Always-on VPN or a similar forced-connection option enabled, also verify that the correct apps are bound to it. When connections outside the VPN are blocked, stopping v2rayNG or a failed configuration can make the device appear unable to access the internet in any app. During initial setup, verify node stability before enabling such system policies.
The VPN icon is present, but webpages will not open
This is usually not an authorization problem, but an issue with the remote connection, DNS, or routing. Switch to a known-working configuration first, then run the connection test provided by the client. If the latency test fails, check the server address, port, network environment, and system time. If latency is normal but domains will not open, continue by checking DNS settings. If only a specific app fails, review the per-app proxy and routing rules.
Battery optimization exclusions and background disconnects
A connection that works while the screen is on but drops a few minutes after locking is one of the most common Android background-management issues. The system may restrict background execution, pause network activity, or terminate the client process when memory is low. Settings vary by device, but the goal is the same: let v2rayNG keep running in the background and reduce system restrictions on its network activity.
First: remove battery optimization limits
Open the app info page in system settings and find v2rayNG's battery or power management settings. Set the background policy to Unrestricted, Allow background activity, or an equivalent option on your device. If the system provides a battery optimization list, mark v2rayNG as not optimized. After making the change, start the connection again instead of merely returning to the home screen and observing the old process.
Second: allow background activity and auto-start
Some devices split background activity, auto-start, and associated launch into separate switches. At minimum, v2rayNG should be allowed to run in the background. If you need it to resume automatically after a reboot, also check auto-start permission. These options are commonly found under app management, battery management, or a system security manager, and their exact names vary by system version.
Third: keep the persistent notification enabled
The persistent notification shown during a connection displays service status and helps the background service comply with the system's foreground-service requirements. Do not disable the notification category associated with connection status just to clear notifications. If background stability worsens after notifications are disabled, restore v2rayNG's notification permission and reconnect.
Fourth: check Data Saver and background data
When Android's Data Saver mode is enabled, background mobile-data activity may be restricted. Open v2rayNG's mobile-data settings and allow background data. If the system offers a list of apps exempt from Data Saver, you can add the client there as well. This mainly affects mobile networks. If Wi-Fi works normally but the connection drops after the screen locks on mobile data, check this first.
| Symptom | Check first | Action |
|---|---|---|
| Disconnects a few minutes after the screen locks | Battery optimization | Allow background activity and exclude the app from optimization |
| Stops working immediately after clearing recent apps | Background process management | Keep the client process running; do not force-stop it |
| Disconnects frequently on mobile data | Background data and Data Saver | Allow background data and unrestricted data usage |
| Does not reconnect after a device reboot | Auto-start and system VPN policy | Allow auto-start if needed, then verify the active configuration |
After applying these settings, retest using the same procedure: start the connection, open a webpage to confirm access, lock the screen for five to ten minutes, then wake it and test the same page. Next, switch once between Wi-Fi and mobile data. If you must reconnect manually after every network change, update the client first, then check whether the current node can connect on the new network.
Choosing per-app proxying and bypass mode
Per-app proxying determines which Android apps hand their traffic to v2rayNG. It answers the question, “Which apps enter the VPN interface?” Routing rules solve a different problem: once traffic reaches the client, they decide whether it should connect directly, use the proxy, or be blocked based on domains, IPs, or other rules. These operate at different layers and should not be treated as the same switch.
Proxy only the apps you select
If you need only a browser or a few tools to use the proxy, enable per-app proxying in v2rayNG and select the target apps. Make sure bypass mode is off so the list means “selected apps use the proxy.” Wording varies slightly between versions, so read the switch description before saving and confirm whether the list represents included or excluded apps.
The advantage of this mode is its clearly defined scope: unselected apps continue using the system's default network. It works well when only a few apps need proxy access. The drawback is that newly installed apps are not added automatically and must be selected manually. Some apps use separate components or an external browser for sign-in. If you select only the main app, the sign-in page may use a different path. When sign-in redirects fail, check every app involved in the flow.
Let the apps you select bypass the proxy
If most apps should use the proxy and you only need to exclude banking, local-network control, or other specified apps, enable bypass mode. Apps in the list use the default network directly, while all other apps enter v2rayNG. Recheck the interface description before changing this mode: misunderstanding the list can produce the result that checking an app makes it bypass the proxy.
How per-app proxying works with routing rules
After an app is allowed into v2rayNG, its connections are still evaluated by the client's routing rules. For example, a selected browser may still connect directly when routing rules mark local-network addresses and specific domains as direct. Conversely, an app that never enters the VPN interface will not be routed through the proxy just because a domain rule exists.
Start with a simple configuration to verify the per-app scope before adding complex routing. For the first test, use an easy-to-understand routing mode, open one selected app and one unselected app, and compare their egress paths and access results. Once the app selection is confirmed, restore domain, IP, and local-network routing rules.
Checking DNS, subscriptions, and node switching together
If per-app settings are correct but domains still will not open, treat DNS as a separate item to investigate. The client may process queries using local DNS, remote DNS, domain policies, and routing rules. Android's Private DNS setting can also change part of the resolution process. Do not enable several experimental DNS options at once; start with settings that are clear and reproducible.
Compare access by domain with access by direct IP. If the node connection test succeeds and some IP addresses are reachable but every domain fails, DNS is a likely cause. If only one category of domains fails, check whether routing rules send the resolved traffic through an unsuitable egress. Re-establish the connection after changing DNS, because existing connections and caches may delay the visible result.
Verify the active configuration after a subscription update
Updating a subscription retrieves a configuration list; it does not automatically choose the fastest or most stable node for the current network. After the update, check that the selected configuration still exists and that you have not accidentally chosen a disabled entry. When node names are similar, compare key fields such as the protocol, address, and port instead of relying only on list order.
Batch latency tests reflect connectivity only at the time of testing. Low latency does not guarantee that every transport parameter is correct, and it cannot replace a real webpage test. After choosing a candidate node, run a connection, domain-resolution, webpage-loading, and screen-lock recovery test before making it your daily configuration.
Switching between Wi-Fi and mobile data
Changing networks can alter the local address, DNS, IPv4 or IPv6 availability, and the carrier's network path. A brief reconnect after switching is normal, but if the connection does not recover after a while, stop and start it manually. If a node fails on only one network type, the cause is more likely to be the network path, address family, or server reachability; repeatedly changing VpnService permission is unnecessary.
Troubleshooting checklist by symptom
Stops immediately after tapping Start
- Confirm that system VPN permission has been granted.
- Stop other services using the VPN interface.
- Select a complete configuration again; avoid entries missing a server or port.
- Check the client message to distinguish a configuration parsing error from a network connection failure.
The connection says it is active, but no apps can open anything
- Check node latency and the actual connection result first.
- Confirm that the system time and time zone are correct, especially when TLS or REALITY is involved.
- Temporarily simplify DNS and routing settings to rule out rule conflicts.
- Check whether per-app proxying is enabled without any target apps selected.
Only one app cannot access the network
- Confirm whether the app is included in the per-app list.
- Check bypass mode and determine whether the list currently represents included or excluded apps.
- Check whether the app invokes a separate browser, sign-in component, or system download component.
- Clear the target app's DNS cache or fully close it before opening it again.
The connection disappears after locking the screen
- Set v2rayNG to allow background activity.
- Exclude the client from battery optimization.
- Allow the persistent notification and background data.
- Do not force-stop the client process while connected.
The result does not change after modifying settings
Stop the current connection first, wait for the VPN icon to disappear from the status bar, then start it again. Fully close the target app used for testing and reopen it. Keep the node, network, and URL fixed, changing only one setting at a time. This is the only reliable way to determine whether the change came from the per-app list, battery policy, DNS, or the remote node.
Final checks for reliable everyday use
After configuration is complete, there is no need to repeatedly change every advanced option. Keeping a verified baseline is easier to maintain. Before and after daily use, run through this quick checklist:
- The subscription updated successfully, and the active node is still valid.
- VpnService permission is granted, with no conflict from another active VPN.
- v2rayNG is allowed to run in the background, use background data, and show necessary notifications.
- The per-app list matches the intended meaning of bypass mode.
- Routing rules do not send the target traffic through the wrong egress.
- Tests on Wi-Fi, mobile data, and after locking the screen all pass.
If the issue appeared only after a particular subscription update, switch back to a verified configuration instead of immediately resetting every system setting. If it occurs only after locking the screen, check battery restrictions first. If it affects only one app, check per-app proxying first. Narrowing the scope by symptom is more effective than repeatedly importing subscriptions or switching several nodes at once.