This guide is for users seeing overnight battery loss, a warm phone, frequent background disconnects, or an unusually high v2rayNG battery share. Establish a baseline first, then adjust background controls, narrow proxy coverage, and check DNS, reconnects, and Mux to identify the real cause.
First determine whether the proxy is using power or the battery stats are misleading
The percentage shown on Android’s battery page is an app’s share of battery use during a reporting period; it does not mean the app consumed the same percentage of the phone’s total charge. If the phone loses 4% and v2rayNG accounts for 25%, its estimated contribution is about 1 percentage point. Further investigation is warranted when the phone loses 18% overnight while v2rayNG keeps mobile-network activity alive.
Before testing, keep screen brightness, network type, active node, and app set consistent. Do not compare Wi-Fi standby with video playback over mobile data. Start at about 80% charge and record 30 minutes with the screen on and 6 hours with it off. Disable system updates, photo sync, and large downloads during testing so other background tasks do not skew the results.
v2rayNG receives traffic through the system VPN interface, then passes it to the Xray core for DNS, routing, and outbound connections. While the proxy is enabled, Android may attribute other apps’ network activity to the VPN app, so v2rayNG’s battery share can include some forwarding overhead. Focus on persistent wakeups, repeated dialing, excessive DNS queries, and unnecessary full-device proxying.
| Test | How to record it | Warning signs |
|---|---|---|
| 6 hours with the screen off | Record the starting and ending battery levels and network type | More than 8% battery loss with no active tasks, while the phone stays warm |
| 30 minutes of web browsing | Keep brightness fixed and visit the same pages | Battery loss with the proxy exceeds twice the loss without it |
| Background activity | Check foreground and background duration in the system battery details | Background activity continues for nearly the entire screen-off test |
| Connection logs | Check whether the same errors repeat continuously | Timeout, resolution, or reconnect entries every few seconds |
Adjust battery controls and background operation
Looser battery controls do not always save more power. If the system repeatedly terminates the VPN service, v2rayNG must recreate the VPN interface, resolve the node address, and reconnect, creating a terminate–restart–reconnect loop. Stable background operation is usually more efficient than a cold start every few minutes and also reduces lock-screen message delays.
Menu labels vary slightly across Android vendors, but the goal is the same: let v2rayNG run in the background, disable automatic freezing for it, and keep the system VPN’s persistent notification. The paths below reference common Android 14 and Android 15 settings layouts and the v2rayNG 1.10.x interface.
Remove battery restrictions
Open system “Settings” → “Apps” → “v2rayNG” → “App battery usage” and choose “Unrestricted” or the equivalent option. Do not also place the app on a vendor sleep or freeze list.
Allow background data
Go to “Settings” → “Apps” → “v2rayNG” → “Mobile data & Wi‑Fi” and enable background data. If the app must run while Data Saver is enabled, also turn on “Unrestricted data usage.”
Add v2rayNG to the background allowlist
In the device’s “Battery” → “Background usage limits” or “App launch management,” allow auto-start, associated launch, and background operation. If the vendor provides only one master switch, disable automatic management for v2rayNG.
Keep the persistent notification
Go to “Settings” → “Notifications” → “v2rayNG” and keep the VPN service notification enabled. It shows foreground-service status; hiding it should not involve force-stopping the app.
Recreate the connection once
Return to the v2rayNG main screen, stop the current connection, wait 5 seconds, and start it again. Lock the screen for 10 minutes, then confirm that the VPN indicator and network access still work normally.
Some systems also offer “Lock recent tasks.” This mainly prevents the process from being ended by a one-tap cleanup and cannot replace the battery allowlist. After completing these settings, avoid stacking multiple so-called background booster tools; competing managers often create duplicate wakeups by changing process priority at the same time.
Bottom line: background operation should be stable, not constantly active
The desired state is a long-lived VPN service with substantially fewer connections and DNS requests while the screen is off. A long background duration with no continuous network activity is usually normal for a foreground service. If the log shows a reconnect every few seconds, investigate the node, DNS, or network changes.
Narrow the workload with per-app proxying and routing rules
A full-device VPN receives traffic from every app, including system sync, local-device discovery, software updates, and media backups. Even when the final rule sends that traffic direct, it may still pass through the VPN interface and routing checks. Proxying only the apps that need it directly reduces connection count, DNS queries, and core processing time.
v2rayNG’s per-app proxy works well when the app set is relatively stable. Go to “Settings” → “Per-app proxy,” enable it, select the apps that should use the proxy, and confirm that the mode is “Proxy selected apps.” Do not reverse the selection logic. Depending on the version, the choices may appear as “Bypass selected apps” and “Proxy selected apps”; read the description before saving.
Record the current configuration
Before changing anything, capture the current per-app proxy and routing settings and note the server in use. If access changes, you can revert individual items instead of importing the entire subscription again.
Reduce the app set
Go to “Settings” → “Per-app proxy” and start with only 2 to 5 apps that genuinely need the proxy. Keep a browser as the test entry point so you can verify that the proxy exit is working.
Set local-network traffic to direct
Go to “Settings” → “Routing settings” and confirm that private address ranges use a direct connection. Common ranges include
10.0.0.0/8,172.16.0.0/12, and192.168.0.0/16.Remove duplicate rules
Delete custom rules that do the same thing or conflict in order. When routes are matched from top to bottom, put specific block and direct-connection conditions before broad proxy rules.
Retest for 30 minutes
Keep the same node and network while performing your usual tasks for 30 minutes. Compare connection count, phone temperature, and battery loss per hour before deciding whether to expand the app set.
| Traffic type | Recommended outbound | Why it saves power |
|---|---|---|
| Home router and local-network devices | Direct | Prevents local requests from reaching a remote node and retrying after failure |
| System updates that do not need a proxy | Direct or exclude from per-app proxying | Keeps large transfers off the VPN interface |
| Apps that require a fixed proxy exit | Proxy | Preserves required functionality without taking over the entire device |
| Ads and known tracking domains | Block by rule | Reduces useless connections, but avoid endlessly stacking rules |
Check DNS timeouts, network changes, and repeated reconnects
High battery use is often caused not by encryption itself, but by repeated retries after failed connections. Weak mobile signal, failed node-domain resolution, unreachable IPv6 paths, or frequent Wi-Fi/mobile switching can make the core repeat DNS lookups and TCP dials. A dense pattern of the same error in the log is more diagnostic than a single error.
Open the log on the v2rayNG main screen, stop unrelated apps from using the network, and observe for 2 to 3 minutes. An occasional context canceled is common when switching nodes or stopping the service manually. If a timeout repeats every few seconds, check node reachability, DNS, and the current network instead of simply relaxing background permissions.
Error: dial tcp: i/o timeout
Cause and fix: The destination did not complete the connection within the time limit, commonly because the node is unreachable, the signal is weak, or the port is restricted. Test another working node on the same network, then compare Wi-Fi with mobile data to prevent the client from repeatedly dialing an unusable address.
Error: failed to find an available destination
Cause and fix: DNS resolution, the routing target, or the outbound path could not provide a usable address. Check the server address and DNS configuration, update the subscription, restart the core, and make sure the node domain is not mistakenly being sent back through the same proxy outbound.
Error: context canceled
Cause and fix: The connection context was stopped. This is normal when disconnecting manually; if it continues after the screen is turned off, check whether the system keeps terminating the VPN service and reset the battery allowlist and background permissions.
Error: network is unreachable
Cause and fix: The current network has no usable route for the relevant address family. Compare another network, check whether the node returns only unreachable IPv6 records, and avoid repeatedly tapping reconnect before the network has recovered.
Keep DNS configuration simple and explainable. Do not stack multiple remote DNS servers, FakeDNS, and complex fallback conditions before judging battery use. Start with one stable local or remote resolver and confirm that the node domain resolves; add rules later if split routing requires them. DNS commonly uses port 53, while encrypted DNS uses the port defined by its protocol and endpoint; changing the port to 853 alone does not configure it.
Recommended fields to record
Test network: Wi-Fi / mobile data
Test duration: 30 minutes with the screen on, 6 hours with it off
Active node: keep the same server
Timeout count: number of i/o timeout entries in the log
Reconnect interval: seconds between consecutive errors
Battery loss per hour: battery difference ÷ test duration in hoursBottom line: eliminate repeated failures before fine-tuning parameters
When the node retries every 5 to 10 seconds, changing Mux or per-app proxying can only hide part of the symptom. First get the log free of recurring timeouts, then compare power settings under identical test conditions.
Mux is not a guaranteed power-saving switch
Mux lets multiple logical connections share one underlying connection, which can theoretically reduce repeated handshakes. It does not guarantee lower power use on every network or with every server configuration. With many long-lived connections, a stable network, and proper server support, multiplexing may reduce connection setup. On weak networks, during frequent cell-tower changes, or with poor server handling, one failed multiplexed connection can force multiple requests to be rebuilt.
Do not judge battery use solely by a lower connection count. Also watch time to first byte, retry failures, and whether connections survive with the screen off. Mux can be tested when a site uses many short-lived web connections. For real-time communication, continuous downloads, or nodes that already provide their own stream multiplexing, the benefit may be minimal.
| Scenario | Mux test approach | Metrics to watch |
|---|---|---|
| Stable Wi-Fi with many short-lived connections | Test with Mux off and on separately | Connections established within 30 minutes and time to first byte |
| Frequent mobile-network switching | Start with Mux off to establish a baseline | Recovery time after switching, timeouts, and reconnect count |
| Continuous downloads or video streaming | Usually do not rely on Mux for power savings | Throughput stability, device temperature, and battery loss per hour |
| Server does not properly support it | Keep Mux off | Protocol errors, dropped connections, and failed page loads |
Open the current server’s edit screen and check the Mux setting under transport or advanced parameters. Subscription-imported nodes may overwrite manual changes during updates, so confirm the effective value before each test round. With a custom full configuration, inspect multiplexing in the outbound object rather than relying only on the name shown on the main screen.
Bottom line: decide on Mux through two controlled comparisons
Keep the node and network fixed, test for 30 minutes in each mode, and record timeout count and battery loss. If the difference is under 2 percentage points and connection stability is similar, the default is fine. If enabling Mux clearly increases reconnects, turn it off and check server support first.
Run the final retest in a fixed order
After troubleshooting, restore a reproducible everyday configuration. A good configuration meets three conditions: no disconnect after the screen locks, no recurring errors in the log, and stable battery loss over time. Looking at only one condition can mislead you; force-stopping background activity may temporarily reduce drain while breaking notifications and background connectivity.
- Update the subscription and select a verified working node. Do not let the server switch automatically during testing.
- Restart v2rayNG, keep the screen off for 10 minutes, and confirm that the VPN remains active.
- Run a 30-minute test with a fixed app set and record starting charge, ending charge, network type, and phone-temperature changes.
- Run a 6-hour screen-off test. Disable active downloads and large sync jobs, but keep normal message delivery enabled.
- Check timeout, resolution-failure, and reconnect counts in the log and compare them with the pre-change record.
- After two consecutive results are similar, gradually add other apps that need the proxy.
| Retest result | Assessment | Next step |
|---|---|---|
| Stable with the screen off, quiet logs, lower battery drain | Background and routing changes worked | Keep the configuration and gradually restore required apps |
| Disconnects with the screen off and recovers only after waking the screen | The system is still restricting the background service | Recheck the battery allowlist, background data, and startup management |
| Persistent heat with frequent timeouts | The node or network path is abnormal | Switch to a verified node and compare another network |
| Stable connections but high drain with full-device proxying | The proxy scope is too broad | Enable per-app proxying and add direct-connection rules |
Frequently asked questions
Why does v2rayNG take such a large share on the battery page?
Android may attribute some network activity routed through the VPN interface to v2rayNG. Check total battery loss, background duration, and retry frequency in the log instead of judging by the app percentage alone.
Will choosing “Unrestricted” definitely use more battery?
Not by itself. It mainly prevents the system from repeatedly terminating the VPN service. Stable standby is usually more predictable than repeated termination, resolution, and reconnects, but it still needs sensible per-app proxying and routing.
What should I do if some apps cannot connect after enabling per-app proxy?
First confirm whether the mode is “Proxy selected apps” or “Bypass selected apps,” then check whether the target app depends on another system component for connectivity. Temporarily include the related component for comparison instead of switching straight back to full-device proxying.
Are the troubleshooting steps the same for v2rayNG and v2flyNG?
The approach to system background permissions, per-app proxying, and network baselines is similar, but the cores and some menus differ. v2rayNG uses the Xray core, while v2flyNG uses the v2fly core; follow each app’s interface for log fields and exact parameters.
Can switching protocols solve battery drain directly?
The protocol is only one factor. Packet loss, DNS timeouts, network switching, and full-device proxying are usually worth checking first. Only a controlled comparison with the same node can show whether VMess, VLESS, or another configured protocol makes a real difference.