This checklist is useful when v2rayN, v2rayNG, or v2flyNG has imported the nodes, but latency tests time out, websites fail to load after startup, or connection errors keep appearing in the logs. Check the local network first, then verify the clock, subscription, protocol settings, and server status. Retest after each layer to pinpoint the failure faster.
First: Check the local network and proxy entry point
A “node timeout” only means that the client did not receive the expected response within the allowed time; it does not prove that the node is offline. A request travels from the browser through the system proxy, local listening port, V2Ray or Xray core, DNS, router, and current network before reaching the remote server. A failure at any point can appear as a timeout in the client.
First, exit the client completely, then use a browser to open two websites that normally work without a proxy. If ordinary websites also fail, restore the local network first—for example, reconnect the router, switch to another working network, or check whether a public network requires a login. Repeatedly refreshing the subscription will not help because the subscription request also depends on a working network.
Once the basic network works, start the client, but do not rely only on the tray icon. In v2rayN 7.x, check the bottom of the main window or the log area to confirm that the core has started, and verify the selected server. Common local listening ports are SOCKS 10808 and HTTP 10809, but versions and personal configurations differ; use the ports shown under “Settings” → “Parameter settings”. If another program occupies a port, the core may fail to start while the system proxy still points to the old port.
Close old processes
After exiting v2rayN, open the task manager and confirm that the earlier V2Ray or Xray core process has ended. Then restart the client to prevent the old process from continuing to occupy the local port.
Verify the listening ports
Go to “Settings” → “Parameter settings” and note the local SOCKS, HTTP, or mixed-proxy port. Then check that the port entered in your browser or other apps matches the client’s port.
Reset the system proxy
First choose the option to clear the system proxy, then enable it again. This can fix an old address or port left behind after the client exited unexpectedly.
Switch local networks
When possible, test the same node on another network. If the original network times out three times in a row while another network connects within 1 to 3 seconds, the problem is more likely to be with the original network or router.
Second: Correct the system clock and time zone
VMess authentication depends on time, so a large clock offset can cause authentication to fail outright. TLS-based VMess, VLESS, and other configurations also check certificate validity periods. An incorrect date, time zone, or automatic time sync can prevent node connections and cause certificate time errors on subscription pages.
Even a one-minute difference is worth fixing. Set the device to obtain the time and time zone automatically instead of changing only the displayed hour by hand. After a time-zone change, long sleep, faulty motherboard clock, or blocked time synchronization by the router, the displayed time may not match actual standard time.
Windows
Open “Settings” → “Time & language” → “Date & time”, enable automatic time and automatic time-zone settings, then click “Sync now”. Exit and restart v2rayN afterward.
macOS
Open “System Settings” → “General” → “Date & Time”, enable automatic date and time, and confirm that the current time zone matches your location.
Android
Open the date and time options in system “Settings”, enable automatic time and time-zone settings, then stop and relaunch v2rayNG or v2flyNG completely.
After correcting the clock, restart the client core instead of running another latency test only. Failed connections, DNS cache entries, and old sessions may still remain in the process. If every node failed before the clock was corrected and several nodes in different regions recover afterward, the device time is usually the root cause rather than a single subscription server.
Error: x509: certificate has expired or is not yet valid
Cause and fix: The TLS certificate may genuinely be expired, or the device date may be wrong. Sync the system time and time zone first. If only one node still reports the error, ask the server operator to check the certificate.
Error: invalid user
Cause and fix: The server rejected the authentication details. For VMess, correct the system clock first, then verify the UUID, alterId, and subscription contents are complete. Avoid changing several parameters at once and losing the diagnostic trail.
Conclusion: If every node fails, check shared device conditions first
When multiple independent nodes on the same device all time out at the same time, check the network, system clock, local ports, and core status first. A simultaneous failure of one remote server cannot explain such a consistent pattern.
Third: Confirm that the subscription is valid and really updated
Being able to add a subscription URL to the client does not mean its nodes will remain valid. The subscription may have expired, its traffic quota may be exhausted, access credentials may have changed, or new nodes may have been generated while the client is still using a cached list. Updating the subscription and testing a node are separate actions: the first retrieves configuration, while the second attempts to connect to a server in that configuration.
In v2rayN, select the relevant group under “Subscription groups”, then choose “Update all subscriptions”. If the current proxy is unavailable, try updating “without proxy” first so the client does not use a dead node to request new subscription data. Afterward, check whether the node count, server addresses, and update time changed; do not stop at the words “Update complete”.
Confirm that the subscription is accessible
With the basic network working, update the subscription again and note whether the client reports success, an HTTP error, a parsing failure, or a connection timeout. Each result points to a different next step.
Review the group contents
Confirm that you updated the subscription group currently in use. When multiple groups exist, old nodes may remain in the list, and similar names make it easy to select the wrong one.
Select a node again
After updating, choose a server from the new list and explicitly set it as the active server. Updating the list does not guarantee that the active item has switched to the new configuration.
Test three nodes
Choose three nodes with different addresses or regions and test each one twice. If only one fails, it is usually a single-node issue. If all three time out at around the same time, continue checking the parameters or server status.
Error: unexpected EOF
Cause and fix: The subscription response or remote connection closed before completion. Fetch the subscription again first. If the update succeeds but the error returns during connection, check the transport parameters and server status.
Error: failed to parse config
Cause and fix: The imported content does not match the configuration format expected by the client or core. Delete the abnormal copy just imported, update the subscription again, and make sure a webpage URL, explanatory text, or truncated content was not imported as a node configuration.
Error: failed to find an available destination
Cause and fix: The outbound target could not establish a usable connection. Common clues include failure to resolve the server domain or no usable outbound route. Check the node address, DNS settings, and active outbound, then restart the core.
Fourth: Check protocol, transport, and TLS parameters one by one
A reachable node address and port do not prove that the protocol parameters are correct. VMess and VLESS use different identity fields, and TCP, WebSocket, and gRPC transports are not interchangeable. A mismatch in the UUID, port, transport type, path, service name, TLS switch, or server name can cause a timeout, immediate disconnect, or handshake failure.
Do not change every port to 443 based on experience, and do not fill in a random path just because you see WebSocket. Port 443 is often used for TLS, but a server can listen on another port. WebSocket Host and Path, as well as gRPC serviceName, must match the server configuration. Keep subscription-imported settings unchanged unless you have confirmed parameters to correct.
| Check | VMess | VLESS | Common symptoms |
|---|---|---|---|
| User identity | UUID; alterId is usually 0 in modern configurations | UUID; some configurations also include flow | Authentication failure or immediate disconnect after connecting |
| Transport | Must match the configured TCP, WebSocket, or other transport | Must match the configured TCP, WebSocket, gRPC, or other transport | Handshake timeout or unexpected EOF |
| TLS parameters | Verify the TLS switch and server name | Verify TLS, the server name, and the security parameters supplied by the subscription | TLS handshake timeout or certificate name mismatch |
| Additional fields | WebSocket usually requires checking Host and Path | gRPC usually requires checking serviceName | Server rejection or prolonged waiting |
Also confirm that the core used by the client can handle the configuration. In v2rayN, view or change the core under “Settings” → “Parameter settings” → “Core type”; menu labels may vary slightly by version. Configurations that use VLESS-specific capabilities generally require a compatible Xray core. On Android, v2rayNG uses the Xray core and v2flyNG uses the v2fly core; do not assume that both support exactly the same configuration fields.
If the configuration came from a subscription, the safest comparison method is to keep the original node and duplicate it for one-field-at-a-time changes. Restart the core after each change. For example, check the port first, then the transport type, followed by TLS and the server name. Changing the UUID, path, port, and TLS simultaneously may restore the connection, but it will not reveal the actual cause.
Error: TLS handshake timeout
Cause and fix: The TCP connection may be established, but the TLS handshake did not finish in time. Check the server name, TLS switch, port, and system clock, then try another network to rule out path interference.
Error: dial tcp: i/o timeout
Cause and fix: The client did not receive a timely response while establishing the TCP connection. Check the server address, port, local network, and firewall. If only this address fails, determine whether the remote port has stopped listening.
Error: connection refused
Cause and fix: The target host explicitly refused the connection. Usually the address is reachable but no service is listening on that port, or an entry rule actively rejected it. Verify the port, then ask the service operator to confirm its listening status.
Conclusion: Treat timeouts and refused connections differently
i/o timeout usually means the request did not receive a timely response, while connection refused means the target explicitly rejected it. For the former, check the network path and address first; for the latter, verify the port and server listener.
Fifth: Use cross-testing to determine server status
After the first four layers are complete, if the basic network works, the clock is accurate, the subscription was just updated, and the parameters match, determine whether the remote server is under maintenance, its port has stopped listening, or the route is unreachable only from one network. Do not keep changing random client settings; create comparable test results instead.
The most useful comparisons cover three dimensions: change the node on the same device, change the network for the same node, and use the same subscription on another device. Change only one condition at a time. For example, if node A on one Windows device times out for more than 10 seconds three times in a row while nodes B and C in the same group open webpages within 2 seconds, the evidence points to node A. If A, B, and C all fail on the current network but recover on another, the original network path is more likely at fault.
- Only one node fails: Record the time, server address, and error type from the logs. Wait for the server to recover or use another node from the same subscription.
- Nodes in one region fail together: The regional entry point or route may be having problems. Test different addresses first instead of repeatedly reinstalling the client.
- All nodes fail on only one network: Check the router, DNS, network access restrictions, and firewall policy, then retest on another network.
- All devices fail with the same subscription: Confirm the subscription validity period, traffic status, and service notices instead of continuing to change local ports on every device.
- Only one device fails: Return to the local listener, system proxy, clock, and core configuration, focusing on differences from a working device.
When reviewing logs, focus on the first failure rather than the repeated cascade of errors that follows. v2rayN runtime information usually records the target address, connection stage, and core response; v2rayNG and v2flyNG also show recent connection results in their log areas. Clear the log or note its current position before making a new request to reduce interference from old entries.
Error: context deadline exceeded
Cause and fix: An operation exceeded the waiting period set by the core or client. This line alone cannot identify the root cause. Look earlier in the same request for DNS, TCP, or TLS errors, then troubleshoot the corresponding stage.
Error: context canceled
Cause and fix: An upper layer canceled the connection task. This commonly happens when switching nodes, restarting the core, or cleaning up after an earlier connection failure. If it follows a more specific error, treat the earlier error as the main clue.
Error: network is unreachable
Cause and fix: The system currently has no usable route to the target network. Check whether the device is online, whether the router works, and whether the network interface changed. Also make sure leftover proxy or virtual-network settings are not affecting routing.
The full process is: prove that the device can access the network, make the system clock reliable, confirm that the subscription really updated, verify the node’s protocol parameters, and only then use comparisons across nodes, networks, and devices to assess the server. This avoids rebuilding a subscription during a local network failure and repeatedly changing correct client settings during remote maintenance.