v2rayNG on Android: VPN Permissions, Battery Optimization & Per-App Proxy

At a glance

On Android, “connected but apps can’t reach the internet” and “disconnects when the screen locks” usually have different causes. First check VpnService permission and VPN mode, then review background battery restrictions, and finally choose which apps use the tunnel. This guide covers system settings, per-app routing, and retesting for v2rayNG users who have already imported a server and need a reliable background connection.

VpnService permission: routing traffic doesn’t mean the server works

v2rayNG is an Android client that uses the Xray core to handle proxy protocols. VpnService is Android’s mechanism for creating a virtual network interface. In VPN mode, Android routes eligible app traffic through that interface, and the client passes it to the core. “VPN” here describes how Android routes traffic; it doesn’t mean the server uses a traditional VPN protocol.

The first time you connect, Android displays a connection request explaining that the app wants to set up a VPN connection. Confirm it to let Android create the interface. A VPN icon in the status bar only confirms that the system-level connection is active. The icon may still appear even if the server address, port, credentials, or transport settings are wrong—and webpages may not load.

VPN services active at the same time under one user or profile

API 23

Android 6.0 introduced Doze

API 33

Android 13 introduced runtime notification permission

When another VPN-based app starts under the same user or profile, it may replace the current connection. Some local filtering apps also use VpnService, so don’t assume an app is harmless just from its name. Work and personal profiles may manage VPNs separately; check the profile where the app is actually running.

VPN permission: Allows the client to create a virtual interface. It is not permission for a subscription account, and it does not require device administrator access.
Notification permission: Controls whether notifications are shown. Denying notification permission on Android 13 or later does not necessarily prevent a foreground service from running, so don’t use it alone to determine whether the connection is active.
Server availability: Verify it by testing access and checking core logs. The Android VPN icon is not a substitute for either check.

First connection: check mode, permission, then access

Start with a known-good server to establish a baseline. Don’t change DNS, routing, and the per-app list at the same time. The menu names below match common labels in the Chinese version of v2rayNG; wording and placement may vary by release, so follow the descriptions shown in your app. System settings paths use near-stock Android labels; on other devices, search Settings for the equivalent option.

Check the connection mode

Open the v2rayNG side menu and go to “Settings” → “VPN settings.” Make sure VPN mode is selected. If your version puts the mode selector in the main screen menu, choose VPN there. Proxy-only mode does not automatically route traffic from other apps.
Temporarily disable per-app routing

Open “Per-app proxy” from the side menu and temporarily turn it off. First test the full VPN connection, then add apps one at a time to avoid confusing a server problem with an app selection issue.
Confirm system permission

Return to the main screen, select a server, and tap Connect. Confirm Android’s “Connection request.” If the prompt doesn’t appear, check “Settings” → “Network & internet” → “VPN” for an existing connection or a managed policy.
Test app access

Open a browser and visit an HTTPS page you normally use, then check “Log” in the v2rayNG side menu. Note the time and any errors. Don’t rely only on the latency shown in the server list to determine whether all apps are working.
Save a test baseline

Note whether you’re on Wi-Fi or mobile data, the server name, routing mode, and test results. After changing per-app or battery settings, disconnect and reconnect, then test the same page again.

Battery optimization: check battery and background restrictions separately

If the connection drops when the screen locks, first check whether the app is still running. Doze, app standby, manufacturer background cleanup, and manually force-stopping an app are different mechanisms. Allowing background activity can reduce the chance that the service is restricted, but it can’t guarantee a continuous connection or override a force stop.

Long-press the v2rayNG icon and open “App info” → “App battery usage” or “Battery,” then select “Unrestricted.” If your system also has a battery optimization list, go to “Settings” → “Apps” → “Special app access” → “Battery optimization,” switch to “All apps,” find v2rayNG, and select “Don’t optimize.” Some devices offer only one of these paths; you don’t need to find both sets of switches.

System battery management

App settings: App info → App battery usage
Background policy: Unrestricted or allow background activity
Optimization list: Special app access → Battery optimization → Don’t optimize
Notifications: App info → Notifications → Allow notifications

Reconnect after changing settings, then check that the service stays active before and after locking the screen.

Manufacturer-specific controls

Launch controls: App launch management → Allow background activity
Auto-start: Allow auto-start or linked launch if needed
Data access: Check background data and Data Saver restrictions
Recent apps: If available, lock the app in the recent apps screen

Not all devices have these options, and locking an app in recent apps doesn’t replace battery settings.

If the connection fails only on mobile data, also check “App info” → “Mobile data & Wi-Fi” for background data access, and add the app to the system Data Saver exception list. A battery exemption does not grant network access. A persistent connection uses some battery; unusually high drain may also come from frequent reconnects, other apps transferring data, or an unstable connection. Disabling power saving alone may not fix it.

