This checklist is for Android users whose v2rayNG speed tests time out, connections repeatedly drop, or every node in the same subscription suddenly stops working. The order is fixed: identify the symptom, verify system time and network, refresh the subscription, check transport settings, inspect TLS or REALITY, then rule out DNS and VPN conflicts. Run a real connection test after each step to pinpoint the failing layer faster.
Step 1: Distinguish speed-test timeouts, connection timeouts, and handshake failures
A “timeout” in v2rayNG does not always mean the server is offline. The latency test, real connection test, and core logs after startup cover different stages. A blank latency result may mean the test target is unreachable; stopping immediately after tapping Start usually points to a configuration or handshake error; if the service stays running but websites do not load, continue with routing, DNS, and the device’s VPN environment.
This guide uses the common v2rayNG 1.10.x interface as a reference. Button locations may vary slightly between minor releases, but the troubleshooting process is the same: select one node, run a real connection test, then open “Logs” in the sidebar and review the last 20 to 40 lines. Do not begin by changing UUIDs, ports, and transport settings in bulk, or the original error may be overwritten.
Error: context deadline exceeded
Cause and fix: The connection did not complete within the time limit. Common causes include an unreachable server port, packet loss on mobile networks, or a handshake response that never arrived. Switch between Wi-Fi and mobile data, then verify the address and port.
Error: dial tcp: i/o timeout
Cause and fix: The connection to the target IP and TCP port timed out. If the same node fails on both networks, first check whether the server address changed and whether the port is still open.
Error: failed to find an available destination
Cause and fix: The target domain did not resolve to a usable address, or the DNS response does not work on the current network. Check the node’s domain spelling, change the DNS setting, and restart the connection.
Record these three results first
- The real connection test result for one node, rather than only the latency number in the list.
- The first error in the log when startup fails; repeated errors afterward are usually cascading results.
- Whether the failure affects one node, every node in the same subscription, or every configuration on the device.
If only one node fails while other nodes in the same subscription work, the problem is usually limited to that node’s address, port, or transport settings. If all nodes fail at the same time, check system time, subscription status, the current network, and app permissions before editing nodes one by one.
Step 2: Correct system time, then compare basic network conditions
TLS certificate validation and the REALITY handshake both depend on the device clock. A one-day date error, an incorrect time zone, or a clock that is several minutes slow can make a certificate appear not yet valid or already expired. On Android, enable network-provided automatic time and time zone, then fully stop v2rayNG and restart the core.
Basic network comparison is just as important. Disconnect v2rayNG and confirm that ordinary network access can open familiar websites; then test the same node on both the current Wi-Fi and mobile network. If mobile data works but Wi-Fi times out, check router DNS, guest-network restrictions, and the upstream network. If Wi-Fi works but mobile data fails, the cause may be the current access point, an IPv6 path, or network quality.
-
Correct the time
Open system “Settings” → “System” → “Date & time” and enable “Set time automatically” and “Set time zone automatically.” The “System” entry may have a slightly different name on different Android versions.
-
Stop the connection
Return to v2rayNG, tap the connection button at the bottom to stop the service, then close the app from recent apps. Wait about 5 seconds before opening it again.
-
Test direct access
Keep the proxy off and visit two reliable sites in a browser to confirm that ordinary DNS and basic network access work.
-
Switch networks for comparison
Test the same node on both Wi-Fi and mobile data. Run 3 consecutive tests on each network and record whether the timeout reproduces consistently.
-
Keep the logs
Restart the connection, open “Logs” in the sidebar, and save the earliest error type and timestamp rather than capturing only the last line.
Also temporarily disable the system’s battery-saving restrictions. Open system “Settings” → “Apps” → “v2rayNG” → “Battery” and allow the app to run normally while connected. Some devices restrict background VPN services after the screen locks, causing a connection that works at first to drop after a few dozen seconds. This is different from a server speed-test timeout.
Step 3: Confirm the subscription is valid and refresh local node data
A subscription link only distributes configuration; node availability still depends on the subscription status and server-side settings. An expired subscription, exhausted traffic allowance, or changed group permissions can leave old nodes in the list even though every real connection times out. Seeing a node name does not prove that the local configuration is current.
In v2rayNG, open “Subscription groups” in the sidebar first. Confirm that the subscription URL is complete and its group is enabled, then choose “Update subscription.” Afterward, check whether the node count, names, and ports changed. If the update itself times out, disconnect the proxy and update over the current direct connection. If one node still works, enable updating through the proxy in the subscription settings and try again.
Check these details when refreshing a subscription
- The subscription URL has no spaces, line breaks, or characters truncated by a messaging app.
- After updating, select the new configuration rather than an old node copy with the same name.
- The UUIDs of VMess and VLESS nodes in the subscription remain complete; do not delete characters manually.
- Modern VMess AEAD configurations generally use
alterId 0; do not carry over old parameters from an unknown source. - VLESS encryption is usually
none; transport security is provided by settings such as TLS or REALITY.
If the node count becomes zero after an update, do not repeatedly re-import it. Check whether the subscription response is valid and whether group filters are hiding the nodes. If the update succeeds but all old nodes remain unchanged, delete the subscription group and add it again. Record any custom routing rules first so local changes are not removed accidentally.
Step 4: Check the address, port, and transport parameters one by one
Once system time and the subscription are confirmed, open the node editor and check the connection parameters. The three basics are the server address, port, and user ID. An extra space in a domain, changing 443 to 8443, or a UUID missing one character can all cause failure. A domain should not include the https:// prefix, and a WebSocket path should not be entered in the address field.
Next, check the network type. TCP, WebSocket, and gRPC are not interchangeable; the client must match the server. For WebSocket, verify the path and Host. For gRPC, verify serviceName. VLESS nodes using TCP and REALITY may also require the correct flow. Paths and service names are usually case-sensitive, so /ray and /Ray are different values.
Error: failed to dial WebSocket > bad handshake
Cause and fix: TCP connected, but the WebSocket upgrade handshake was rejected. Check the path, Host, TLS toggle, and port in the node editor, and make sure they match the original subscription values.
Error: connection reset by peer
Cause and fix: The remote endpoint or an intermediate network actively reset the connection. If it happens immediately after the handshake every time, check whether the transport type, server port, and security layer match.
Error: invalid user
Cause and fix: The server rejected the user ID. Update the subscription, verify the UUID, and avoid continuing to use an expired or incompletely copied configuration.
Common transport parameter checklist
- TCP: Verify the port, TLS or REALITY status, and that the VLESS flow matches the configured value.
- WebSocket: Make sure Path starts with the correct slash, Host matches the subscription, and SNI and Host have not been swapped.
- gRPC: Verify the complete service name and that the security-layer toggle matches the server. The port is often, but not always,
443. - VMess: Check the UUID, security settings, and transport type; do not infer parameters from the node name alone.
- VLESS: Check the UUID, flow, transport security, and server name, paying particular attention to the REALITY fields.
After editing, test only the current node; do not immediately run a bulk speed test. Change one field at a time, save, connect for 10 to 15 seconds, and see whether the log advances from a TCP timeout to the TLS or transport handshake stage. A changed error stage confirms that the previous edit took effect; if the error is identical, undo changes that had no clear basis.
Step 5: Check TLS, SNI, and the REALITY fields together
TLS issues often allow the TCP port to connect while the secure handshake still fails. Ordinary TLS nodes need the correct server name, commonly called SNI. SNI is usually the domain covered by the certificate and may not exactly match the node’s connection address. If the subscription supplies this field, keep it unchanged; do not replace it with an IP address.
When certificate validation fails, first address system time, the domain, and the configuration source. Do not treat “allow insecure connections” as a permanent fix. Disabling verification only hides domain or certificate errors and cannot solve mismatched ports, paths, or REALITY parameters.
Error: x509: certificate has expired or is not yet valid
Cause and fix: The device clock is incorrect, or the server certificate is genuinely outside its validity period. Enable automatic time first. If the error remains with an accurate clock, update the node configuration or wait for the server operator to resolve it.
Error: x509: certificate is valid for another name
Cause and fix: SNI does not match the domain covered by the certificate. Restore the server name supplied by the subscription and make sure the node address was not copied directly into SNI.
Error: REALITY: processed invalid connection
Cause and fix: The REALITY handshake fields do not match. Recheck the public key, short ID, serverName, fingerprint, and flow. Updating the subscription is the recommended way to restore the complete parameter set.
Key REALITY checks
- The protocol is VLESS, and the network type matches the configuration instructions.
- The public key is complete, with no leading or trailing spaces or line breaks from copying.
- The short ID is the value supplied by the subscription; do not add zeros or remove characters arbitrarily.
- serverName matches the configuration, and common fingerprint values such as
chromeare entered exactly as specified. - When using Vision, flow usually needs to be set to
xtls-rprx-vision; follow the node configuration.
If ordinary TLS nodes work but every REALITY node in the same subscription fails, the likely causes are REALITY fields, core compatibility, or subscription data. First confirm that v2rayNG is using the Xray core, then obtain the currently maintained version from the package page and re-import the subscription for another test.
Step 6: Rule out DNS, routing rules, and local VPN conflicts
If the first five steps are normal but websites still do not open after connection, check whether requests pass successfully through DNS, route matching, and proxy outbound. Domain-based nodes depend on DNS resolution; custom routes may send test domains to direct access or block them incorrectly; another VPN service running on the device may prevent v2rayNG from creating its VPN interface or replace the connection immediately after startup.
Restore a simple environment first: stop other VPN services, disable automatic network switching, and temporarily turn off custom routing rules, leaving only one node with confirmed parameters. In v2rayNG “Settings,” record the current DNS options, switch to the default configuration, then stop and restart the connection. If it works with the defaults, add routing rules and DNS settings back one at a time.
The node says it is connected, but why do no websites open?
Open the logs first and confirm that the client is not reconnecting continuously, then disable custom routing and restore the default DNS. If the local SOCKS listener is enabled, make sure another app is not using its port. A common port is 10808; use the actual value shown in Settings.
It connects by IP address but times out with a domain name. What should I do?
This usually points to DNS resolution. Disconnect, refresh the network, restore v2rayNG’s default DNS, and test the node domain again. Do not permanently replace the domain with its resolved IP, because TLS SNI and certificate validation may still depend on the original domain.
It times out on Wi-Fi but connects normally over mobile data. What should I do?
Restart the router, disable guest-network restrictions, and check whether the router is using an unusual DNS server. Reconnect the device to Wi-Fi and run 3 consecutive tests to confirm whether the problem is limited to that network.
The connection drops automatically after the screen has been locked for a few dozen seconds. What should I do?
Open system “Settings” → “Apps” → “v2rayNG” → “Battery,” disable strict background restrictions, and allow the VPN service to keep running. Lock the screen for 2 minutes, then test connection stability again.
Every subscription node times out, and manual nodes fail too. What should I do?
Check device time, the current network, and VPN conflicts first. Restart the device, launch only v2rayNG, and test one node with clearly defined parameters. If it still fails, keep the first error from the log and continue from there.
Final retest order
- Keep automatic time and automatic time zone enabled.
- Stop other VPN services and keep only v2rayNG running.
- Update the subscription once and select one new node.
- Restore the default DNS and routing settings.
- Run a real connection test before starting the VPN service.
- Open one domain-based site and one commonly used app, then observe them for 2 minutes.
After retesting in this order, if only one node still times out, the problem is almost certainly limited to that node or the server. If every node in one subscription fails while other subscriptions work, address the subscription status or the group configuration. If every configuration fails on the current device and changing networks makes no difference, check the app version, system VPN permission, and the core startup error in the logs.
Effective troubleshooting is not about trying more random combinations; each test should verify one variable. Check time, network, subscription, transport, security layer, DNS, and the local environment in sequence. This shows exactly where the connection stops and prevents a simple port change from being mistaken for a client failure.