For new v2rayNG users and anyone dealing with disconnects when the screen locks or apps that bypass the proxy. First, distinguish VPN permission, background operation, and traffic scope. Then configure battery settings and per-app rules, and test in the foreground, with the screen locked, and after switching networks to pinpoint the issue.
VPN permission and connecting to a server are separate things
v2rayNG is an Android client that uses the Xray core to handle proxy connections. It creates a virtual network interface through Android’s VpnService and routes app traffic that matches your configuration through its local processing chain. A VPN icon in the status bar only confirms that the interface is up—it doesn’t mean the remote server is reachable or that every app’s traffic uses the proxy.
The first time you start the service, Android displays a VPN connection request. Approve it to let the client create the interface; this permission does not grant access to your texts, contacts, or device management. You still need to verify that your VMess or VLESS settings are correct and that the TLS handshake succeeds. Even if the same subscription works in the desktop v2rayN client, that doesn’t rule out permission or battery restrictions on your phone.
The port above is included to clarify what you’re testing: HTTPS websites usually connect to the destination on port 443, while the proxy server must use the port specified in your subscription. Don’t change every server port to 443 just because a website won’t load. Android work profiles can have their own VPN environment, so check which profile the app you’re testing belongs to.
Start by checking the interface, then check the connection
If the VPN interface isn’t up, troubleshoot permission and service startup first. If it is up but websites won’t load, check the server, DNS, and routing. Don’t treat these as the same problem and keep reinstalling the app.
First connection: permissions, service startup, and conflicts
The steps below use common menu names from Chinese-language Android interfaces. Names and locations may vary across v2rayNG versions and Android manufacturers. If they differ, look for the relevant functions—VPN, notifications, battery, and per-app proxy—instead of following desktop client menu paths.
-
Check the server
Choose an imported configuration on the v2rayNG home screen and check the server address, port, and transport settings. A subscription link serves a different purpose from an individual server configuration; don’t enter the subscription URL in the server address field.
-
Approve the connection
Tap the start button in the lower-right corner of the home screen, then select “OK” in Android’s VPN connection request. If you cancel the request, return to the app and start again. Selecting a server doesn’t mean the service is running.
-
Check for conflicts
Go to Settings → Network & internet → VPN to check the active connection. Firewalls, filtering tools, or other VPN services that use the VPN interface may replace one another. Stop any conflicting service before testing.
-
Allow notifications
Go to Settings → Apps → v2rayNG → Notifications and allow service notifications if needed. On Android 13 and later, notification permission and VPN permission are separate; denying notifications does not deny VPN access.
-
Test access
Keep v2rayNG in the foreground, open a known-accessible HTTPS page, then check Log in the client’s side menu. First look for recurring connection errors before changing background settings.
Disconnects when the screen locks: setting battery exemptions
Check background restrictions first only if the connection works in the foreground but fails when the screen is locked. Android battery optimization, manufacturer-specific background controls, and network changes can all affect long-lived connections. Removing battery restrictions may reduce the chance of the process being limited, but it won’t fix an unreachable server, server-side idle timeouts, or a loss of mobile signal.
- App battery settings: On many Android devices, go to Settings → Apps → v2rayNG → App battery usage and look for Unrestricted or Allow background usage. Some systems put similar options under Battery optimization → All apps.
- Manufacturer startup controls: If your device has an App launch or startup management setting, allow v2rayNG to run in the background. Autostart manages app startup; it doesn’t guarantee that the client will automatically establish a proxy connection.
- Data usage restrictions: In the app info screen, open Mobile data & Wi-Fi or Data usage and check that background data isn’t blocked. If Data Saver is enabled, also check its unrestricted data settings.
- Locking in recent apps: Some manufacturers let you lock an app from the recent apps screen as an extra measure. But this won’t restart the service if the system force-stops the app; you’ll need to open the app and start the service again.
You don’t need to disable every battery-saving feature on your phone. Start by changing only v2rayNG’s app-level settings and compare the results. Keeping the app active in the background uses some battery; consumption also depends on traffic, signal strength, and connection frequency, so no single percentage applies to every phone.
Does swiping v2rayNG away from recent apps disconnect it?
Manufacturers handle clearing recent apps differently. After restarting the service, press Home to return to the home screen without clearing the app. If it stays connected when the screen locks, check the manufacturer’s background cleanup and app-lock settings.
Why does it still disconnect when set to unrestricted?
First check whether the VPN interface is still up when the disconnect happens. If it is and the client is still running, focus on reconnecting after a network change, server reachability, and the logs. Don’t keep adding battery exemptions.
Does a missing notification mean the app was killed?
A notification alone can’t tell you. Check the app’s notification permission and the connection status in Android’s VPN settings, then check the service status in v2rayNG. On Android 13 and later, denying notification permission doesn’t necessarily stop a foreground service.
Will it connect automatically after a reboot?
A battery exemption alone won’t start the connection automatically. After rebooting, check both the client and Android’s VPN status. If you use a client startup option or Android’s always-on VPN feature, verify each one separately.
Per-app proxy: does selecting an app include it or exclude it?
In v2rayNG, go to Settings → Per-app proxy in the side menu and enable the feature, then check Bypass mode. Typically, with bypass mode off, selected apps use the VPN; with bypass mode on, selected apps are excluded. If your version uses different wording, follow the mode description shown in the app.
This setting determines which apps enter the VPN interface; it doesn’t force a particular domain to use the remote proxy. Once traffic enters the interface, Xray routing rules can still send some connections direct or block them. So selecting a browser doesn’t mean every request from it will use the remote server.
Route selected apps through the VPN
RecommendedEnable per-app proxy, turn off bypass mode, and select just one browser for testing. This keeps the traffic scope small, making it easier to separate app selection, server connectivity, and routing issues. It’s the recommended approach for initial troubleshooting.
Best for: first-time setup, using the proxy with a few apps, and establishing a baseline for testing.
Exclude selected apps
Enable per-app proxy and turn on bypass mode, then select the apps to exclude. Other apps will generally enter the VPN and use the route specified by your routing rules. If Android blocks connections outside the VPN, excluded apps may be unable to connect.
Best for: routing most apps through the VPN while letting a few use the local network directly.
Disable per-app filtering
Turn off per-app filtering so the VPN configuration can handle all matching traffic, then use routing rules to split traffic. Broadly routing traffic into the VPN doesn’t mean every destination uses the proxy, and it doesn’t automatically apply to apps in a work profile.
Best for: when you don’t need app-based rules and primarily split traffic using domain and address rules.
After saving the app list, stop and restart the v2rayNG service so the VPN interface is created with the updated list. Close and reopen the target app too, to avoid interference from existing connections or cached data. Recheck newly installed apps against the current mode: in include-only mode, you usually need to add them manually; in bypass mode, they may be included by default.
How to check per-app rules, DNS, and routing
If only one app has a problem, first confirm that it’s included in the VPN, then check routing and DNS. Android Private DNS, an app’s built-in encrypted DNS, and the client’s own DNS settings can all affect how names are resolved. Having a VPN enabled doesn’t guarantee that every DNS query uses a particular server.
| Symptom | Check first | Next step |
|---|---|---|
| Browser works, but a specific app doesn’t | App list, bypass mode, and profile | Confirm the app is included as intended, restart the service and the app, then test again. |
| All apps routed through the VPN fail | Server, network, and core logs | Test with v2rayNG in the foreground. Check for connection timeouts, DNS lookup failures, or TLS errors before changing the app list. |
| Excluded apps lose network access | Android’s block connections outside the VPN setting | Check Android’s VPN settings and confirm that this security setting matches your connectivity needs. |
| Some domains fail while others work | DNS and domain routing rules | Check the logs for the relevant time and verify the DNS results and matching rules one by one. |
To troubleshoot Private DNS, note its current setting under Settings → Network & internet → Private DNS, then briefly switch it to Automatic for comparison. Menu names vary by device. This is only a diagnostic test, not a recommendation to permanently disable encrypted DNS. Restore the setting to suit your network needs, and check the client’s DNS configuration afterward.
Troubleshooting: change one setting at a time
Keep the server and network fixed, and change only which apps enter the VPN. Once that’s correct, adjust DNS or routing separately. Otherwise, even if connectivity returns, you won’t know which change fixed it.
Check background stability with three tests
Use the following steps to retest; these aren’t benchmark results for a particular phone. Keep the server and test page the same, and record the start time, network type, and service status. A single latency reading can’t replace a sustained connection test, and a successful connection doesn’t prove it will work with the screen locked.
- Foreground test — 2 minutes: On Wi-Fi, start v2rayNG and open the test page twice in the selected browser. If it already fails, fix the server or routing rules before testing in the background.
- Screen-locked test — 10 minutes: Return to the home screen and lock your phone without clearing the app from recent apps. After unlocking, check the VPN status before reloading the page. Note whether the service stopped, the first request was slow, or requests kept timing out.
- Retest after switching networks: Switch from Wi-Fi to mobile data and wait for the connection to come up, then open the same page. If it fails only after the switch, first restart the service to test reconnection rather than assuming the battery exemption isn’t working.
A timeout in the logs means an operation timed out; check the destination and timestamp to understand what happened. failed to lookup points to a DNS resolution failure, while connection refused usually means the destination or an intermediary explicitly rejected the connection. A single error line doesn’t prove Android’s background restrictions caused the issue, nor does it identify the server protocol as the cause.
The goal is to confirm three things: connections work in the foreground, the service and access recover after the screen is locked, and the selected apps are routed as expected. If only one check fails, troubleshoot that layer. This makes it easier to keep settings that work than changing core parameters, servers, and battery settings all at once.