Identify what is using the battery first
After v2rayNG starts, it creates a local VPN interface, while the Xray core handles matching connections. Android's battery screen may attribute network activity through this interface to v2rayNG, so a high share of app battery use does not necessarily mean the core is running at full load continuously. Check total battery consumption, foreground time, background activity, and mobile data usage before deciding whether the usage is abnormal.
Start by recording results over one complete charge cycle. Keep your usual network conditions and usage habits, and note the battery change after one hour of standby, 30 minutes of continuous browsing, and 30 minutes of streaming online video. Then turn off v2rayNG and repeat the test with the same apps and similar brightness. The difference between the two rounds is more useful than the system ranking alone.
If the phone is noticeably warm, loses battery steadily while idle, or v2rayNG generates substantial traffic without any active network use, continue troubleshooting. If battery use rises only during video playback, file downloads, or heavy image loading, the load usually comes from encryption, forwarding, and network transfer together. Start by checking latency, packet loss, and proxy scope.
Narrow the per-app proxy scope
Global routing sends connections from more apps on the device through the local VPN interface. Messaging, cloud sync, weather, online keyboard services, media scanning, and system components may connect periodically in the background. Each request may be small, but frequent network and processor wakeups can add up. On devices where only a few apps need the proxy, per-app proxying is usually the most direct way to reduce the load.
Open v2rayNG's per-app proxy settings and first confirm whether the current mode is “Proxy only selected apps” or “Bypass selected apps.” The two modes have opposite meanings, and choosing the wrong one may send every background app that does not need the proxy through the core. To simplify the setup, keep only the browser, communication tools that need remote services, and apps that genuinely depend on the current configuration.
Banking, maps, local media, LAN controls, and apps that access only services in mainland China generally do not need to be added to the proxy scope just to use a single exit. Base bypass decisions on actual network requirements. After making changes, open common apps one by one and check sign-in, image loading, message delivery, and local-device access. This makes issues easier to isolate than removing many apps at once.
Per-app troubleshooting steps
- Record the current per-app mode and selected apps. If needed, capture the settings screen for comparison.
- Reduce the proxy scope to two or three frequently used apps while keeping the route and node unchanged.
- Lock the screen and leave the device idle for one hour, then check battery level, background activity time, and network traffic.
- Add one group of apps at a time and observe one complete test cycle after each change.
- If battery use suddenly increases, check whether a recently added app is syncing frequently in the background.
Per-app proxying only determines which apps enter the local VPN; it does not replace V2Ray routing rules. Once an app enters the proxy, routing rules can still decide whether each destination domain or IP connects directly, uses the proxy, or is blocked. To reduce unnecessary remote traffic as well, combine per-app scope with sensible mainland-China and outside-China routing.
Check heartbeats, connection tests, and subscription updates
Keeping a connection alive does not mean transferring large amounts of data continuously, but overly frequent heartbeats increase network wakeups. Idle connections are handled differently depending on the protocol, transport, and server configuration. WebSocket, gRPC, and TCP connections may be affected by mobile NAT, router idle timeouts, or server policies, so there is no heartbeat interval that fits every route.
During troubleshooting, restore related parameters to their defaults and avoid enabling several high-frequency checks at once. Connection tests, real-latency tests, automatic subscription updates, and an app's own background refresh can all generate periodic requests. If the interval is too short, the network may keep waking even with the screen off. For everyday use, manual testing is usually enough after changing nodes, noticing connection problems, or updating a subscription.
Subscriptions do not need to update every minute. Their contents change only when the provider updates nodes, ports, or parameters. Scheduling updates before actual use or at longer intervals better balances current configuration data with standby battery life. After an update, confirm that the selected configuration is still valid so the client does not repeatedly try to connect to an expired node.
Mux is not a universal battery-saving switch
Mux lets multiple logical requests share a connection, with the aim of reducing the overhead of establishing connections repeatedly. Whether it saves battery depends on the workload, route quality, server support, and connection duration. Reuse may reduce handshakes during many short concurrent requests; during long idle periods or frequent network changes, however, maintaining and re-establishing a connection may create extra activity.
So neither “enable Mux” nor “disable Mux” is a universal answer. Test both modes separately. Keep the same node, per-app scope, and a similar usage pattern: run with Mux off for half a day, then with Mux on for half a day. Compare standby drain, webpage response, video buffering, background message delivery, and recovery after switching networks.
If enabling Mux causes stalled connections, pages to wait for a long time, failure to recover after switching from Wi-Fi to mobile data, or repeated background reconnects, turn it off first and observe. If disabling it noticeably slows many short-connection workloads and the server confirms support for the relevant multiplexing method, it can remain enabled. When imported settings contain explicit subscription parameters, avoid overwriting them in bulk without understanding the server configuration.
Keep these conditions unchanged during comparison
- Use the same node and do not automatically switch to another configuration during the test.
- Keep the per-app proxy list unchanged.
- Keep the routing mode, DNS settings, and transport parameters unchanged.
- Use similar screen brightness, network type, and app combinations.
- Include at least one locked-screen standby period and one session of continuous network use.
Battery optimization exceptions and background operation
Android limits background networking, scheduled tasks, and process activity after the screen is locked. Some devices also add separate policies for auto-start, background operation, sleeping apps, or app freezing. If the system force-stops v2rayNG, the local VPN disconnects. The app or system may then repeatedly bring the connection back up, creating a stop-start-reconnect loop that hurts both stability and battery life.
When a connection must stay active for a long time, allow v2rayNG to run in the background in the system battery settings and, when necessary, add it to the battery optimization exceptions. Menu names vary by device and may include “Unrestricted,” “Allow background activity,” “Don't optimize,” or “Allow high background battery use.” Adjust v2rayNG only; there is no need to exempt every networked app.
If the proxy is enabled only temporarily, there is no need to keep it alive all day. When finished, stop the connection from v2rayNG's main screen and let the local VPN exit normally. This is more controllable than leaving it connected for the system to freeze forcibly. If you use it frequently, keeping background permission can reduce reconnects after each screen lock.
Also check the system's data-saver mode. Data Saver may restrict background transfers and delay app messages; v2rayNG may then consume more power by repeatedly retrying the connection. During testing, first allow v2rayNG to use background data and observe stability. Once the connection is stable, restrict background traffic for other apps according to your needs.
Route quality and DNS can affect battery use too
High latency, packet loss, and frequent disconnects make the client repeat handshakes, retransmit data, or resolve domains again. Even when the settings look correct, the processor and wireless radio then work more often. Node latency is only one indicator; sustained packet loss and connection stability usually matter more than a single speed-test result.
Start by selecting a configuration that remains stable over time in v2rayNG, and avoid running full tests repeatedly. If the same configuration works on Wi-Fi but keeps reconnecting on mobile data, the cause may be network switching, IPv4 or IPv6 reachability, the transport, or the server entry point—not just the client's battery settings. First confirm that the address, port, transport layer, TLS, and domain parameters in the subscription match completely.
Poorly chosen DNS settings can also cause repeated requests. For example, the resolved address may be unreachable, remote DNS responses may be too slow, or routing rules may repeatedly try DNS queries through both direct and proxied paths. Most users should start with the subscription and client defaults rather than stacking several custom DNS groups. When split routing is needed, make sure the resolution paths for mainland-China domains, local domains, and other domains match their respective routing exits.
Avoid sending LAN addresses and local domains to remote DNS unnecessarily. For domains that must be accessed through the proxy, prevent the client from first receiving an answer that the current network cannot reach directly. After each DNS change, reload the configuration, then test initial webpage load time, recovery after waking from sleep, and sign-in to commonly used apps.
A complete troubleshooting workflow
- Establish a baseline: Record standby battery drain, traffic, and temperature with v2rayNG enabled and disabled.
- Pin the node: Choose a stable configuration and pause automatic switching and repeated speed tests.
- Trim the scope: Use per-app proxying and keep only apps that genuinely need the proxy.
- Restore defaults: Return uncertain heartbeat, connection-test, and Mux parameters to their default states.
- Reduce scheduled tasks: Lengthen subscription-update and automatic-test intervals to avoid frequent wakeups after the screen locks.
- Set background permissions: For long-term use, allow v2rayNG to run in the background to prevent repeated stops and reconnects.
- Test Mux separately: Observe enabled and disabled states independently without changing other settings.
- Check split routing: Confirm that local and mainland-China services connect directly as needed, while other traffic enters the proxy.
- Check DNS: Avoid resolution timeouts, mismatched exits, and duplicate queries.
- Retest a complete cycle: Include locked-screen standby, continuous browsing, video playback, and a network switch.
If abnormal battery use appears only with one node and disappears after switching to another node using the same protocol, check that node's route quality and server parameters first. If every node disconnects after the screen locks, focus on system background restrictions. If battery use rises noticeably only when one app is running, check that app's background sync, media loading, and whether it actually needs the proxy.
Clearing app data or reinstalling should be a last resort because it removes subscriptions, routes, and custom settings. Save any necessary subscription information first. After importing again, connect with the default parameters and do not immediately restore every advanced setting. Restore one item at a time and observe the result to identify the combination that actually causes the problem.
The final balance between stable connections and battery life
The goal of power-saving settings is not to stop v2rayNG from all background activity, but to reduce pointless tests, reconnects, DNS lookups, and unnecessary proxied traffic. When instant messaging and long-lived connections are needed, give the client stable background operating conditions. For browsing or temporary tasks, start it when needed and stop it deliberately afterward.
Most devices can start with this combination: proxy only the necessary apps, keep the core connection parameters supplied by the subscription, reduce automatic speed tests, lengthen the subscription update interval, leave Mux at its default initially, allow v2rayNG to run in the background during long-term use, and use routing rules to connect locally and to frequently used mainland-China services directly. Then fine-tune based on actual battery drain and network recovery speed.
To judge whether a change worked, check three results together: whether standby drain decreased, whether the connection stays up after the screen locks, and whether it recovers promptly after a network switch. Chasing the lowest background drain may lead to delayed messages and frequent manual reconnects; keeping everything constantly active may cause unnecessary network wakeups. Choosing the operating mode for your actual usage periods is usually more reliable than applying one fixed parameter set.