Use this guide when v2rayNG stops in the background, disconnects after the screen has been locked, or only some apps cannot connect. First identify the scope of the failure, then check VpnService, other VPNs, battery policies, and the per-app list. Only afterward inspect subscriptions, nodes, and routing to avoid mistaking a permission issue for a protocol problem.
First distinguish background disconnects from apps outside the proxy scope
v2rayNG is an Android GUI client that imports subscriptions, selects configurations, and calls the Xray core. The Xray core handles connections such as VMess and VLESS, while Android's VpnService passes app traffic to the client. These operate at different layers. If the VPN icon disappears from the status bar, check system authorization, process survival, or VPN conflicts. If the icon remains but one app connects directly or fails to open, inspect per-app proxy settings and routing rules.
Do not judge the issue only by whether a webpage opens. Watch three things together: the running status on the v2rayNG main screen, the VPN icon in the system status bar, and at least two apps with different behavior. If every app fails after the screen is locked, background process restrictions are more likely. If the browser works but the target app does not, check the app list, the app's own connection method, and differences in domain and IP routing.
- VPN icon disappears: First check whether VpnService was replaced, whether the system stopped the app, and whether battery policies are restricting background activity.
- VPN icon remains, but all apps fail: Check the active configuration, network changes, DNS, subscription node availability, and core error messages.
- Only selected apps fail: Check the per-app proxy switch, list mode, and whether the target app is selected.
- Works in the foreground but fails after locking the screen: Test battery restrictions and background activity first; do not immediately replace the VMess or VLESS configuration.
Conclusion: Check the failure scope before changing node settings
Whether the VPN icon remains and whether the issue affects one app or all apps are the two most useful signals. Only after authorization, background survival, and app scope are confirmed should you inspect subscription contents, server names, transport parameters, and routing rules.
Recheck VpnService authorization and VPN conflicts
When v2rayNG starts in VPN mode, Android displays a connection request. This authorization lets the app create a local VPN interface; it does not grant permission on the server side. The request may reappear after first launch, clearing app data, a system upgrade, or restoring a configuration. If it is denied, the client cannot route traffic from other apps through the VPN interface, even when a configuration is selected.
Android typically keeps only one active VPN. When another app using VpnService starts, it may replace v2rayNG. An “Always-on VPN” setting that points to another app can also cause repeated disconnects. Changing nodes, updating subscriptions, or switching Xray configurations will not resolve this resource conflict.
Stop the connection
Return to the v2rayNG main screen and stop the current connection. Wait for the VPN icon to disappear from the status bar so the old session does not interfere with reauthorization.
Check system VPN settings
Open Android “Settings” → “Network & internet” → “VPN”. On some devices, the entry is under “Connection & sharing” → “VPN”. Make sure no other VPN is connected.
Check Always-on VPN
Open the settings button next to the VPN entry and check whether “Always-on VPN” is assigned to another app. During troubleshooting, turn this option off and start v2rayNG by itself.
Authorize again
In v2rayNG, select a configuration known to work and start it. When Android shows the “Connection request”, tap Allow and confirm that the VPN icon returns to the status bar.
Test network switching
Test once on Wi-Fi and once on mobile data. After switching networks, wait 10 to 20 seconds before checking whether the connection recovers by itself, so a brief rebuild is not mistaken for a persistent disconnect.
Handle battery optimization and background restrictions layer by layer
The most common triggers for background disconnects are the screen turning off, long periods without interaction, battery saver mode, and system cleanup of background apps. Android's standard battery optimization may operate alongside manufacturer-specific settings for auto-start, background activity, and sleeping apps. Simply locking the app in the recent-apps list is usually not enough to remove every restriction.
Check settings in this order: “app battery policy → background activity → auto-start → battery saver mode”. A common path is “Settings” → “Apps” → “v2rayNG” → “Battery” → “Unrestricted”. If the system has separate “Auto-start management” or “Background start” settings, allow v2rayNG to recover after network changes or process cleanup. Menu names vary by Android version and device interface, but the goal is always to remove background execution limits for the client.
Unrestricted
RecommendedAllows the client to keep running while the screen is off and during network changes; use this as the baseline for troubleshooting background disconnects.
Best for: maintaining a continuous VPN connection
Optimized
The system schedules background activity based on usage. After a long idle period, it may delay tasks or reclaim the process; actual behavior depends on the device policy.
Best for: testing after confirming there are no disconnects
Restricted
Significantly limits background execution time. It is unsuitable for a persistent VPN connection and can interfere with troubleshooting.
Best for: apps that do not need a background connection
| Check item | Recommended state | How to verify |
|---|---|---|
| App battery usage | Unrestricted | Lock the screen for 30 minutes, then wake it and check whether the VPN icon is still present |
| Background activity | Allow | Switch to another app for 10 minutes, then return to v2rayNG and check its status |
| Auto-start management | Allow | Restart the device, launch it manually once, then test whether a network switch recovers the connection |
| System battery saver mode | Turn off during troubleshooting | With the same node, compare the results with battery saver mode off and on |
Keep one variable at a time during testing: choose one configuration, turn off per-app proxy, remove battery restrictions, and observe continuously. If a 30-minute screen-lock test is stable, restore battery settings one by one. This identifies the policy that actually triggers disconnects instead of permanently disabling every battery-management feature.
Check both the mode and the list for per-app proxy
Per-app proxy determines which apps enter v2rayNG's VPN interface; routing determines whether traffic inside the core uses the proxy or a direct connection. They are separate. When an app is outside the VPN scope, the Xray core cannot see its connections, so later domain rules, IP rules, and outbound selection cannot take effect.
The relevant v2rayNG entry is usually under “Settings” → “Per-app proxy”. After enabling it, confirm the list mode: one mode proxies only selected apps, while the other bypasses selected apps. Both use the same checkboxes, but their meanings are opposite. Recheck the list after updating or reinstalling apps, or switching work profiles.
Turn off per-app proxy
In v2rayNG, open “Settings” → “Per-app proxy” and turn the feature off. Start the connection and test the target app. If it works, the issue is most likely the list or its mode.
Choose the list mode
When only a few apps need access, choose “Proxy selected apps only”. When most apps need access, choose “Bypass selected apps”. Do not rely on the checkboxes without reading the mode label.
Select the apps again
Find the target app in the app list and make sure it is selected. After reinstalling an app, the identity assigned by the system may change, so an old selection should not be assumed to remain valid.
Rebuild the VPN
Save the changes, stop v2rayNG, and start it again so the new app scope is applied to VpnService. Returning to the home screen without rebuilding the connection may keep the previous scope.
Compare two apps
Choose one app that is definitely included and one that is definitely excluded. Open the same test target in both to verify that the list mode behaves as expected.
Conclusion: The list controls access; routing chooses the exit
When troubleshooting one app, first test with per-app proxy disabled. After confirming that it can connect, set the list mode, then check proxy, direct, and block rules. This order prevents you from investigating two layers at the same time.
Check subscriptions, nodes, and routing after permissions
If the VPN icon remains stable and every target app is within scope but the connection still fails, move on to configuration-level checks. A subscription only distributes configuration; it does not grant VpnService authorization or change system battery policies. After updating a subscription, confirm that the selected configuration still exists and that fields such as VMess, VLESS, TLS, and server name are complete.
v2rayNG uses the Xray core; v2flyNG uses the v2fly core. The two clients have different core positioning, so switching cores should not be treated as a fix for background process reclamation. Incorrect protocol settings usually cause connection establishment failures or make specific targets unreachable, rather than disappearing predictably after 30 minutes of screen lock.
Routing can also produce results that look like disconnects. For example, a target domain may match a block rule, a specific IP range may be set to direct, or a DNS change may match a different rule. During troubleshooting, use a configuration with a known, clear structure and reduce custom rules. Once the connection is stable, add routing conditions back one at a time.
Troubleshooting record example
System version: Android 14
Client: v2rayNG
VPN icon: still present after 30 minutes with the screen locked
Per-app proxy: Off
Test apps: 2
Local SOCKS example port: 10808
Recovery after network switching: observed for 20 seconds
Next step: Check the active configuration and routing match results| Layer | Typical symptom | Priority action |
|---|---|---|
| VpnService | No VPN icon at startup, or it is replaced by another VPN | Reauthorize and clear the VPN conflict |
| Background policy | Works in the foreground, then stops when the screen turns off or the device goes idle | Set it to Unrestricted and complete a 30-minute screen-lock test |
| App scope | Only some apps do not connect | Disable per-app proxy for comparison, then check the mode and list |
| Core configuration | The VPN icon is present, but the configuration cannot establish a connection | Check subscription fields, protocol parameters, and core information |
| Routing | A specific domain or IP produces an unexpected result | Reduce custom rules and check proxy, direct, and block outbounds |
Local SOCKS port 10808 is a common example value, not a port used by every installation. In VPN mode, most ordinary apps do not need this port entered manually; only apps explicitly using a local proxy address need it checked. If you change the local port in v2rayNG, old port values saved in external apps will not update automatically.
Quickly locate common issues by symptom
After completing the layered checks above, use the symptoms below to finish troubleshooting. After each change, stop and restart the connection, and record the VPN icon, target app, and screen-lock duration. Do not change nodes, routing, and battery policies at the same time, or you will not know which step made the difference.
Why does it disconnect a few minutes after I lock the screen?
Open “Settings” → “Apps” → “v2rayNG” → “Battery”, set the policy to “Unrestricted”, and check background activity and auto-start permissions. Turn off system battery saver and run a 30-minute screen-lock test. If it remains stable, restore the original settings one at a time.
The status bar shows a VPN icon. Why does one app still connect directly?
In v2rayNG, open “Settings” → “Per-app proxy”. First confirm whether the current mode is “Proxy selected apps only” or “Bypass selected apps”, then check whether the target app is selected. Save the changes, stop the connection, and start it again.
Will updating the subscription automatically fix background issues?
No. A subscription update only changes the configuration content managed by the client; it does not handle Android VpnService authorization or battery policies. Confirm the VPN icon and background survival first, then check whether the new configuration can establish a connection.
Wi-Fi works, but mobile data does not. What should I do?
After switching networks, wait 20 seconds and check whether the client rebuilds the connection. Then disable per-app proxy for comparison. If the VPN icon remains but every app fails, check the active configuration's connection details, DNS, and routing rules.
Can it still disconnect after enabling Always-on VPN?
Yes. Always-on VPN specifies which VPN app the system should maintain; it cannot replace the app's Unrestricted battery setting, background activity permission, or auto-start setting. Also confirm that another VPN configuration is not occupying the Always-on VPN slot.
- First confirm that only one active VPN exists in the system and complete v2rayNG connection authorization.
- Set v2rayNG's battery policy to Unrestricted and use a 30-minute screen-lock test to verify background survival.
- Disable per-app proxy for a baseline test, then configure the list mode and app scope again.
- After permissions and scope are working, check the subscription, VMess or VLESS parameters, DNS, and routing.
- Change only one variable at a time and preserve repeatable test conditions.