A node timeout means one step did not finish in time; it does not prove the server is offline. This guide is for v2rayN and v2rayNG users seeing timed-out latency tests, failed connections, or websites that will not load. Work through the checks in order: confirm the scope, sync your clock and update the subscription, read the logs, verify transport and TLS, then check the server. Change one thing at a time and keep notes you can share with the maintainer.
1. First, Is the Node Timing Out—or Is the App Bypassing the Proxy?
Pinpoint where the failure occurs before changing settings. A latency test in the node list, the core connecting to a server, and a browser loading a site are three different operations. An unreachable test endpoint can make a working node appear to time out. Conversely, a successful TCP connection does not guarantee that authentication, the TLS handshake, and proxy forwarding are all working.
| Observed symptom | Check first | What you cannot conclude yet |
|---|---|---|
| Only the latency test times out; websites load | The test URL, test method, and route to that URL | This alone does not mean the node is down |
| All nodes fail at the same time | Local network, system clock, and whether the core started | It does not necessarily mean every server failed at once |
| Only one node fails | That node's settings, remote port, and account status | One failed attempt does not prove the node is permanently unavailable |
| Browser works, but terminal does not | Terminal proxy environment variables or explicit proxy settings | This is usually not caused by a node timeout |
Set up a minimal, reproducible test to eliminate unrelated variables. Run only one client, select one node and a test URL you know is reachable, and note the time. Do not change routing, DNS, TUN, and transport settings all at once. v2rayNG uses Android's VPN service to route traffic, so make sure its connection switch is on and no other VPN service is occupying the connection.
2. Check Your Device Clock, Then Update the Subscription
Make sure the system clock is correct before investigating authentication or certificate errors. VMess authentication depends on time, so a significantly inaccurate clock can cause connection failures. TLS certificate validity checks also rely on the local clock. Do not apply VMess's time-based authentication explanation directly to VLESS, but keep the clock accurate when using TLS. Changing only the displayed time zone will not fix an incorrect system clock.
-
Sync your system clock
On Windows, open Settings → Time & language → Date & time, turn on Set time automatically, then select Sync now. On Android, search Settings for Date & time and enable automatic time. Menu locations vary by device.
-
Update the current subscription
In v2rayN, open the Subscription group menu and select Update current subscription. You can try Update current subscription (without proxy) first. In v2rayNG, open the top-right menu on the main screen and select Update current group subscription. Menu wording may vary by version; check the update result rather than just noting that you tapped the button.
-
Select the node again
After updating, select the target node again and start the connection. Check whether its server address or port changed. A successful subscription update does not mean the node can connect: the subscription endpoint and node server may use entirely different addresses and network routes.
-
Record one failed attempt
Note the current time, make one request, then check the logs immediately. Keep the entries around that attempt; a batch of latency tests can flood the logs and obscure the actual connection issue.
3. Check the Core Logs for the First Useful Error
Read the logs from local startup errors through remote connection errors; do not search only for the final timeout. In v2rayN, start with the log or information area at the bottom of the main window. For more detail, open Settings → Parameter settings and look for the log level options. In v2rayNG, open Log from the top-right menu on the main screen. Menu locations and log level names vary by version, so note both the client version and the core version shown in the logs.
Temporarily increase the log level, restart the connection, and reproduce the issue once. Debug logs may include visited domains and server addresses, so restore your usual log level when finished. These are common error snippets; different cores may add connection IDs, destination addresses, or more context.
Error: address already in use
Cause: The local listen address or port is already in use, so the core may not have started at all.
Fix: Close duplicate client instances and identify the process using the port. If you change the local port, update the proxy port configured in your app too.
Error: no such host
Cause: A domain could not be resolved. It might be the node's domain or the destination you are trying to reach.
Fix: Identify the domain in the error and check its spelling and the DNS route in use. If the node's domain cannot be resolved, fix DNS resolution before troubleshooting the connection itself.
Error: i/o timeout
Cause: A connection or read/write operation timed out. This message alone cannot tell you whether the cause is packet loss, remote filtering, or no response during the handshake.
Fix: Use the destination address and surrounding handshake entries to identify the stage that failed. Then test the remote port, transport settings, and server status separately.
Error: x509: certificate has expired or is not yet valid
Cause: Your device clock is wrong, or the remote certificate is genuinely outside its validity period.
Fix: Sync your device clock first. If the error persists with the clock correct, ask the maintainer to check the certificate validity period and the certificate actually loaded by the reverse proxy.
Bottom line: Fix local startup errors before checking the remote server
If the logs show a listening port conflict and no record that the core started successfully, resolve the conflict first. Changing the server address, TLS settings, or subscription parameters repeatedly will not fix a local bind failure.
4. Test the Local Listener and Remote Port Separately
Keep the local proxy port and server port separate. An app connects to the local proxy first; the core then connects to the remote server. The numbers below illustrate these two connections and are not universal defaults. For v2rayN in particular, check the current settings for HTTP, SOCKS, or mixed listening modes.
On Windows, use this interactive PowerShell command to test the remote TCP port. Enter the server address and remote port shown in the node editor—not the subscription URL or local proxy port. A true TcpTestSucceeded value means only that the TCP connection succeeded; it does not confirm proxy protocol authentication. This test also cannot fully diagnose transports that use UDP.
$nodeHost = Read-Host "Enter the node server hostname or IP"
$nodePort = [int](Read-Host "Enter the remote node port")
Test-NetConnection -ComputerName $nodeHost -Port $nodePortTo check whether a terminal is actually using the local SOCKS proxy, first confirm it is listening on 127.0.0.1:10808, then run the command below. Enter a test URL when prompted. socks5h sends the destination hostname to the proxy for resolution, so this does not directly test local DNS. The 15-second limit is for this test only; it is not a performance benchmark for the node.
$testUrl = Read-Host "Enter the full HTTPS URL to test"
curl.exe --proxy socks5h://127.0.0.1:10808 --connect-timeout 15 --max-time 30 -I $testUrl- Connection to the local port is refused: Check that the core is running and that the SOCKS port matches the command.
- Remote TCP succeeds, but the proxy request fails: Check authentication, TLS, transport, and outbound routing. A successful port test is not the end of the investigation.
- The same node works on another network: Compare DNS, IPv4/IPv6 connectivity, and outbound network restrictions. Do not reinstall the client right away.
5. Check Transport, TLS, and REALITY Settings One by One
Check the full set of parameters, not just the server address and UUID. A subscription typically includes protocol, transport, and security settings. After manual edits or a migration between cores, one incompatible field can cause a handshake failure. v2rayNG uses the Xray core, while v2flyNG uses the v2fly core; do not assume they support exactly the same protocol extensions and configuration fields.
| Setting group | What to check | Common point of confusion |
|---|---|---|
| Protocol and authentication | VMess or VLESS, UUID, and settings supported by the server | Changing only the protocol name does not make the other fields compatible |
| WebSocket | Transport type, path, Host, and reverse proxy routing target | Paths are case-sensitive and include slashes; Host is not the server address |
| gRPC | serviceName, TLS, and HTTP/2 support in the reverse proxy | serviceName is not the WebSocket path field |
| TLS | serverName/SNI, certificate hostname, validity period, and ALPN requirements | When connecting to an IP address, the certificate name must still match the expected hostname |
| REALITY and Vision | Server-provided public key, shortId, serverName, fingerprint, and flow | For Vision, set flow as required by the server; do not guess |
After making changes, reload the configuration and confirm the logs are for a new connection. In v2rayN, stop and restart the current service; in v2rayNG, turn the connection switch off and back on. If refreshing the subscription overwrites manual changes, keep a record and ask the provider to fix the subscription rather than repeating the same edits after every update.
6. Check Server Status and the Network Route
Server-side evidence is easier to interpret after you have checked local startup, subscription settings, and handshake requirements. If you do not administer the server, send the provider the time of the issue, node identifier, network type, and redacted logs. Ask whether the listener, account validity period, or entry point changed. Do not post screenshots that reveal your full subscription URL.
- Check listeners: Administrators can use
ss -lntpto inspect TCP listeners andss -lnupto inspect UDP listeners. Confirm the process, bind address, and configured port match. - Check firewall rules: Cloud security groups and the system firewall are separate layers. Allow only the ports and transport types you need; do not leave the entire firewall disabled as a long-term fix.
- Check the reverse proxy: If a reverse proxy accepts incoming connections, verify the upstream address, path, and service name. Match the timestamps in the access and core logs.
- Check IPv4 and IPv6: If the domain has A and AAAA records, test whether both IPv4 and IPv6 are reachable. If one address family fails, fix the corresponding entry point or DNS record first.
- Check resources and policies: Make sure the process is not repeatedly exiting and that disk space and memory are available. Check account traffic limits, expiration, and server-side connection limits.
Bottom line: Narrow it down with a network comparison
If the same configuration fails on home Wi-Fi but works on a mobile network, compare the network routes first. If other nodes work on the same network but one target node does not, check that node's entry point. These comparisons are more useful than repeatedly reinstalling the client.
7. Still Timing Out? Gather the Missing Details
The latency test always times out, but websites load. Should I switch nodes?
Not yet. Check the test URL and method, then try visiting the same URL normally. The test target may be routed separately, reject requests, or be temporarily unreachable, so test results may not reflect everyday browsing.
v2rayNG says connected. Why won't anything load?
Connected usually means the local VPN service has started; it does not mean every remote request succeeds. Open Log from the top-right menu, make one request, and check for remote dial or handshake errors. Also check whether per-app proxy settings exclude the app you are testing.
My computer works, but the same node times out on my phone. Which settings should I compare?
First confirm both devices use the same up-to-date subscription and network. Then compare transport type, SNI, path or serviceName, REALITY settings, and flow. Note the core version on each device. Do not copy the entire desktop configuration, since local inbound settings and system-level traffic routing differ.
Will increasing the timeout fix it?
It can help distinguish a slow response from a persistent failure, but it will not fix a wrong port, failed authentication, or certificate issue. Keep the original setting and reproduce the problem with a fixed test limit. If the logs keep showing a handshake error, fix the relevant settings instead of extending the wait indefinitely.
The most useful information to include when asking for help is a reproducible sequence of steps. Provide the client and core versions, time and time zone, Wi-Fi or mobile network, whether all nodes or just one fail, remote port test results, and the logs around a single failed attempt. Redact UUIDs, subscription tokens, and other credentials before sharing. If you need to provide the server address, send it through a trusted private channel.