First distinguish actual battery drain from usage attribution and background disconnects, then compare results over fixed intervals. This guide is for Android users who can connect but experience standby drain or disconnects when the screen is off. Check per-app proxying, log levels, battery optimization and “Always-on VPN” in order. Keep a reproducible test record instead of enabling every background permission at once.
Identify the source of battery use—not just the app ranking
v2rayNG uses Android’s VPN service to receive traffic and pass it to the Xray core. An app’s percentage on the Battery screen doesn’t equal its share of total battery drain; some systems may also attribute VPN traffic to the VPN app. Seeing v2rayNG at the top doesn’t prove that the core is constantly maxing out the processor. Go to Settings → Battery → Battery usage and check the reporting period, background activity time, and whether video playback, downloads or cloud backups were running during the same period.
Separate three scenarios: normal battery use during continuous traffic; connection failures and retries by apps caused by an unstable network; and screen-off disconnects caused by the system stopping a background service. Excluding an app from battery optimization mainly addresses the third scenario—it won’t reduce encryption overhead. If your phone keeps switching between mobile data and Wi-Fi in a weak-signal area, hold the network constant before comparing client settings.
These figures describe a test plan, not measured battery results. Battery percentages are rounded, so the same drop over a short interval doesn’t necessarily mean the same power use. Repeat tests at similar battery levels, signal strength and temperatures. Don’t charge the phone or run system updates during testing.
| Test | Conditions | What to record |
|---|---|---|
| Service off | Disconnect v2rayNG and leave the screen off for 30 minutes | Starting and ending battery level, network signal, background sync |
| Connected, idle | Connect to the same server and leave the screen off for 30 minutes | Whether the service is still running, network disconnects, traffic increase |
| Fixed workload | Connect to the same server and play the same content at the same quality for 30 minutes | Starting and ending battery level, data transferred, change in device temperature |
Takeaway: compare the idle test first, then adjust background permissions
If the difference appears only under a fixed workload, first narrow the traffic routed through the proxy and check network quality. If the service stops when the screen is off, investigate background restrictions. Don’t use “Unrestricted” to mask repeated retries.
Limit proxy traffic: understand per-app proxying and routing
In v2rayNG, open the side menu and go to Settings → Per-app proxy. Depending on the version, the toggle and app list may appear on the same page, or you may need to open the list separately. Check how the selected mode works: with “Bypass mode” enabled, listed apps usually bypass the VPN; with it disabled, the list selects apps routed through the VPN. Follow the on-screen explanation for your version—don’t rely on checkmarks alone.
- Route only the apps you need through the VPN: Best when your needs are specific. Start with your browser and the apps that require a proxy, then test sign-ins, web pages and downloads in each.
- Bypass the VPN for high-traffic apps: If local video, system downloads or backups don’t need a proxy, add those apps in bypass mode. Their traffic will use your current network directly.
- Keep routing rules appropriate: Routing settings decide which outbound route traffic already in the core takes. Per-app proxying decides which apps enter the VPN. These are separate layers.
- Reconnect after changing settings: Stop and restart the service to apply the new app selection. Test one app on the list and one off it; don’t rely only on the VPN icon in the status bar.
Traffic routed directly by a routing rule usually still passes through the VPN and core for inspection, so a “direct” rule doesn’t mean “bypass the VPN.” Per-app proxying can reduce the traffic entering the processing chain, but actual battery savings depend on app activity. Traffic attribution can also shift when a browser launches another app, a download manager or a system component. Include real-world actions in your tests.
Reduce log volume and check for timeouts and repeated connections
Go to Settings → Log level and check the current value. For everyday use, choose warning. Temporarily switch to info when diagnosing connection issues, and use debug only when you need more detail. These are core log levels; the app may display localized names. Restart the service after changing the level and confirm the new setting has taken effect.
Verbose debug logs add formatting, transfer and display overhead, but turning logs off won’t fix a broken server. Clear old logs, reproduce the issue with one consistent action, then check whether the error keeps appearing. Logs may contain visited domains and server addresses; redact them before sharing, and never include subscription links.
Error snippet: i/o timeout
Cause and fix: A network read or write didn’t finish before its timeout. Full logs can help identify whether the delay occurred during DNS lookup, server connection or data transfer. Keep the network constant, repeat the same test, then compare with a known-working server. Avoid repeatedly tapping speed test.
Error snippet: connection refused
Cause and fix: The destination port refused the connection, possibly because no service is listening or the address or port is incorrect. Check the server address and port, update the subscription and reconnect. A background allowlist won’t fix a refused connection.
Error snippet: network is unreachable
Cause and fix: No usable route was available at the time, possibly during a network switch or when the address family was unreachable. First confirm that regular internet access has returned, then reconnect the VPN. Check whether the error consistently appears after switching between Wi-Fi and mobile data.
These are common error snippets from real logs, not a one-to-one guide to battery drain. A single disconnect may simply reflect a normal network change. Investigate further only when errors persist alongside increased traffic or background activity. Switching from VMess to VLESS isn’t a universal battery-saving fix; transport, TLS, network quality and actual traffic all affect resource use.
Exclude v2rayNG from battery optimization to address screen-off disconnects
Before changing permissions, note your Android version, system UI version and v2rayNG version. Find the version numbers under Settings → Apps → v2rayNG → App info. The paths below use names typical of near-stock Android. Manufacturers may call these settings “Battery management” or “Background power management”; search Settings for the relevant option.
-
Open App info
Long-press the v2rayNG icon → App info → Battery or App battery usage. Note the original “Optimized” or “Restricted” setting so you can restore it after testing.
-
Relax battery restrictions
If “Unrestricted” is available, select it. If your system uses a Battery optimization list, go to Settings → Apps → Special app access → Battery optimization, switch to “All apps,” find v2rayNG and select “Don’t optimize.” You don’t need to use both settings paths.
-
Check background settings
Check v2rayNG under the manufacturer’s “Auto-start” or “App launch management” settings. Allow auto-start or background activity only if the system is stopping the app or it fails to start as expected after reboot. Locking the app in Recent apps does not replace battery permissions.
-
Check notification permission
On Android 13 and later, check notification permission under App info → Notifications so the service status remains visible. Denying notifications doesn’t necessarily stop a foreground service. Don’t assume the core has stopped just because its notification disappeared.
-
Retest with the screen off
Connect, turn off the screen for 30 minutes, then check the service status before testing a web page. If the disconnect happens only when system Battery Saver is enabled, test that setting on its own—don’t also change servers or routing rules.
An allowlist gives an app more opportunity to run in the background, which may increase rather than reduce battery use. Its purpose is to keep a needed connection alive, not to keep the client busy at all times. If relaxing restrictions doesn’t improve stability, undo changes that didn’t help and investigate the network, server and error logs. Avoid leaving every manufacturer-specific toggle enabled.
“Always-on VPN” is not the same as keeping an app alive in the background
On near-stock Android, go to Settings → Network & internet → VPN, then tap the settings icon next to v2rayNG to find “Always-on VPN.” Some manufacturers place this under Connections & sharing → VPN. Whether the option appears or can be enabled depends on the system and app support.
| Setting | What it does | What it doesn’t mean |
|---|---|---|
| Battery: “Unrestricted” | Reduces some background restrictions imposed by the system | Doesn’t guarantee the service will never stop or fix a server issue |
| Always-on VPN | Asks the system to maintain or restore the selected VPN service | Doesn’t guarantee the remote server is available or keep traffic flowing at high speed |
| Block connections without a VPN | Restricts network connections that don’t use the VPN when it’s unavailable | If the server fails, the whole device may lose internet access; this can affect bypass setups |
| Manufacturer auto-start | Relaxes additional manufacturer controls over app startup | Not available on every device and not the same as the system VPN policy |
For a long-running connection, first make sure it stays stable after you start it manually, then consider enabling “Always-on VPN.” Enable “Block connections without a VPN” only if you specifically want to prevent internet access when the VPN disconnects. If you use per-app bypass, retest excluded apps: the system’s blocking policy may prevent them from connecting directly as intended.
- Connect only when needed: If you don’t need a proxy all day, stop the service when you’re done. This makes background activity easier to control than leaving an idle connection running.
- Stay connected for longer: Keep only the necessary background permissions enabled, then test and record what happens when the screen is off, after a reboot and when the network changes.
- Recover from connection issues: If internet access stops after enabling connection blocking, first check the VPN toggle and connection status in system VPN settings. Don’t immediately reset all network settings.
Clear up common misconceptions and keep reproducible test results
Battery settings say the app used 20%. Does that mean the phone lost 20% battery?
Not necessarily. Check the screen’s explanation to see whether it shows relative usage over a reporting period or battery percentage points. Record the starting and ending battery levels and compare them with a service-off test of the same duration. An app ranking alone doesn’t prove how much extra battery it used.
Why does battery use go up after I add the app to the allowlist?
The background service can now keep running, so network activity that the system previously paused may continue. Check traffic increases and logs. If you only need the proxy while using it, turn off “Always-on VPN,” disconnect when you’re done and repeat the test under the same conditions.
Messages don’t arrive when the screen is off, then appear as soon as I wake the phone. What should I change?
First check whether v2rayNG is still connected, then check the messaging app’s own battery and background data permissions. If only one app is delayed, investigate that app first. If all apps using the proxy lose network access, compare the VPN service status and system Battery Saver settings.
Will switching to v2flyNG definitely save battery?
There’s no guarantee. v2rayNG uses the Xray core, while v2flyNG uses the v2fly core; their capabilities and implementations differ. Keep the network, server capabilities and workload consistent when comparing them. Don’t treat the core’s name as proof of its power use.
Keep a concise record of the client and Android versions, network type, server transport, per-app scope, log level, battery settings, and starting and ending battery levels and disconnect times for all three tests. Change one setting at a time to determine whether relaxing background restrictions helped or network conditions simply improved. For basic connection steps, see the Quick Start. To understand routing and DNS, see the Advanced Handbook.