Use this guide when v2rayN node tests time out, your browser cannot load pages, or v2rayNG shows a connection but apps cannot access the internet. First confirm the request is going through the client, then check the clock, local listener, server port, and handshake settings. Change one thing at a time and retest the same destination to avoid mistaking a system proxy issue for a node failure.
1. Identify Where the Timeout Occurs
A “timeout” message tells you what happened, not why. A request may pass through app proxy settings, a local inbound listener, DNS resolution, a remote connection, and a protocol handshake. If an earlier step fails, correct TLS settings later in the chain won't help. Note the failure time, the node's protocol and server port, and whether system proxy or TUN mode was enabled.
v2rayN is a desktop client; the selected core handles the connection. v2rayNG uses the Xray core, while v2flyNG uses the v2fly core. Protocols, clients, and cores are different things. When troubleshooting, note the core and version actually in use instead of saying only “V2Ray isn't working.”
- Only the browser fails: Check browser proxy extensions, system proxy settings, and routing rules before reinstalling the client.
- The same node fails in every app: Check the client log, then work outward from the local port to the remote address and handshake.
- Only the latency test fails: Check the test type and destination. An unreachable test target can make a working node appear to time out.
- The subscription won't update: This points to an issue accessing the subscription URL; it does not prove that all imported nodes are unavailable.
2. Sync the System Clock, Then Retry
An incorrect date, time, or time zone can affect certificate validity checks and VMess time-based authentication. VLESS does not use the same time-based authentication as VMess, but TLS connections still require server certificate validation. Switching a node to VLESS is no reason to skip the clock check.
-
Check the Date and Time
In Windows 11, open Settings → Time & language → Date & time. Check the date and current time, then turn on Set time automatically. Make sure the time zone matches your location; the hour shown in the taskbar alone isn't enough to confirm the system clock is correct.
-
Sync the Clock
Select Sync now on the same page. If syncing fails, check whether your current network allows access to time servers. Recheck the clock after waking from sleep, restoring a virtual machine snapshot, or replacing a failing motherboard battery.
-
Check Sync Status
Open PowerShell and run the query command below to check the time source and the last successful sync. To sync again, run the second command as an administrator. If the service isn't running or no time data is available, address the message shown first.
-
Retry the Connection
After correcting the clock, stop and restart the client connection, then retest the same node and destination. On Android, search Settings for “Date & time” and enable automatic time; menu names vary by device.
w32tm /query /status
w32tm /resync3. Check That the Local Port Is Listening
Enabling the system proxy doesn't mean the core started successfully. If the proxy points to a port with no listener, the browser will usually fail immediately. If another process has claimed the port, the client may also fail to create its inbound listener. In v2rayN, check the local listening port and inbound type under Settings → Parameter settings. Menu names may vary by version, so use the setting labels shown in your client.
The examples below use local port 10808. The first command shows the listening process ID; the second identifies that process. If your client uses a different port, change the number in both commands. No output usually means no TCP listener was found on that port.
Get-NetTCPConnection -State Listen -LocalPort 10808 -ErrorAction SilentlyContinue |
Select-Object LocalAddress, LocalPort, OwningProcess
Get-NetTCPConnection -State Listen -LocalPort 10808 -ErrorAction SilentlyContinue |
ForEach-Object { Get-Process -Id $_.OwningProcess }Error: Only one usage of each socket address (protocol/network address/port) is normally permitted.
Cause: On Windows, this usually means another process or a duplicate client instance is already using the local port.
Fix: Check the bind address and port in the log, then close any duplicate processes you don't need or change the local listening port. Update the app's proxy settings to match.
Next: Confirm the Listener Before Changing the System Proxy
If nothing is listening on the local port, start by checking the core startup log. If the correct process is listening, confirm whether the app expects an HTTP, SOCKS, or mixed inbound. Don't point an HTTP proxy at a SOCKS-only port.
4. Test DNS and the Server Port Separately
Once the local listener is working, check the node's server address. The server address is used to establish the connection; TLS SNI supplies the server name during the handshake. They can differ. Read the server address from the node editor—don't test the subscription URL or a WebSocket path instead.
Run these commands in Windows PowerShell. When prompted, enter your server hostname or IP address and the remote port from the node configuration. The input is used locally for diagnosis; don't post full output containing personal node details publicly.
$server = Read-Host "Enter the node's server hostname or IP"
$port = [int](Read-Host "Enter the node's remote port")
Resolve-DnsName -Name $server
Test-NetConnection -ComputerName $server -Port $port -InformationLevel Detailed- DNS lookup fails: Check the spelling, whether the subscription is up to date, and whether DNS is working on your current network. If you entered an IP address, focus on the port test that follows; a DNS lookup says nothing about the node's health in that case.
TcpTestSucceeded : False: Check whether the server is online, the port is correct, the remote firewall allows the connection, and your current network isn't blocking it.TcpTestSucceeded : True: This confirms only that this TCP connection succeeded. It doesn't verify the UUID, transport, TLS, or proxy egress.- The hostname has both IPv4 and IPv6 records: Check the actual
RemoteAddress. Routing issues with one address family can cause intermittent timeouts; change address selection only after confirming a difference.
5. Check TLS, Transport, and Authentication in Order
If the remote TCP port is reachable but the proxy still doesn't work, check the handshake settings. Don't assume configurations match just because both use port 443: one port can host different services, and a reverse proxy may route traffic by name, path, or service name.
| Layer | Settings | Common mistakes and what to check |
|---|---|---|
| TLS | Security type, SNI, certificate name | Set SNI as configured on the server. The name covered by the certificate may differ from the server IP; don't substitute one for the other. |
| Transport | TCP、WebSocket、gRPC | The client and server settings must match. Changing transport isn't a general-purpose fix for timeouts. |
| WebSocket | Host and path | The leading slash, capitalization, and suffix in the path can all affect reverse-proxy routing. Host isn't necessarily the same as SNI. |
| gRPC | serviceName、ALPN | The service name must match the server configuration. For HTTP/2 over TLS, the server must correctly negotiate h2. |
| Protocol authentication | UUID, password, flow | Check the identity fields for the protocol in use. For VLESS, flow must match on the client and server. |
| REALITY | Public key, shortId, serverName | REALITY has its own handshake settings; don't troubleshoot it as a standard TLS certificate issue. |
If the node comes from a subscription, save its current settings, update the subscription, and compare the changes. The next update may overwrite manual edits, so note what you changed. Don't change SNI, transport, and server address all at once; even if the connection comes back, you won't know which change fixed it.
Error: x509: certificate has expired or is not yet valid
Cause: The device clock is wrong, or the server certificate is outside its validity period.
Fix: Correct the device clock first, then ask the server administrator to check the certificate validity period and deployment.
Error: remote error: tls: handshake failure
Cause: The remote side rejected the TLS handshake. Possible causes include SNI, protocol negotiation, or server configuration; this log message alone doesn't identify the cause.
Fix: Check the TLS fields one by one and compare them with server logs from the same time to find out why the handshake was rejected.
Error: websocket: bad handshake
Cause: The expected WebSocket upgrade response wasn't received. A mismatched path, Host, or reverse-proxy forwarding configuration is a common cause.
Fix: Check the node's WebSocket settings, then confirm the server forwards upgrade requests to the correct inbound.
6. Verify the Proxy Path with a Consistent Request
After checking the settings, send a request to the same destination each time. The command below is for a local inbound confirmed to accept SOCKS on 10808; replace the port if your configuration differs. socks5-hostname sends the destination hostname to the proxy for resolution, keeping local DNS issues for the destination site out of this test.
curl.exe --proxy socks5-hostname://127.0.0.1:10808 --connect-timeout 10 --max-time 20 --head https://example.com/The 10- and 20-second limits are set by the diagnostic command; they aren't performance benchmarks for the node. A normal HTTP response header means the request reached its destination through the local SOCKS inbound. A non-success status code doesn't necessarily mean the proxy failed—check the response content. If the request fails, check the core log for the same timestamp.
- Local curl works, but the browser fails: Check whether a browser extension overrides the system proxy and whether the system proxy address and port are correct.
- The browser works, but the terminal fails: Terminal apps may not use the system proxy. Test with an explicit proxy option, then check environment variables.
- v2rayNG shows connected, but apps fail: Check Android VPN permission, per-app proxy settings, and whether another VPN connection is active.
- Only some domains fail: Check routing rules, DNS for the destination, and the destination site's status. A direct-connection failure caused by a rule doesn't mean the entire node is timing out.
If TUN or complex routing is enabled, confirm which outbound the test request actually uses. Specifying the local proxy explicitly rules out differences in whether an app reads the system proxy, but it doesn't bypass the client's routing rules. For rule priority, see the routing guide.
7. Cross-Check Before Blaming the Remote Server
If the local listener, system clock, remote address, and handshake settings all check out, run a few controlled comparisons. Keep the same device and node but switch to another network you can use. Then stay on the same network and test another known-working node. Change one condition at a time so the results are meaningful.
Error: i/o timeout
Cause: A read or write didn't complete in time. This could happen during connection, handshake, or data transfer; use the surrounding log entries to pinpoint the stage.
Fix: First check whether the target address in the log belongs to the remote node or the destination website. Then test the port or cross-check the relevant layer.
Error: connection refused
Cause: Nothing is listening on the target port, or the connection was actively rejected. This differs from a timeout, where no response arrives for an extended period.
Fix: Determine whether the rejected connection was to the local inbound or the remote port. Check core startup status for the former, and the server listener and firewall rules for the latter.
Narrow It Down to a Reproducible Layer
If the same node works on another network, focus on the original network path. If only one node fails on the same network, check that node's settings and remote status first. These results are clues, not proof; confirm with logs rather than assuming throttling or blocking.
- Record the environment: Operating system, client version, core and version in use, and whether you're using system proxy or TUN mode.
- Record what happened: Failure time, test method, whether every app failed, and any settings changed recently.
- Share only relevant logs: Keep a few lines before and after the failure, and redact subscription tokens, UUIDs, passwords, and personal server details.
- Restore diagnostic settings: When you're done, return logging to its normal level, remove temporary proxy variables, and delete test rules you no longer need.
If you still can't identify the issue, follow the troubleshooting steps. Start by finding out which layer failed, what error appeared, and how to reproduce it. That's more useful than repeatedly updating subscriptions, switching cores, or reinstalling the client.