First distinguish battery attribution from actual drain, then run a screen-off comparison on the same network to pinpoint the issue. This guide is for Android users experiencing heat after connecting, dropped traffic when the screen locks, or frequent background reconnects. Check battery permissions, VPN coverage, nodes, and logs in order instead of disabling every background restriction at once.
1. A High Battery Percentage Doesn’t Always Mean Excessive Drain
v2rayNG uses the Xray core to handle proxy connections and typically creates a virtual network interface through Android’s VPN service. When other apps’ traffic passes through this route, forwarding, encryption and decryption, and some network activity may be attributed to v2rayNG in battery stats. Attribution varies by Android version and device manufacturer, so the app’s ranking alone doesn’t prove there’s a problem.
For example, “20%” on the battery screen may mean that v2rayNG used one-fifth of the power consumed during the reporting period—not that the battery lost 20 percentage points. Check the reporting period, total battery drain, screen-on time, and data usage before deciding whether the client is adding significant load. A high ranking during sustained downloads or video playback is not unusual.
These figures describe a test plan, not acceptable battery-drain thresholds. Battery percentages are rounded, so a one-point difference over 30 minutes may just be measurement noise. If the results are unclear, extend the test to two hours and repeat under the same conditions. Don’t compare days with different signal strengths or screen-on times.
- Where to check: On near-stock Android, go to Settings → Battery → Battery usage. Some manufacturer interfaces list it under “Battery usage ranking.”
- Record these too: Battery level at the start and end, screen-on time, Wi-Fi or mobile data, download usage, and any connection drops.
- Rule out other activity first: Avoid testing during system updates, bulk app updates, photo syncing, hotspot use, or heat caused by charging.
2. Keep v2rayNG Running in the Background—Only Where Needed
Strict background limits may stop the VPN service, causing notifications to disappear after the screen locks or the connection to restart when you unlock the phone. But removing every restriction isn’t a battery-saving measure: it lets the service run continuously, which may use less power only if it prevents repeated restarts. Relax restrictions one at a time, and only after confirming that the service is being stopped.
-
Note your versions
In v2rayNG, open About from the sidebar and note the client version. Also record the Android version under Settings → About phone. Menu names vary by release, so note the exact option labels you see while troubleshooting.
-
Check battery permissions
On near-stock Android 13, go to Settings → Apps → See all apps → v2rayNG → App battery usage. If it’s set to Restricted, change it to Optimized and test with the screen locked after connecting.
-
Relax restrictions only if needed
If you confirm that the service is still being stopped, try Unrestricted. Some manufacturers call this “Allow background activity” or “No restrictions.” Change this for v2rayNG only; don’t disable battery management globally.
-
Check manufacturer task-killing settings
If the system has a separate Auto-start manager or background-cleanup list, allow v2rayNG as needed. Check auto-start only if the service needs to resume after a reboot. Allowing auto-start does not guarantee that the client will connect automatically.
-
Test again with the screen locked
Keep the same node and network, lock the screen for 30 minutes, then check that the service works before reviewing its status and logs. A visible notification is only a clue; notification permission may also be disabled.
3. VPN Mode and Per-App Proxy: Limit Which Apps Are Routed
VPN mode determines how traffic enters the client; it doesn’t mean all traffic goes through a remote node. Routing rules can direct traffic to a direct, proxy, or blocked outbound. However, traffic that enters the virtual interface may still be processed locally even if it ultimately goes direct. Per-app proxy settings determine earlier in the process which apps use this VPN route.
In the v2rayNG sidebar, open Settings and find Per-app proxy. Turn it on using the available switch, then select apps. Some versions offer “Bypass mode”: when enabled, selected apps usually bypass the proxy; when disabled, only selected apps usually use it. Read the on-screen explanation before changing the list so you don’t reverse its meaning.
| Configuration | What it handles | Best for investigating |
|---|---|---|
| All apps use the VPN | Most app traffic enters the client, then routing rules determine its outbound | Finding out whether a background app is generating heavy traffic |
| Proxy only selected apps | Apps on the list use the VPN route | When only a few apps, such as a browser, need a proxy |
| Bypass selected apps | Apps not on the list use the VPN route | Excluding high-traffic apps such as downloads or video |
| Route traffic directly | Traffic enters the client and is matched to a direct outbound | Choosing outbounds for domains and IP addresses |
After changing the per-app list, stop and restart the service so the VPN interface is created with the new settings. Test one selected app and one app that isn’t selected; don’t rely on the key icon alone. Check payment apps, work networks, and access to local devices individually if they have special requirements. Don’t remove apps that must use the proxy just to lower v2rayNG’s battery ranking.
4. Troubleshoot Frequent Reconnects, DNS, and Keep-Alive
Weak mobile signal, switching between Wi-Fi and mobile data, or an unreachable server can cause repeated connection attempts. Cellular radio activity after each transmission also affects battery use, so low background data alone doesn’t prove that power consumption is low. Start by using a stable network and checking the logs; this is usually more useful than changing low-level connection parameters right away.
Use Logs in the v2rayNG sidebar to check whether errors keep appearing. The examples below may appear in logs; exact prefixes, addresses, and wording vary by core version. A one-off timeout is common. Investigate further only if errors keep recurring and coincide with battery drain or connection drops.
Error: i/o timeout
Possible cause: A connection or read/write operation didn’t complete in time. The link may be unstable, or the destination may not be responding.
What to try: Keep the current network and switch to a known-working node for comparison. Then keep the node and switch networks. Don’t change both at once.
Error: connection refused
Possible cause: The destination port isn’t accepting connections, or an intermediary is actively rejecting them.
What to try: Check that the node address and port match the server settings. If the node came from a subscription, update the subscription and test again. Repeatedly tapping Connect won’t fix an incorrect port.
Error: no such host
Possible cause: The current name-resolution process couldn’t find an address for the destination. The domain may be misspelled, or there may be an issue with the DNS response or configuration.
What to try: First check that the node’s domain is correct, then review DNS-related options in Settings. If you use a custom configuration, check the core’s DNS settings too. Encrypted DNS isn’t a battery-saving measure.
Keep-alive can refer to two different things: letting the service run in the background, and periodically sending data at the TCP, transport, or application layer. Don’t use a keep-alive interval of a few seconds to work around Android stopping the app; shorter intervals can increase network activity. If you’ve changed connection parameters in a custom configuration, save a copy, restore the defaults, and see whether any adjustment is actually needed.
- Stop repeated tests: Don’t run speed tests on every node one after another while troubleshooting; each test creates connections and uses data.
- Limit verbose logging: Temporarily increase log detail only when needed, then restore the normal level once you have the evidence. Leaving verbose logging on can generate a large volume of logs.
- Check protocol settings: VMess, VLESS, and other protocols must match the server configuration. A different protocol name doesn’t automatically mean higher battery use; it depends on the transport and traffic volume.
5. Use Three Comparisons to Pinpoint Battery Drain
Note the current client version, node, routing mode, and per-app list. Keep screen brightness, background sync, and network conditions consistent. Don’t charge the phone or run speed tests during the trials. Then test in this order. Test with the proxy off only in an environment where direct internet access is allowed. If a VPN is required, use another controlled comparison with the same protection in place.
- Test A: Service stopped. Record battery drain over 30 minutes with the screen off. This gives you a baseline for the phone’s background activity.
- Test B: Service running with current VPN coverage. Use the same node and routing settings. Record battery drain, background data, log errors, and whether the connection stays up.
- Test C: Only necessary apps use the VPN. Leave everything else unchanged, restart the service, and observe for another 30 minutes.
If battery drain is high in both A and B, check signal, syncing, and system tasks first. If B is clearly higher than A and C reduces the drain, focus on background apps removed from the list. If both B and C are high and the logs show repeated timeouts, check the node and network first. Consider client-version or device-compatibility issues only if the phone continues to heat up on a stable network with little traffic and no reconnects.
6. FAQ: Connection Drops and Heat with the Screen Locked
Can turning off battery optimization make battery drain worse?
After restrictions are removed, the service may finally run continuously, restoring background traffic that was previously interrupted. Compare total data use and the number of connection drops first. If there’s no improvement, restore Optimized mode and narrow VPN coverage with the per-app list; there’s no need to keep the setting on Unrestricted.
If web pages won’t load after 30 minutes with the screen locked, does that mean Android stopped the app?
Not necessarily. Check the system VPN status first, then review the service logs. If the service is still running but connections are timing out, check the node, DNS, and network switching. If the service has stopped, focus on app battery usage and the manufacturer’s background cleanup settings.
Does global mode use less battery than routing rules?
There’s no universal answer. Global proxying may increase remote traffic, while routing rules require local processing. The actual difference depends on traffic, the network path, and the rules. Test with the same node and apps; don’t judge by the mode’s name alone.
What happens if another VPN app is running at the same time?
On Android, only one VPN service can usually be active at a time for the same user or profile. Local filtering or packet-capture apps that also use the VPN interface may replace the current connection. Check the system VPN screen to see which service is active, and leave only the one you’re testing enabled.
A practical troubleshooting order is: verify actual battery drain, check whether the service is being stopped, narrow VPN coverage, then investigate timeouts and reconnects. Once the connection is stable, background data is reasonable, and battery drain is repeatable under consistent conditions, there’s no need to keep adding keep-alive settings.