Use this guide when v2rayN opens and nodes are imported, but latency tests time out or your browser cannot connect. First distinguish a local proxy that is not running from an unreachable remote port or a failed protocol handshake. Then check system time, local listeners, firewall rules, transport settings, and routing/DNS in order. Record a repeatable test result at each step, and avoid changing multiple settings at once.
1. Identify Where the Timeout Occurs
A “node timeout” can have several causes. A TCP latency test typically checks only whether a connection to the remote port can be established. A real connection or availability test also involves the proxy protocol and destination website. Results can vary depending on the test target. A successful TCP test does not mean VMess or VLESS authentication succeeded, and failure to reach one test site does not mean all traffic is blocked.
Choose one node as your test case and record the test time, server address, port, protocol, transport, and active core. Open the log pane in the v2rayN main window, send a new request, and find the first error at that time. Later connection-closed messages are often just consequences of the earlier error.
- All nodes fail at once: Check the system clock, local core, network egress, and whether the subscription itself is down.
- Only one node fails: Check that node’s settings, server status, and account validity first.
- Proxy test succeeds, but the browser fails: Check whether the app is using the system proxy and whether a browser extension is overriding its proxy settings.
- Some websites fail: Check routing rules, DNS, and whether the destination is reachable before reinstalling the client.
2. Sync Your System Clock, Then Retry
VMess authentication is time-sensitive, so a significant clock difference between client and server can cause authentication to fail. TLS certificate validation also depends on the current time: an incorrect date or year can make a valid certificate appear not yet valid or expired. VLESS does not use the same simple time-window check as VMess, but the system clock must still be accurate when using security layers such as TLS.
-
Sync the system clock
On Windows 11, go to Settings → Time & language → Date & time, turn on Set time automatically, then select Sync now. On macOS, go to System Settings → General → Date & Time and turn on automatic time and date.
-
Check the actual date and time
Make sure the date and current time are correct. The time zone affects how the time is displayed; authentication mainly depends on the actual timestamp. Don’t change the displayed time zone to match the server’s location. If the clock repeatedly drifts after sleep, check the system time service and hardware clock.
-
Reload the node
In v2rayN, select the current node again to reload its configuration, then repeat the same connection test. If you manage the server, check its clock too; correcting the client alone won’t fix a significant time difference on the server.
3. Check Local Ports: Use the Configured Values, Often 10808 and 10809
v2rayN is the client interface; the running core handles listening on local ports and forwarding connections. If the core fails to start, the interface may still show your node list, but apps will fail when they try to connect to the local proxy port. Port assignments vary by version and configuration. A common setup uses 10808; older configurations may use 10808 for SOCKS and 10809 for HTTP. Configurations with a mixed inbound can accept both types of requests on the same port.
Go to Settings → Parameter settings and check the local listening port and address; field names vary by version. Then check the logs for a successful listener startup. Don’t set your browser to 10809 just because an online guide says so, and don’t enter the local proxy port as the remote server port.
| System | Command | What to check |
|---|---|---|
| Windows PowerShell | Get-NetTCPConnection -State Listen -LocalPort 10808 | Whether a listener is listed and whether OwningProcess belongs to the expected core |
| Windows process lookup | Get-Process -Id 1234 | Replace 1234 with the process ID from the previous result |
| macOS Terminal | lsof -nP -iTCP:10808 -sTCP:LISTEN | Check the listening process and port. If there’s no output, check the core logs next. |
If another program is using the port, identify the process before taking action; don’t terminate an unfamiliar system service. You can close a duplicate client instance or change the local port to an unused one, then update the app’s proxy settings to match. For local use only, listening on 127.0.0.1 is usually sufficient; you don’t need to enable LAN access for troubleshooting.
curl --proxy socks5h://127.0.0.1:10808 --connect-timeout 10 --max-time 20 -I https://example.com/On Windows, use curl.exe to avoid differences caused by command aliases. The command above applies only if that port supports SOCKS; socks5h means the proxy resolves the destination hostname. If only an HTTP inbound is available, set the proxy address to http://127.0.0.1:10809 and use the configured port. An HTTP response means the request reached the destination through the proxy; handle a 403 differently from a connection timeout.
4. Test the Remote Port and Firewall; Don’t Use Ping as a Substitute
A server may block ICMP, so a failed Ping does not prove the proxy service is unreachable. Conversely, a successful Ping does not prove the proxy port is listening. For a TCP connection, test the server address and port used by the node. The domain below is only an example of the command format. Replace it with the actual address in your node configuration, and use the configured port.
# Windows PowerShell: test a TCP port
Test-NetConnection -ComputerName example.com -Port 443
# macOS: test a TCP port
nc -vz -G 10 example.com 443- Port test succeeds: A TCP connection was established. Check TLS, the transport, and protocol authentication next; this alone doesn’t mean the node is fully working.
- Connection refused immediately: The service may not be listening, the port may be wrong, or a firewall may be actively rejecting the connection. Ask the server administrator to check the process, listening port, and inbound rules.
- Times out after waiting: Possible causes include packet loss, egress restrictions, or a server firewall or security group dropping traffic. Test from another network to compare.
- Using UDP: A TCP test cannot verify UDP connectivity. Check the relevant core logs and server records instead.
On your computer, check the core process’s outbound firewall permissions. You only need to consider local inbound proxy rules if you’re sharing the proxy with other devices. Don’t leave the firewall disabled to troubleshoot; ask your network administrator to handle any corporate network restrictions. On the server, check both the cloud security group and the operating system firewall. Either one can cause timeouts if it blocks the connection.
Next step: Compare networks
Keep the same node and settings, switch your computer to an Android phone’s hotspot, and test again. If the connection times out on your usual network but works on the hotspot, investigate your usual network’s egress, DNS, or port policies. This comparison narrows down the cause more effectively than changing the node, core, and routing at the same time.
5. Check Transport Settings: An Open Port Doesn’t Guarantee a Successful Handshake
VMess and VLESS are proxy protocols; WebSocket and gRPC are transports; TLS is a security layer. They belong to different configuration layers and aren’t interchangeable. After importing a link, check the key fields, especially for nodes that use a reverse proxy or relay: the connection address, TLS verification domain, and HTTP Host may all differ.
| Setting | Values that must match | Common mistake |
|---|---|---|
| Protocol and credentials | VMess or VLESS type, UUID, and any other parameters required by the server | Changing only the protocol name while keeping all settings from a different type of node |
| TLS and SNI | Whether TLS is enabled, the verification domain, and the certificate’s covered domains | Changing the connection address to an IP and accidentally removing the required SNI |
| WebSocket | Transport, path, Host, and reverse proxy rules | Mixing up /ray and /ray/, or using different path capitalization |
| gRPC | Service name and the server-required HTTP/2 and TLS settings | Putting a WebSocket path in the service name field |
| VLESS security settings | The flow specified by the server; for REALITY, the public key, shortId, serverName, and other required values | Copying security settings from another node or switching security layers arbitrarily |
If the subscription has updates, use the Subscription group menu to update the relevant group, then select the node again. An older node you edited manually may still have an outdated port, path, or credentials. Don’t assume that selecting a particular core makes every node compatible. Check that the active core, such as Xray-core, supports the node’s required features, and prefer the core provided with the client.
Error: bind: address already in use
Cause: The local listening address and port are already in use, so the current core can’t bind to them.
Fix: Identify the process using the port, close a duplicate instance or change the local port, then update the app’s proxy port to match.
Error: x509: certificate has expired or is not yet valid
Cause: The local clock is wrong, or the server certificate is actually outside its validity period.
Fix: Sync the clock first. If the error persists with the correct time, ask the administrator to check certificate renewal and the certificate chain being served.
Error: websocket: bad handshake
Cause: The WebSocket upgrade request didn’t receive the expected response. Common causes include a mismatched path, Host, or reverse proxy forwarding configuration.
Fix: Check the path and Host character by character, and ask the server administrator to verify the response from the entry point and the upgrade request forwarding settings.
Error: context deadline exceeded
Cause: An operation didn’t finish before its deadline. This message alone doesn’t identify whether the problem is authentication, DNS, or the network.
Fix: Check the connection target and surrounding log entries, then use local listener and remote port tests to identify where the timeout occurs.
6. Once the Proxy Works, Check System Proxy, DNS, and Routing
If a curl request with an explicitly specified proxy succeeds but the browser still can’t connect, first select Set system proxy automatically from the System proxy menu in the v2rayN tray menu. Then check whether the browser has its own proxy settings. The system proxy only affects apps that follow it; it doesn’t route all network traffic. Avoid enabling or switching TUN during initial troubleshooting, as it adds variables such as virtual adapters, routing, and permissions.
- Check which rule matched: Confirm in the logs which outbound was used for the failed request. If a rule sends the destination through a direct connection, it may fail even when the node is working.
- Distinguish where DNS resolution happens: The remote node address must be resolved first. Successfully resolving a destination website remotely over SOCKS doesn’t mean your computer can resolve the node’s hostname.
- Compare address families: If a domain returns both IPv4 and IPv6 addresses, check whether only one address family fails. Don’t disable IPv6 system-wide as a first step.
- Check the test target: The availability test site may be temporarily down or restricting requests. Test against two known-reachable HTTPS sites rather than relying on a single latency result.
7. Record Reproducible Results Before Changing Nodes
Troubleshooting should end with a repeatable result, not “it seems to work after a restart.” Once the connection is restored, repeat the same request twice and check that handshake or listener errors aren’t still appearing in the logs. If only a specific node fails, and local ports, system time, and network comparison tests are all normal, contact the node provider.
- Record your operating system and v2rayN versions, as well as the name and version of the core actually running. Get version numbers from the current program information; don’t infer them from the installer’s filename.
- Record when the failure occurred, the results on your usual network and hotspot, and whether the TCP test and explicit proxy request each succeeded or failed.
- Share the relevant log entries from around the same request. Hide subscription links, UUIDs, access tokens, and personal network information; don’t publish the full configuration.
- Record the results before and after each change. Change one setting at a time, and revert ineffective changes before the next test.
Follow this order: sync the clock, confirm the core is listening, test the remote port, check transport and authentication, then check app proxy settings, DNS, and routing. This breaks “everything times out” into specific, testable problems and avoids losing useful diagnostic clues by repeatedly switching clients.