This guide covers connection timeouts in v2rayN for desktop and v2rayNG or v2flyNG for Android. First identify which test is failing, then check the system time, local listener, and request entry point. Next verify the server address, TLS, and transport settings, and finally check the server listener and firewall. Save logs and retest results at each step so you can pinpoint the cause without changing several settings at once.
1. Tell a test timeout from a connection failure
A “timeout” in the node list doesn’t mean every function of that node is unavailable. A TCP connectivity test only checks whether a TCP connection can be established. Testing a URL through the proxy also involves protocol authentication, TLS, DNS resolution, and the destination website’s response. Note which test you ran; don’t treat different test results as the same metric.
- Only the list test fails: Select the node, visit a known-working website in your browser, and check the client logs. If the site loads, focus on the test URL and the route used for the test request.
- The test succeeds, but the browser fails: Check that the browser is sending requests through the local proxy and that no browser extension has its own proxy settings.
- All nodes fail at once: Check whether the core started, the system time is correct, and the current network requires web-based sign-in. Don’t start by changing each node’s settings.
- Only one node fails: Keep a working node as a comparison and check the failing node’s address, port, transport settings, and server status.
Before you start, note the client version, core, operating system, test time, and a snippet of the failure log. The v2rayN interface varies by version. Menu names below refer to the classic Windows interface; in other versions, look for settings with the same names rather than relying on their location.
2. Check the system time and basic connectivity first
A significantly incorrect system time can affect TLS certificate validity checks and may also cause VMess time-based authentication to fail. VLESS does not use the same time check as VMess, but the system time must still be correct when TLS is used. Changing the displayed time zone alone won’t fix an incorrect system clock.
-
Sync the system clock
On Windows, go to Settings → Time & language → Date & time, turn on Set time automatically, then select Sync now. On Android, search system settings for Date & time and enable automatic time. Menu names may vary by device.
-
Check your internet connection
Disconnect the proxy temporarily and check whether the current network requires web-based sign-in. On public Wi-Fi, complete the sign-in first, then start the client. Don’t keep refreshing nodes before basic connectivity is working.
-
Retest with one controlled change
Keep the node and its settings unchanged, switch networks once, and retest. If the same node works on another network, investigate DNS, outbound traffic policies, or access restrictions on the original network. This alone doesn’t prove the server is at fault.
On Windows, you can also check time sync status from the terminal. The command below only displays information; it doesn’t change node settings. If the time service isn’t running, return to the system time settings and check the service and sync status.
w32tm /query /status3. Check the local listener and app entry point
The local core may fail to start before the server receives any connection. In the classic v2rayN interface, check the local listener under Settings → Parameter settings, then confirm the system proxy status on the main screen. Use the actual interface and startup logs as your guide: some versions use a mixed listener, so don’t assume every version has separate SOCKS and HTTP ports.
These ports are only used in command examples; they are not defaults for any particular client version. Before running the commands, confirm the protocol and port in your own configuration. If your local SOCKS listener is at 127.0.0.1:10808, for example, first check that it’s listening, then explicitly send a request through the proxy:
Get-NetTCPConnection -LocalPort 10808 -State Listen
curl.exe -I --connect-timeout 10 --max-time 20 --proxy socks5h://127.0.0.1:10808 https://example.com/Run the first command in PowerShell. If no listener appears, check the core startup log and local port before investigating remote certificates. In the second command, example.com is a sample destination; replace it with a known-working HTTPS site when troubleshooting. socks5h sends the destination hostname to the proxy for resolution. The 10- and 20-second limits are explicitly set for these commands; they aren’t test results.
What it means: explicit proxy works—fix the app entry point first
If the command gets an HTTP response but your browser still can’t reach the same destination, check the system proxy, browser-specific proxy settings, and routing rules first. A status such as HTTP 403 still means a response was received; it’s not the same as a connection timeout.
- v2rayN: The system proxy only affects apps that follow that setting. An explicit proxy command bypasses the system proxy entry point, but it does not bypass routing rules in the core.
- v2rayNG and v2flyNG: Confirm that Android VPN permission is granted and that no other VPN connection has replaced the current one. If per-app proxying is enabled, check that the target app is included.
- Only fails after the screen locks: Check Android background activity and battery restrictions, and see whether connection logs continue after the screen locks. Don’t change the server port to fix a background process that’s being stopped.
4. Check the server address, DNS, and port
This step checks whether the node’s server hostname resolves—not whether the website you’re visiting in your browser resolves. They may use different resolution paths. A mistyped server address, stale DNS record, or IPv6 address unreachable from the current network can all cause a node timeout.
| Check | What to do | What the result tells you |
|---|---|---|
| Server address | Compare the hostname spelling, spaces, and port with the node source | The address field usually shouldn’t contain a full webpage URL or transport path |
| DNS resolution | Use Resolve-DnsName to query the node hostname and compare its A and AAAA records | A successful system lookup doesn’t guarantee the core’s DNS resolution path will work |
| Remote TCP | Use Test-NetConnection to test the actual node address and port | Checks TCP connectivity only; it doesn’t verify the protocol handshake or UDP connectivity |
| Network comparison | Retest on another network with the same device and configuration | Change only the network; don’t also change DNS and transport settings |
In PowerShell, use interactive input so you don’t mistake a sample hostname for your actual node. The 443 port applies only if the remote node really listens on that port; if it uses another port, change the number in the command.
$server = Read-Host "Enter the node server hostname"
Resolve-DnsName $server
Test-NetConnection -ComputerName $server -Port 443TcpTestSucceeded : True only means a TCP connection can be established to that address and port. If the node uses a CDN, it may only confirm connectivity to the CDN edge, not the origin server. A failed ping alone doesn’t mean the node is offline; network equipment may not respond to ICMP.
5. If TCP works, check TLS and transport settings
If the TCP connection succeeds but proxy requests still fail, focus on protocol authentication and handshake settings. Recheck the original node details from a trusted source; don’t change every node to the same transport based on guesswork. v2rayNG uses the Xray core, while v2flyNG uses the v2fly core. Whether a configuration works depends on the protocol, features, and core version; a successful import alone doesn’t prove compatibility.
- Protocol and credentials: Confirm the VMess or VLESS type, user ID, encryption, and flow settings match the server. If the server configuration changed after a subscription update, the old node may still be in your list.
- TLS: Check whether TLS is enabled, the SNI server name, the domain covered by the certificate, and the ALPN required by the server. If you change the connection address to an IP, keep the correct TLS server name. Don’t disable certificate verification as a routine fix.
- WebSocket: Check the path and Host value. The leading
/in a path and letter case may both matter. Configure the reverse proxy with the matching path and protocol upgrade forwarding. - gRPC: Make sure serviceName matches the server and that the reverse proxy supports the required HTTP/2 forwarding. Don’t reuse WebSocket forwarding settings.
- REALITY: Check the server-provided public key, shortId, server name, and other fields. Make sure the client and core support the configuration; don’t treat it as a standard TLS node.
Error: connection refused
Cause: The connection was actively refused, often because nothing is listening on the target port or a firewall rejected it. Fix: Check whether the address in the log is local or remote, then inspect the local core or remote listener as appropriate. Don’t assume the node has expired.
Error: i/o timeout
Cause: A network read or write didn’t complete before its deadline. This may happen during connection setup, the handshake, or while waiting for a response. Fix: Check surrounding log entries to identify what timed out, then test the port and compare networks. This line alone doesn’t identify which side is responsible.
Error: x509: certificate has expired or is not yet valid
Cause: The current time is outside the certificate’s validity period. The device clock may be wrong, or the server certificate may have expired. Fix: Sync the system clock first. If the error persists, ask the service maintainer to check the certificate’s validity and deployment.
Error: websocket: bad handshake
Cause: The WebSocket upgrade didn’t receive the expected response, often because the path, Host value, or reverse proxy settings don’t match. Fix: Compare the node fields with the entry point, and ask the server administrator to confirm that the request reaches the correct forwarding destination.
These are examples of error snippets that may appear in logs; exact wording varies by core and version. Temporarily increase the log detail, reproduce the failure once, and save the relevant time window. Restore the previous log level afterward to avoid generating excessive logs.
6. Check the server listener and forwarding chain last
If you don’t manage the server, give the maintainer the client version, time of failure, error snippet, and test results from different networks. Don’t request or share an administrator password for troubleshooting. If you have access to the Linux server, check the listener, process logs, host firewall, and cloud inbound rules—in that order.
sudo ss -lntp
sudo ss -lnupThe first command checks TCP listeners; the second checks UDP listeners. Verify the actual protocol and port used by the configuration rather than expecting every node to listen on both TCP and UDP. If there’s a reverse proxy in front, it may listen on the public port while the core listens on a local internal port. That setup is normal.
- Check where it’s listening: Confirm whether the listener is bound to a loopback or public address and that the port matches the client. For container deployments, also check the port mapping and protocol.
- Check the relevant logs: Use the actual service name to inspect its status and recent logs. Make sure a configuration load failure hasn’t left an old process running. When you retest from the client, check for connection or handshake entries in the same time window.
- Check both firewall layers: Inspect the host firewall and cloud security group separately. Allow only the protocols and ports you need; don’t disable the entire firewall to troubleshoot.
- Check the rest of the forwarding path: If the entry point receives the request but returns 502 or 504, or the handshake fails, check the connection from the reverse proxy to the core, path matching, certificates, and upstream reachability.
What it means: the entry point received a request—check the rest of the forwarding path
If the entry point logs show a request at the time of failure, trace authentication, the reverse proxy, and outbound traffic next instead of randomly changing local listener ports. No entry in the logs doesn’t prove traffic never arrived; also check the log level and where the logs are written.
7. Retest under the same conditions and document the results
After each change, retest with the same node, destination, and test method. Increasing the timeout only gives the request longer to wait; it won’t fix an incorrect port or TLS setting. If small requests work but downloads or specific sites fail, narrow the issue down to the destination website, routing, DNS, or path MTU. Don’t reinstall the client right away.
- Useful details: Record the test time and time zone, client and core versions, network, failure stage, and most recent change.
- Minimum evidence: Save the startup result, local listener result, remote port test result, and relevant logs from one actual request.
- Redact before sharing: Remove subscription links, user IDs, access tokens, and node sharing details. Share the server address only in trusted communications where it’s needed to diagnose the issue.
- Stop making changes that aren’t helping: If the evidence points to the remote listener or server configuration, preserve the reproducible state and pass it to the maintainer instead of adding more local variables.
Troubleshooting is complete when requests get a stable response along the same path—not just when the latency number returns in the node list. If timeouts happen again, compare what changed against these notes; that’s usually more effective than trying every setting again.