For anyone whose phone gets hot or loses connection when the screen is off, or who sees v2rayNG near the top of the battery usage list. Start by comparing standby drain under the same conditions. Then separate background restrictions from traffic generated by other apps and repeated connection attempts. Change battery permissions, proxy coverage, or connection settings only when the tests point to them—repeatedly force-stopping the app isn’t the answer.
1. Read battery stats in context
v2rayNG uses Android’s VpnService to receive app traffic and pass it to the Xray core. Android’s battery stats may attribute some of the tunnel processing and network activity to v2rayNG, but attribution varies by device and OS version. A high ranking doesn’t mean the client is idling inefficiently, and the percentage shown isn’t the percentage points lost from your battery charge.
For example, “20% of battery used” usually means 20% of the power consumed during the selected period. It does not mean your battery fell from 80% to 60%. Check the time range, foreground and background activity, and actual battery drop before changing anything. Don’t draw conclusions from a single reading after a system update, a large photo backup, or an offline video download.
-
Check battery usage
On a typical Android 14 device, go to Settings → Battery → Battery usage and select v2rayNG. Some manufacturers call this screen “Battery usage ranking.” First check whether the stats cover the past 24 hours or the period since your last full charge.
-
Check background activity
Note foreground and background run time, actual battery loss, and the network used during the test. A long background time only shows that the service remained active; check traffic and logs to see whether it was continuously transferring data or retrying connections.
-
Check where the traffic comes from
Long-press the v2rayNG icon → App info → Mobile data & Wi-Fi to view available traffic stats. The menu may be called “Data usage.” Compare the numbers with video, cloud backup, and messaging apps to see whether anything is downloading in the background.
-
Record your test conditions
Note your Android and v2rayNG versions, node, Wi-Fi or mobile data connection, and battery permissions. Change one setting per test so you can identify what made a difference; changing the node, network, and routing all at once makes the results hard to interpret.
2. Compare fixed time windows to separate standby from transfer drain
The time windows below are suggested test durations, not results from a specific phone or battery-life targets. Battery wear, signal strength, and the accuracy of system stats vary widely, so there’s no universal “less than X% per hour” rule. A battery level that doesn’t change over a short test doesn’t prove there’s no extra drain.
| Test | Keep constant | Record |
|---|---|---|
| Standby with proxy off | Same Wi-Fi; screen off for 60 minutes; pause large file syncs | Battery level at start and end, and whether the phone gets warm; this is your system standby baseline |
| Standby with proxy on | Same location and duration; use the same node and keep app usage consistent | Difference in battery drain, background traffic, and any repeated disconnects |
| Transfer with proxy on | Set a fixed screen brightness and play the same content at the same quality for 15 minutes | Data usage, temperature, stutters, and when reconnections occur |
The proxy-off baseline shows how the system behaves at idle, but it doesn’t guarantee that every app will do the same thing. Some services behave differently when they can’t connect. A more useful follow-up is to keep the proxy on and change just one thing: try a stable node or narrow the list of proxied apps. Don’t charge the phone during the test; avoid starting just after a full charge or when the battery is nearly empty, and keep signal strength and ambient temperature similar.
Takeaway: Find the conditions that cause the drain before changing settings
If the phone gets warm only during transfers, check data usage and wireless signal first. If screen-off standby also causes a noticeable increase in battery drain, check background traffic and connection retries. Don’t disable background access just because v2rayNG ranks high in battery stats.
3. Balance background access and battery optimization
VPN permission, background activity access, and battery optimization are separate settings. Approving Android’s VPN prompt on first connection only allows the tunnel to be created; it doesn’t override your manufacturer’s background restrictions. A foreground service notification means the service is running, not that the CPU is constantly busy. And the notification alone doesn’t prove the remote server is reachable.
- Need messages to arrive in the background? Long-press the app icon → App info → App battery usage, then allow background use if that option is available. If the connection really drops when the screen is off, change the battery setting from “Optimized” to “Unrestricted.” Some Android versions call this option “Unrestricted” already.
- Only use it while the app is open? Keep the default battery setting and stop the connection from the v2rayNG home screen when you’re done. For occasional browsing, there’s no need to enable autostart, lock the app in the background, and turn on every keep-alive option.
- Manufacturer-specific background controls: Search Settings for “Autostart” or “Background activity.” Change these settings one at a time only if you’ve confirmed a problem, such as the app not restarting after a reboot or being killed when the screen locks. Then repeat the same screen-off test.
- Use Android’s always-on VPN: Go to Settings → Network & internet → VPN and open v2rayNG’s settings. “Always-on VPN” and “Block connections without VPN” are system policies, not battery-saving switches. The latter blocks network access when the tunnel isn’t available.
Allowing background activity can reduce interruptions caused by the service being stopped and restarted, but it doesn’t guarantee lower battery use. Broader permissions also let the service and related traffic keep running. If the connection becomes more stable but battery drain remains high, investigate actual traffic rather than stacking more keep-alive permissions. Before changing Android’s VPN policies, make sure you’re comfortable with what happens to network access if the tunnel stops.
4. Reduce unnecessary connections: check timeouts before changing settings
Unstable nodes, failed DNS lookups, and frequent network switching can cause apps to repeatedly retry connections. The apps waiting for messages, syncing, or downloading—not just the proxy core—may be keeping the wireless radio awake. Open Logs from the menu on the v2rayNG home screen and compare errors with the times connections drop. The menu location can vary between versions.
The following are examples of log messages you might see. A single line rarely identifies the root cause; consider the destination, how often the error occurs, and the network state before and after it. Before sharing logs, hide subscription URLs, credentials, server addresses, and the destinations you accessed.
Error: i/o timeout
What it means and what to try: A network read or write didn’t finish within the allowed time. The cause could be the connection, DNS, or the remote server. On the same network, try a known-working node, then check whether the timeout happens during name resolution, connection setup, or data transfer.
Error: connection refused
What it means and what to try: The destination actively refused the connection, often because nothing is listening on that port or the access settings are wrong. Check the node’s server port and service status instead of repeatedly running speed tests.
Error: network is unreachable
What it means and what to try: The system has no usable network route to the destination. This can happen when you’re offline, switching networks, or using an unreachable address family. Make sure Wi-Fi or mobile data is back, reconnect, and check whether the error continues.
- Limit bulk testing: During troubleshooting, test a few candidate nodes rather than repeatedly checking the entire subscription list. Speed tests actively open connections, creating traffic and processing overhead of their own.
- Keep the access network consistent: Run one test on Wi-Fi with a strong signal, then test mobile data separately. With a weak signal, changes in wireless power use can outweigh the effect of proxy settings.
- Check DNS resolution: If the logs point to DNS failures, review the DNS options in v2rayNG Settings and Android’s Private DNS setting. Change only one at a time and keep a note of the original value so you can revert it.
- Don’t apply generic keep-alive settings: Don’t add TCP keep-alive, Mux, or transport parameters at random to save power. Settings depend on the node, transport, and server support; shortening the keep-alive interval can increase periodic traffic.
5. Reduce unnecessary processing with per-app proxy and routing
If only a few apps need a proxy, start by narrowing which apps send traffic through the tunnel. In v2rayNG, go to Settings → Per-app proxy, enable the feature, and select apps as prompted. In some versions, the related switch is in a section with the same name on the Settings screen. Read the “Bypass” option carefully: in bypass mode, selected apps usually stay outside the proxy; in proxy-only mode, only selected apps use it.
| Setting | When to use it | What to check |
|---|---|---|
| Proxy selected apps only | Only a few apps, such as a browser, need to connect through the node | Whether messaging apps also need the proxy and whether you selected all the right apps |
| Bypass selected apps | Most apps should use the tunnel, with only specific apps excluded | Bypassed apps will use whatever network route is available to them |
| Routing rules within the tunnel | Different destinations in the same app need different outbound routes | Rule order, which rules match, and whether the destinations are routed as intended |
Per-app proxy controls which apps send traffic to the VPN; routing controls how connections that reach the core are sent out. They’re not interchangeable. Traffic matched by a direct-routing rule may still be handled by the client; routing it directly doesn’t mean the app bypasses the VPN entirely. Narrowing the traffic processed may help, but the results depend on background data use.
If cloud backups upload every night or a video app preloads content, pausing background sync or restricting downloads in that app is easier to verify than adding more routing rules. After each change, stop and restart the connection, then test apps that use the proxy and apps that bypass it separately. Don’t bypass traffic that needs protection or requires the proxy to work.
6. Match the fix to the symptom and keep settings you can verify
- Disconnects when the screen locks, reconnects when it wakes: Check the app’s battery settings and manufacturer background restrictions first. Note when it disconnects and confirm the node itself isn’t dropping. Test the “Unrestricted” battery setting before considering additional autostart options.
- Cool at idle, warm while downloading: Compare data volume, signal strength, and download speed first. Encryption, forwarding, and wireless transfers all use power; heat during sustained high-volume transfers doesn’t by itself point to a background activity problem.
- Traffic continues when you’re not using the phone: Check system updates, cloud sync, messaging apps, and repeated connections in the logs. If you narrow per-app proxy coverage, test apps one at a time rather than excluding everything at once.
- The problem started after an update: Note the client and Android versions before and after the update, along with any configuration changes. Back up important settings, then retest under the same conditions. Don’t change the node protocol, DNS, and battery settings all at once.
Takeaway: Prioritize a stable connection and a clearly defined proxy scope
Keep changes that show a clear improvement across two rounds of testing, and revert extra switches that don’t help. If the phone still gets warm on a fixed node and network without corresponding traffic, note the versions, test duration, and redacted logs to investigate client- or system-level issues.
A simple everyday approach works well: when you need to stay connected, allow necessary background activity and use a stable node; for temporary use, stop the connection when you’re done; when something seems wrong, check battery and data usage before changing settings one at a time. This avoids repeated guesswork and prevents trading delayed messages or unstable connections for battery savings you can’t confirm.