Test 1: Stay on the same Wi-Fi network, lock the screen for 10 minutes, then unlock it and revisit the same page.
Test 2: Keep the same server, switch to mobile data, and repeat the test to distinguish background restrictions from network issues.
Record the results: Note whether the VPN icon disappeared, whether the app service stopped, and whether new timeout errors appeared in the log. This is a retest procedure, not a guarantee of uptime.

Per-app proxy: choose which apps use the VPN before adjusting routing

Per-app proxy determines which apps fall under VpnService. Routing rules determine whether connections handled by the core use a proxy, connect directly, or use another configured outbound. These are separate settings. Even when a browser uses the VPN, routing rules may send some domains directly.

Open “Per-app proxy” from the side menu and enable it, then select the apps you want. Pay attention to “Bypass mode” or an equivalent switch: when off, selected apps usually use the VPN; when on, selected apps bypass it. Don’t judge by the number of checked apps—read the mode description too. Disconnect and reconnect after saving so the VPN interface is recreated with the updated app list.

Only selected apps use the VPN

Recommended

For your first setup, select just one test browser and leave Bypass mode off. A smaller test scope makes it easier to tell whether an issue comes from app selection, the server, or routing. Apps installed later aren’t automatically added to this selection list.

Best for: A few apps need a proxy, or you’re establishing a troubleshooting baseline.

Selected apps bypass the VPN

Turn on Bypass mode and add apps that explicitly need a direct connection; all other apps use the VPN. Newly installed apps are usually included, so check that the behavior is what you expect after installing an app.

Best for: Most apps should use the VPN, with direct access reserved for a few local services.

Don’t copy someone else’s package name list. System download components, embedded browser pages, and apps with the same name in a work profile may use different processes or identities. If some requests from an app work and others fail, investigate its actual network behavior instead of adding every system app to the list at once.

Connection issues: distinguish background, routing, and DNS problems

Change one setting at a time. If the VPN icon disappears after locking the screen, first check whether the service stopped or another VPN took over. If the icon remains but one app fails, check the per-app list and routing rules. If multiple included apps can’t connect, check the server, DNS, and current network. Use the conditions below to narrow down the cause.

Disconnects soon after the screen locks—should I switch servers?

Keep the same server for now. Check “App info” → “Battery” to see whether background activity is allowed, and check whether another VPN app has started. If the v2rayNG service has stopped, address the background restrictions first. If the service is still running and the log keeps showing timeouts, test the server on another network.

The browser stops using the proxy after I select it. Why?

Open “Per-app proxy” and check Bypass mode. When it’s on, selecting an app usually excludes it rather than routing it through the VPN. After changing the setting, reconnect and fully close and reopen the browser. Then check whether a routing rule sends the test domain directly.

The browser works, but another app can’t connect. Why?

Confirm the failing app is included in the current VPN scope, and check whether it’s in a work profile. If both app inclusion and routing are correct, look for DNS resolution errors or UDP-related issues in the log. A working browser doesn’t prove that every protocol works.

The VPN icon is still there, but every webpage times out. What should I check?

Check the server log first, then go to “Settings” → “Network & internet” → “Private DNS.” If you manually set a provider hostname that can’t be reached, temporarily switch to “Automatic” for comparison. Note the client’s DNS settings too; changing both at once makes it harder to identify the cause.

When sharing diagnostic details, include the error text, time, Android version, and network type. Remove subscription URLs, server credentials, and full share links first. Updating a subscription changes server configuration; it doesn’t replace checks for Android VPN permission, battery settings, or the per-app list.

Verify your setup: reconnect, lock the screen, and switch networks

A single successful connection isn’t enough to verify the setup. Check system routing, background operation, and app scope separately, and make sure each result is repeatable. To compare direct and proxied traffic, you can check a trusted lookup page. However, the same exit address could mean a routing rule sent traffic directly; it doesn’t prove VpnService failed.

Reconnect: Disconnect and reconnect. Confirm you don’t have to resolve a permission issue again and that the selected test app can access the internet.
Check app scope: Test one included app and one bypassed app. Confirm their behavior matches the selected mode and check the system blocking setting.
Check background operation: Repeat the 10-minute screen-lock test described above. Record service and network status instead of checking only whether the notification is visible.
Switch networks: Switch from Wi-Fi to mobile data and try again. Existing long-lived connections may drop; judge success by whether new requests work.
Keep maintenance notes: Record the client version, Android version, and final settings. After a system update, check battery and background data policies again.

Keep these three settings distinct: VpnService controls how traffic enters the VPN, battery settings affect background operation, and the per-app list defines which apps are included. Once the system-level connection is verified, adjust the server, DNS, and routing as needed. This keeps troubleshooting focused and gives you a known-good baseline to restore.