v2rayNG Android Essentials: VpnService Permissions, Battery Optimization and Per-App Proxy Settings

After importing VMess, VLESS, or subscription nodes into v2rayNG, tapping the connect button only starts the core process. Whether Android allows a VpnService connection, background scheduling keeps the app running, and the per-app rules use the right mode all directly affect real traffic. Common symptoms such as “connected” status with no apps using the node, disconnections after several minutes of screen-off time, or only some apps failing to load usually do not mean the subscription has expired. More often, these three layers are out of sync.

This guide uses the common v2rayNG 1.10.x interface as its reference. Android vendors may rename battery-management screens as “background power management,” “app launch management,” or “battery optimization,” but the goal is the same: let v2rayNG keep running and confirm that the system VPN indicator appears in the status bar. If menu names differ, search the system settings for “battery optimization” or “background activity.”

First connection: confirm that VpnService access is active

v2rayNG uses Android’s VpnService to create a virtual network interface, then passes matching connections to the Xray core. The first time you tap the connect button in the lower-right corner of the main screen, Android displays a connection request, usually worded “Allow this app to set up a VPN connection.” This is a system permission, not a server-account check. Without granting it, the node list may display normally and latency tests may still return results, but traffic from other apps will not enter the virtual interface.

After granting access, look for three signals at once: the v2rayNG connect button shows an active state, a persistent v2rayNG notification appears, and the status bar displays the system VPN indicator. If only the button changes, return to system settings and check for a conflicting old VPN profile. Android normally allows only one VpnService-based connection to take control of traffic at a time; another active network tool can cause the new connection to stop immediately.

1. Select a node

   On the main screen, tap an imported VMess or VLESS node so its selection marker shows it as active. If the subscription contains several nodes, start with one that has stable latency rather than judging the route by its name alone.

2. Start the connection

   Tap the circular connect button in the lower-right corner. On the first run, Android displays a VpnService request. Choose “OK” or “Allow”; do not return to the home screen to dismiss the prompt.

3. Check the status

   Pull down the notification shade and confirm that the persistent v2rayNG notification and the system VPN indicator are both present. If the connection stops automatically within 1–2 seconds, open “Logs” from the side menu and inspect the first error.

4. Test traffic

   Close and reopen the target app, then visit a page that is normally reliable. Do not use node latency alone as proof of connectivity: a latency test and an app’s real request do not follow the same complete path.

Background disconnects: battery optimization and activity limits

Android’s power-saving policies can restrict background processes, network wakeups, and scheduled tasks after the screen turns off. When an ordinary app is paused, it can reload the next time you open it. When a proxy client is paused, however, the virtual interface may remain visible briefly while the core process can no longer forward data reliably. The result is a false connection: the notification remains, but pages time out. Some systems impose these limits after 10–30 minutes of screen-off time; others switch to a stricter power-saving mode when the battery falls below 20%.

Do not enable only “Allow notifications.” Notification permission controls whether the status is visible; battery optimization determines whether the background process can keep running. The usual Android path is “Settings” → “Apps” → “v2rayNG” → “App battery usage” → “Unrestricted.” Another path is “Settings” → “Battery” → “Battery optimization” → “All apps” → “v2rayNG” → “Don’t optimize.” If the system also offers “Allow background activity” and “Auto-start,” enable both.

Verify the setup with a screen-off test

• After connecting to a node, open an app that needs a continuous connection and confirm that foreground requests work normally.
• Lock the screen for 15 minutes. Do not swipe v2rayNG away from the recent-apps list during the test.
• Unlock the device, refresh the page immediately, and note whether the first response takes more than 5 seconds.
• Lock the screen for another 30-minute test. If failures occur only after extended screen-off time, check battery optimization before changing nodes.
• If the connection drops while switching between mobile data and Wi-Fi, wait 3–5 seconds for the default network to re-establish, then check whether the connection recovers automatically.

A reproducible test is easier to diagnose than an occasional disconnect. For example, if 20 minutes of foreground use is normal, the first request times out after 30 minutes of screen-off time, and reopening v2rayNG restores service immediately, the symptoms clearly point to a background restriction. If packets are also lost in the foreground, or every node fails at the same time, continue by checking the local network, DNS, and subscription node status.

Per-app proxying: choose the traffic scope carefully

Per-app proxying determines which Android apps enter v2rayNG’s virtual interface. It is separate from Xray routing: per-app scope filters traffic by application first; once traffic reaches the core, domain and address rules can still select proxying, direct access, or blocking. If an app is not included in VpnService, later domain rules cannot affect it.

The usual path is v2rayNG’s side menu: “Settings” → “Per-app proxy.” After enabling the main switch, an app list and “Bypass mode” appear. With bypass mode off, only selected apps use the proxy. With bypass mode on, selected apps connect directly and all others use the proxy. After changing the list, disconnect and reconnect once so VpnService rebuilds the interface with the new scope.

Verification order after setup

1. Select one browser only, keep bypass mode off, and reconnect.
2. Send a request in that browser and confirm that it loads normally.
3. Open another unselected app and confirm that it still uses the regular network.
4. Add target apps one at a time, changing only one variable per test.
5. If an app still is not affected, check whether it sends network requests through a separate process or system component.

Nodes, subscriptions, and the core: keep the configuration layers separate

v2rayNG uses the Xray core to process VMess, VLESS, and related configurations. A subscription supplies nodes in bulk; the client stores the selection, starts VpnService, and displays logs; the core handles protocol handshakes, routing, and transport. A successful subscription update does not mean the active node changes automatically. If the previous node was removed or its parameters changed, select a node again after the update and reconnect.

Do not infer every parameter from the protocol name. VLESS may use TCP, WebSocket, or gRPC transport and may include TLS or REALITY fields. VMess nodes likewise require the server address, port, user ID, transport, and security settings to match. Manually changing any field can break the handshake, so use the complete subscription configuration supplied by the service.

Understanding common local parameters

10808 and 10809 are common local listening ports, but they do not have to remain the same in every version, and changing them arbitrarily will not make the connection “faster.” In VpnService mode, ordinary Android apps use the virtual interface to capture traffic and do not require users to enter these ports manually. Check them only when the logs report a port conflict or a local program needs a manual proxy.

Connection problems: troubleshoot permissions, background activity, scope, and DNS in order

First identify which layer the problem belongs to. If VpnService was not established, no app traffic reaches the core. If the background process is restricted, the connection is usually fine immediately after startup but fails after the screen is locked. If the per-app scope is reversed, only specific apps are affected. DNS or routing problems often appear as some domains failing while direct address access behaves differently. Checking in this order avoids deleting the subscription or switching nodes repeatedly at the start.

An actionable checklist

• The status bar shows the system VPN indicator, and the notification shade shows the persistent v2rayNG notification.
• A node is clearly selected, and the connection was restarted after the subscription update.
• The system battery policy is set to “Unrestricted,” with background activity and auto-start allowed.
• The per-app proxy bypass mode matches the meaning of the selected-app list.
• Temporarily disable custom routing for comparison, then restore the proxy and direct-access rules you need.
• Test Wi-Fi and mobile data separately to distinguish local network problems from node problems.
• Record when the error occurs, then inspect core logs from around the same time instead of looking only at the last line.

A stable configuration does not require every switch to be enabled. Each layer needs a clear responsibility: the system must establish and keep VpnService running, per-app proxying must define the traffic scope accurately, Xray routing must handle domains and addresses, and the subscription must provide complete node parameters. After one layered verification, future disconnects or partial failures can usually be traced within minutes to system permissions, local policies, or the remote node.