Use this guide when v2rayNG on Android times out while testing a node, fails to connect, or starts but cannot load websites. First distinguish subscription retrieval failures from server handshake failures and traffic that never reaches the proxy. Then work through these seven checks in order. Change one setting at a time, and keep the logs and a way to restore your original configuration.
Check 1: Make sure the subscription updated
A subscription URL is how you retrieve node configurations; it is not the node server itself. If an update times out, that only means the configuration could not be retrieved this time—it does not prove every node in the list is down. Likewise, a successful subscription update does not mean every server in it is reachable.
In v2rayNG, open “Subscription group settings” from the side menu and make sure the URL is saved under the correct group. Return to the main screen and select “Update subscription” from the menu. Button labels may vary slightly by version. Distinguish a regular update from one labeled “via proxy,” and note which method failed.
- Check the subscription source: Verify the complete URL provided by your service, watching for spaces or line breaks added during copying and checking whether the subscription token has been reset.
- Check your account: Make sure the subscription has not expired, your data allowance is not used up, and the provider has not changed its access details. A response from the update endpoint does not mean your account still has available service.
- Choose an update method: If no node is currently usable, first try updating without a proxy. If you have a working node but cannot reach the subscription endpoint directly, try updating through the proxy.
- Keep your current configuration: Do not clear all nodes just to retry. After updating, check whether the groups and node details changed. If needed, retrieve the subscription again from its source.
Check 2: Verify your device’s date and time
A significantly incorrect device clock can interfere with VMess authentication and cause TLS certificates to appear not yet valid or expired. VLESS does not use the same time-based authentication mechanism as VMess, but TLS connections still depend on accurate time checks. Do not skip this step just because the node uses VLESS.
- On Android, go to “Settings” → “System” → “Date & time” and turn on automatic time and time zone. Some devices put these options under “Additional settings.”
- If your device cannot sync its clock, restore regular network access first, then try again. Changing the time zone alone may not correct the device’s actual clock.
- After correcting the time, stop and restart the v2rayNG connection, then test the same node without changing any other settings.
If the logs show a certificate date error, check the date, year, and device clock first, then ask your provider to verify the server certificate. Do not treat “Allow insecure connections” as a general fix: it weakens certificate validation and cannot fix routing problems or an unreachable server port.
Check 3: Verify the protocol and transport settings
Open the target node’s edit screen and compare each field with the original settings from your provider. A node name is just a label: calling it “TLS” or naming a region does not prove the configuration is correct. If possible, re-import the full configuration from a trusted source before checking fields you have edited manually.
| Setting | Fields that must match | Common mistakes |
|---|---|---|
| Server endpoint | Address and port | Using a website address as the node address or missing a non-standard port |
| VMess | User ID, encryption settings, and transport | Copying a user ID from another node or choosing the wrong transport |
| VLESS | User ID, encryption field, and flow | Not setting the encryption field to none as required, or adding a flow value without instructions |
| TLS | serverName, certificate validation, and any required ALPN settings | Changing the server address to an IP and incorrectly clearing serverName |
| REALITY | serverName, public key, shortId, and the fingerprint required by the server | Using the public key as the user ID, omitting shortId, or mixing in settings from another node |
| WebSocket | Path, Host, and whether TLS is enabled | Changing the path’s capitalization or confusing Host with the server address |
For VLESS, encryption is usually none. This does not mean the outer connection is unencrypted: TLS or REALITY can provide secure transport. Set flow only as specified by the server. Do not apply the same settings to every node just because a particular combination is said to be faster.
Check 4: Can your current network reach the server?
Stop v2rayNG first and make sure you can browse the web over a regular connection. Public Wi-Fi may require you to sign in, while mobile data can be affected by an unpaid balance, data limits, or a weak signal. Switching nodes is unlikely to tell you anything useful until the underlying connection works.
Next, test the same node over Wi-Fi and mobile data without changing its settings. Switching networks can reveal differences in outbound restrictions, IP address families, or DNS, but one success or failure alone cannot identify the cause. Use the logs to narrow it down.
These port numbers help distinguish types of traffic; they are not instructions to change every node to port 443. A node must use the port its server actually listens on. Being able to open a regular website over 443 does not prove that a node port on another address is reachable. Likewise, a failed ICMP test does not prove that a TCP proxy service is unavailable.
Bottom line: Compare networks using the same node
If the same node fails on only one type of network, note the network and destination address shown in the logs, then ask your provider to check whether the endpoint is reachable. Do not change the protocol, port, and DNS at the same time or you will lose a useful point of comparison.
Check 5: Is the VPN actually handling your traffic?
When v2rayNG shows that it is running, its local service has started; this does not mean the remote server has passed every connection check. Android VPN permissions, another VPN app, per-app proxy settings, or background restrictions can all separate “the client is running” from “the browser is using the proxy.”
- Check VPN permission: Accept Android’s VPN connection request on first launch, then confirm in Android’s VPN settings that v2rayNG is the active connection.
- Check for conflicts: Temporarily stop other apps using Android’s VPN interface, including filtering tools that work as local VPNs. Standard apps generally cannot use the same VPN interface at the same time for one user.
- Check per-app proxy settings: Open the per-app proxy options under v2rayNG “Settings” and make sure your test browser is not excluded. You can temporarily disable per-app filtering while testing.
- Check background restrictions: If the connection drops only when the screen is off, check v2rayNG’s battery and background activity permissions in Android’s app settings. If it times out immediately in the foreground, investigate the server connection first rather than changing power-saving settings alone.
After changing VPN or per-app settings, stop and restart the connection. Then use the same browser to visit the same destination. If only the icon changes and no new request appears in the logs, check which traffic is being captured before deciding that the node is down.
Check 6: Is routing sending requests the wrong way?
If some websites load while others keep failing, check the routing rules instead of relying only on the node’s latency. Rules can send certain domains directly, through the proxy, or block them. A “bypass” setting may also mean the request never goes through the selected node.
- In v2rayNG “Settings,” open “Routing settings” or the equivalent routing mode screen. Note the current mode, custom rules, and relevant domain matching conditions.
- Run a brief comparison to test whether routing is the cause: temporarily choose a routing mode that sends the test destination through the proxy, visit the same destination, then restore your original setting. Global proxy mode does not necessarily override per-app exclusions.
- If you have edited custom rules, check whether the destination domain matches a direct or block rule earlier in the list. Rule order matters: an earlier match may prevent later rules from being applied.
- If only one app fails, check its own proxy settings, the per-app inclusion list, and whether it connects differently from your browser.
Why does the latency test show a value if websites still won’t load?
First, identify which test you ran. A TCP probe only reports whether a port can be reached; a real connection test also depends on its test destination. Visit the target website in your browser and check the matching request in the logs. A latency value alone does not confirm that browsing works.
If global routing works, should I leave it on?
Restore your original mode first, then check which rule sends the domain direct or blocks it. Global routing is useful for a brief comparison; choose a long-term setting based on the traffic you actually want to proxy.
The browser works, but another app keeps loading. What should I do?
First, make sure the app is included in the per-app proxy settings, then force-stop and reopen it. If it still fails, check the protocol and destination address in the logs to distinguish an app issue from a proxy connection problem.
Check 7: What do DNS and the logs reveal?
DNS involves at least two separate things: the node server’s domain and the domain of the website you are visiting. If the first cannot resolve, the client cannot reach the node. If the second fails to resolve or is routed incorrectly, the proxy may start while a particular website remains unavailable. Enabling remote DNS does not necessarily fix resolution of the node’s own domain.
In v2rayNG “Settings,” check the DNS options, including local DNS, remote DNS, and whether each is enabled. Save the current values before testing changes. Android’s “Private DNS” under “Settings” → “Network & internet” is a separate setting; you can temporarily switch from a custom provider to automatic mode, test, then restore it. Menu names vary by device manufacturer.
Error: i/o timeout
What it means: A read or write operation exceeded its timeout. This can happen during a DNS query, connection, or later data transfer, so the message alone does not pinpoint the problem.
What to do: Check the surrounding log entries to see whether the timeout involved a DNS server, the node address, or the destination website. Then compare using another network instead of changing every DNS setting at once.
Error: connection refused
What it means: The connection was explicitly rejected. Common causes include a port with no service listening, a stopped service, or a network device actively refusing the connection.
What to do: Check whether the rejected address is the remote node or a local listening address. For a remote endpoint, verify the port in your subscription and contact your provider. For a local address, check that the service is running.
Error: x509: certificate has expired or is not yet valid
What it means: The certificate’s validity period does not match the device’s current time. The device clock may be wrong, or the server certificate may have expired.
What to do: Turn on automatic time synchronization and retry. If the error persists while the clock is correct, report the certificate issue to your provider; do not bypass it by disabling certificate validation.
Open “Logs” from the side menu and note the exact time of a failed attempt. Restart the connection, make one request to the destination, then review the nearby log entries. Error messages can contain several layers of prefixes; a top-level “connection failed” usually describes the result, while an inner DNS, handshake, or port error is more useful for finding the cause.
- Record how to reproduce the issue: Note your Android version, the version shown under v2rayNG “About,” the network type, and whether the failure happened while updating the subscription or opening a website.
- Record comparison results: Note whether the same node works on another network and whether another known-good node works on the same network. Do not substitute batch speed-test results for an actual connection test.
- Share redacted logs: Keep the original error text and timestamps, but hide subscription tokens, user IDs, private addresses, and other credentials. Share node endpoint details only through a trusted support channel.
Bottom line: Restore your settings and test again
Once you have identified the cause, restore any temporary changes to routing, Private DNS, and per-app settings, keeping only fixes that proved effective. Restart the connection and test the original destination again to make sure the fix does not depend on a temporary option you forgot to restore.