This guide is for users whose v2rayN or v2rayNG nodes time out, whose browsers stop loading pages after the proxy is enabled, or whose latency tests all fail. The checks help distinguish local network problems, clock drift, expired subscription parameters, mismatched transport settings, unreachable node ports, and server-side failures—so you can decide whether to adjust settings, update the subscription, or switch nodes.
Start with a fixed troubleshooting order
When a connection fails, changing several settings at once creates the most confusion. For example, you might change DNS, re-import the subscription, and modify the transport protocol simultaneously. Even if the connection returns, you will not know the real cause. A more reliable approach is to change one variable at a time and retest the same node after each change.
The complete connection path is more than just “client to node.” An application request first enters the local proxy port. V2Ray or the Xray core then reads routing rules, resolves the server domain, connects to the remote port, and completes the protocol and transport-layer handshake. A failure at any stage may appear only as a timeout in the interface.
Start checking at the end closest to the device. Confirm that ordinary internet access works, then check the clock and local proxy port. Next verify the node parameters, and only then assess the server. This order prevents a disconnected local network from being mistaken for a dead node and reduces configuration loss caused by repeated client reinstalls.
Pause the proxy
Exit the system proxy or disable VPN mode, then open two commonly used websites in a browser to confirm that the device itself can access the internet normally.
Check the clock
Enable automatic date, time, and time-zone settings, then sync once manually to keep the clock difference within 60 seconds.
Check the port
Make sure the local SOCKS or HTTP listening port matches the system proxy. For example, 10808 is a common local port for v2rayN.
Test one node
Choose one node and run a real connection latency test. Do not substitute a batch result for a single-node retest.
Update the subscription
Update the subscription only after the local connection is working, then compare the old and new nodes' addresses, ports, and transport parameters.
Assess the remote side
Consider a closed remote port or an unavailable server only when the same node continues to time out across different networks and devices.
Confirm the local network and system time
First verify the basic network with the proxy disabled. A browser loading a cached page does not prove that the network is working; visit a page you have not opened before, or use a system command to test DNS resolution directly. On Windows, run nslookup example.com in a terminal. On Linux and macOS, use nslookup or dig. If the domain cannot be resolved, fix the current network or DNS first instead of changing the node protocol.
Also check whether the network is restricting remote ports. On a home network, temporarily switch to a mobile hotspot for comparison; on a mobile network, switch to a fixed connection and test again. If the same node times out on network A but connects on network B, the client configuration is usually not fundamentally wrong. Focus instead on the network egress, DNS results, and port reachability.
Protocols such as VMess rely on a reasonably accurate system clock for authentication. If the device clock is off by several minutes, the client may establish a TCP connection but fail during the protocol handshake. In Windows 11 24H2, go to “Settings” → “Time & language” → “Date & time,” enable automatic time and automatic time zone, then click “Sync now.” In Android 15, go to “Settings” → “System” → “Date & time” and enable network-provided time.
- Ordinary websites still fail with the proxy disabled: fix the local network first; do not start with node parameters.
- Domain-based node fails while an IP-based node connects: check the DNS result and the network's DNS first.
- Fixed connection fails while the mobile hotspot works: check the router's DNS, access controls, and egress restrictions.
- All VMess nodes fail at once: check the system time, UUID, and subscription update time.
- Only one port fails: check the remote port status instead of resetting the entire configuration.
Error:lookup server.example on 127.0.0.1:53: no such host
Cause and fix:The node domain did not resolve successfully. Disable the proxy and run a DNS resolution test, then switch to a working DNS server and restart the client core.
Error:dial tcp: i/o timeout
Cause and fix:The client did not connect to the remote address and port within the allowed time. Retest on another local network and confirm that the server address and port in the subscription are still current.
Error:context deadline exceeded
Cause and fix:A connection task exceeded its deadline. This may occur during DNS resolution, TCP connection setup, or the transport-layer handshake. Use the address, port, and stage next to this line in the log to identify the problem; do not look only at the final line.
Conclusion: Comparing networks beats repeating latency tests
The results from the same configuration on two independent networks are more useful for distinguishing local restrictions from node failures than clicking a latency test ten times. If the mobile hotspot works, keep the client configuration and investigate the original network's DNS and port reachability.
Verify node and transport parameters
Once the local network is working, verify the node one item at a time. Matching protocol names do not mean configurations are interchangeable. VMess requires the correct server address, port, user ID, security settings, and transport parameters; VLESS requires matching user ID, flow-control options, and transport-layer settings. If the server changes its path, hostname, or TLS parameters after a subscription update, the old configuration may remain in the list but can no longer complete the handshake.
Do not rebuild a node from memory. Use the currently valid subscription or the configuration supplied by the server as the reference, and compare the server address, port, protocol, transport method, TLS, SNI, Host, and WebSocket path. Case and leading slashes matter in paths: /ray and /Ray are different values.
| Check item | Common symptom | What to verify |
|---|---|---|
| Server address | Resolution failure or repeated timeouts | Domain spelling, DNS result, and whether it still points to the current server |
| Remote port | connection refused or i/o timeout | Port number, service listening status, and network egress restrictions |
| User ID | Disconnects shortly after connecting | Every character, grouping, and whether an old subscription value is being used |
| TLS and SNI | Handshake failure or certificate name mismatch | TLS setting, Server Name, and system time |
| WebSocket | TCP is reachable but proxy requests fail | Host, Path, letter case, and leading slash |
| gRPC | Transport-layer setup failure | serviceName, TLS settings, and server configuration must match |
In v2rayN 7.x, select the node first, then view or edit the server from the context menu. To verify the core, go to “Settings” → “Parameter settings” → “Core type” and check that the current protocol is handled by the corresponding core. After editing, save the configuration, restart the core, and test the current node; closing the window alone may not reload the configuration used by the running core.
v2rayNG uses the Xray core, while v2flyNG uses the v2fly core. Importing from a QR code or clipboard transfers only the fields actually included in the link; it cannot fill in transport parameters required separately by the server. If fields are missing after import, update the subscription first instead of guessing values from another node.
Error:connection refused
Cause and fix:The target host explicitly refused the connection on that port, commonly because the service is not listening or the port has changed. Update the subscription and verify the remote port; if the issue occurs on multiple networks, contact the server operator.
Error:remote error: tls: handshake failure
Cause and fix:TLS negotiation did not complete. Check the system time, TLS setting, SNI, and transport method, making sure each field matches the current node configuration.
Error:invalid user
Cause and fix:The server rejected the current user identity. Check that the user ID is complete and confirm that the client is not still using the old node from before the subscription update.
Check the local port and proxy status
Even when the node itself works, an incorrect local proxy port can appear as a browser timeout. With common settings, v2rayN may listen on local port 10808, and the browser extension or system proxy must point to the same port. If the client uses 10809 while the system proxy still connects to 10808, the request never reaches the current core.
On Windows, run netstat -ano | findstr :10808 in a terminal to see whether the port is LISTENING and record the associated PID. On Linux and macOS, run lsof -nP -iTCP:10808 -sTCP:LISTEN. If the port is not listening, check whether the core has started. If another program is using it, stop the conflicting process or change the client's listening port, then update the system proxy accordingly.
Windows:
netstat -ano | findstr :10808
tasklist | findstr 4321
Linux / macOS:
lsof -nP -iTCP:10808 -sTCP:LISTEN
Local SOCKS test:
curl --proxy socks5h://127.0.0.1:10808 https://example.com/The letter h in socks5h means that domain resolution is handled by the proxy. If a normal browser request fails but the command above returns page content, focus on the browser proxy mode, system proxy address, or extension rules rather than the node. If the command also times out, check the client log for a corresponding request.
Confirm the listener
Check whether 127.0.0.1:10808 is being listened to by the current client process, and record the process ID for comparison.
Use one port everywhere
Use the same port in the client, system proxy, and browser settings. Do not mix 10808 and 10809.
Restart the core
Save the parameters and restart the core so that the listening port and routing configuration are loaded again.
Send a request
Send a request through the local SOCKS port with curl while watching the log for a new connection record.
Use real connection latency to isolate the fault
A basic connectivity test and real connection latency are not the same. Testing only a TCP port usually proves merely that the target port accepts a connection; it does not prove that the VMess, VLESS, TLS, WebSocket, or gRPC handshake succeeds. Real connection latency sends an actual request through the current proxy path, making it better for determining whether a node provides a fully working outbound connection.
In v2rayN, select a single node and choose “Test server real connection latency” from the context menu. Before testing, make sure the node configuration is saved and the system clock is correct. Three consecutive tests provide a basic signal: one success and two failures may indicate link instability; if all three time out after the 10-second wait, compare against other nodes and networks.
Do not rank nodes by latency alone. A node showing 180 ms but succeeding three times in a row is usually more stable than one that occasionally shows 60 ms and then times out twice. During testing, pause large file transfers, system updates, and cloud synchronization to avoid false results caused by saturated local bandwidth.
| Test result | Initial assessment | Next step |
|---|---|---|
| Single node succeeds, browser fails | The node connection path is basically working | Check the system proxy, browser proxy, and routing rules |
| All nodes time out simultaneously | The local network, DNS, system time, or entire subscription may be at fault | Disable the proxy to verify the network, then update the subscription |
| Only one node times out | A single-node parameter or server-side problem | Compare other nodes in the same subscription and retest across networks |
| TCP is reachable, but the real connection times out | The protocol or transport-layer handshake failed | Check the user ID, TLS, SNI, Host, and Path |
| Real connection succeeds, but speed is abnormal | Link congestion or fluctuating routing quality | Retest at different times and compare other nodes |
Conclusion: Use success rate to judge stability
Three consecutive real connection tests on a fixed network are more informative than a single lowest-latency result. Three successes with no retries in the log indicate that the complete proxy path is established; repeated timeouts at the same stage should be investigated at that stage.
Update the subscription or switch nodes
Once the local network, system time, local port, and client proxy status are all normal, update the subscription. In v2rayN, first confirm that “Subscription groups” contains the current address, then update all subscriptions. Do not delete the old group immediately; compare the server address, port, protocol, and transport parameters of same-named nodes first.
Android clients should also update the current subscription before testing newly generated node entries. A manually imported single node does not receive subscription-side changes automatically; if the server changes the port or transport path, the old QR code and link retain their original values. Scanning the old content again is pointless—obtain the currently valid configuration instead.
- A new node appears after updating and connects successfully: use the new entry and remove the expired copy.
- The update succeeds but the list is unchanged: confirm the subscription update time and group address.
- The subscription request itself times out: disable the proxy and update directly first, then follow the provider's instructions on whether updates should use a proxy.
- Only one node in the subscription fails: keep the other working nodes and record the faulty node's details separately.
- All nodes continue to fail across devices and networks: the subscription may be invalid or the remote service may be undergoing maintenance. Stop repeatedly changing the client.
Switch nodes based on reproducible results, not a single random timeout. Keep a simple record of the test date, device, network, client, node name, three real connection results, and log errors. If the same node cannot connect on Windows, Android, and two networks while other nodes in the same subscription work, the evidence for a single-node failure is strong enough.
Reinstalling the client is appropriate only for local problems such as missing program files, failure to launch, or a corrupted configuration database. Node timeouts usually occur in the network, parameters, or remote path; reinstalling does not change the server address, port, system time, or network restrictions. Export the current configuration or record the subscription group before troubleshooting to avoid adding new variables after a reinstall.
Error:failed to update subscription
Cause and fix:The client could not retrieve the subscription content. Verify that the subscription address is complete, try updating with the proxy disabled and with a working node enabled, and check the returned status.
Error:unexpected EOF
Cause and fix:The connection closed before the full response was read. Possible causes include link instability, a transport mismatch, or an intentional disconnect by the remote side. Retest on another network and verify the TLS and transport parameters.
Create a reproducible troubleshooting record
A troubleshooting record does not need complex tools, but it must be reproducible. At minimum, include the OS version, client name, test time, network type, node protocol, local port, and exact error. For example, “Windows 11 24H2, v2rayN 7.x, fixed network, VMess, 127.0.0.1:10808, three real connection tests all timed out after 10 seconds” is far more useful than “the node does not work.”
When sharing logs, hide the server address, user ID, subscription address, and authentication information. Keep only the error type, time, and connection stage. The first anomaly in a log is usually closer to the cause than the final “task failed” message. Start reading from where a test begins and look for the earliest DNS, connection, TLS, or protocol-handshake error.
Record the environment
Write down the OS version, client, network type, local listening port, and test time.
Fix the node
Choose one node and save its server, protocol, port, and transport method. Do not switch nodes during the test.
Run three tests
Complete three consecutive real connection tests and record success, timeout, or the specific error—not just the latency number.
Switch networks
Repeat the same test on another independent network while keeping the client configuration unchanged.
State the conclusion
Use the differences to classify the issue as a local network, client setting, node parameter, or server problem, then make one targeted correction.