This checklist is for anyone whose node tests time out, whose browser cannot load pages, or whose subscription updates fail. Check the system clock and subscription first, then local listeners, remote ports, and handshake settings. Record a verifiable result at each step. By the end, you can tell whether the client is not routing traffic, the network is unreachable, or the protocol settings do not match—without repeatedly reinstalling or changing several settings at once.
First, identify which kind of timeout you’re seeing
A timeout means an operation did not finish within the allotted time; it does not necessarily mean the node is down. Subscription updates, node tests, and browser requests take different paths. A subscription URL is usually an HTTPS endpoint; a node connection uses the node’s own address, port, and credentials; browser traffic also depends on the system proxy or TUN routing. Start by noting which operation failed so you know what to check next.
| Symptom | Check first | Does not necessarily mean |
|---|---|---|
| Subscription update times out | Subscription hostname resolution, endpoint reachability, and whether updates use the proxy | Every imported node is unavailable |
| Node test times out | Test type, remote port, handshake settings, and test target | The system proxy is definitely misconfigured |
| Test succeeds, but webpages won’t load | System proxy, app proxy settings, DNS, and routing rules | The server is definitely working or definitely down |
A TCP connection test only shows that a connection to the port can be established; it does not validate the UUID, password, or application data exchange. A real connection test covers more steps, but also depends on whether its test URL is reachable. Don’t interpret these two tests interchangeably. When troubleshooting, use one node, one target URL, and one test method; note when it fails and check the core logs. Don’t combine results from different tests into a single conclusion.
Step 1: Sync your system clock and check your subscription
TLS certificates have start and expiration dates. If your device clock is significantly off, a valid server certificate may appear to be not yet valid or expired. Some VMess authentication flows also depend on the time. A different displayed time zone is not necessarily a problem; what matters is whether the system’s actual time is correct.
-
Sync the clock
In Windows 11, open Settings → Time & language → Date & time, turn on Set time automatically, then select Sync now under Additional settings. If syncing fails, first check that your regular internet connection works; changing only the displayed hour manually won’t address the cause.
-
Check your plan
Check the subscription provider’s account page for the expiration date, remaining data, and service announcements. A subscription URL downloading successfully does not mean the account still has connection access; an active account does not guarantee that an old node address is still valid.
-
Update the subscription group
In v2rayN, open the Subscription Group menu and update the relevant group. If the interface offers Update subscription without proxy and Update subscription via proxy, choose according to your current network. Relying on a broken node to update its own subscription creates a “connect first to fix the connection” loop.
-
Select a node again
After the update succeeds, select a node in that group again and confirm that the core has loaded the new configuration. Check whether the server address or port has changed. Menu labels may vary slightly between versions; use the group update feature in your current version.
Step 2: Check local ports and where traffic enters
First confirm that the core starts successfully, then check whether your browser sends requests to it. An open v2rayN window does not mean the proxy core is listening. Go to Settings → Parameter Settings and check the local listening ports. Depending on the version, HTTP and SOCKS may use separate ports or a mixed port; use the actual settings and startup logs as your source of truth.
These numbers are examples for troubleshooting, not fixed settings for every node or measured speeds. The commands below check the local listener and its process in Windows PowerShell. If your port is not 10808, update the command first. No output means there is no matching TCP listener at that moment; check the core startup logs first.
Get-NetTCPConnection -State Listen -LocalPort 10808 |
Select-Object LocalAddress, LocalPort, OwningProcess
Get-NetTCPConnection -State Listen -LocalPort 10808 |
ForEach-Object { Get-Process -Id $_.OwningProcess }If another program owns the port, identify the process before closing the conflicting program or changing the local port. After changing the port, update the app’s proxy settings too. Once the listener is working, use the Windows-built-in curl.exe with an explicitly specified SOCKS proxy to test without relying on browser settings:
curl.exe --proxy socks5h://127.0.0.1:10808 --connect-timeout 5 --max-time 15 -I https://www.example.com/socks5hsends the target hostname through the SOCKS proxy, reducing interference from local target-name resolution. It does not bypass resolution problems with the node server address itself.- example.com is a public example website, not a node server address. If the target is unreachable, use an HTTPS site you know is working.
- An HTTP response means the request made it through the proxy chain. A status such as 403 also means a response was received, but does not mean the target allows access.
- If the explicit proxy test succeeds but the browser fails, check that the system proxy points to the same port and that the browser is not using separate proxy settings.
Step 3: Check DNS and the remote port, layer by layer
Once the local entry point is working, check the server address. DNS resolution failure and TCP connection failure happen at different stages. node.example.com below is a fictional node hostname; replace it with the actual server address from your subscription before running the command. Replace 443 with the actual server port too.
Resolve-DnsName node.example.com
Test-NetConnection node.example.com -Port 443 -InformationLevel Detailed| Result | Meaning | Next step |
|---|---|---|
| Hostname resolution failed | The connection has not reached the remote port yet | Check the address spelling, DNS reachability, and whether the hostname is still valid |
| TcpTestSucceeded is False | A TCP connection to this port could not be established from this network | Check the remote listener, firewall, network path, and whether the port is correct |
| TcpTestSucceeded is True | The TCP three-way handshake succeeded | Continue by checking TLS, transport, and protocol authentication |
A failed ping does not prove that a node is down; the server may not respond to ICMP. Conversely, a successful ping does not mean the service port is open. The TCP checks above apply only to nodes using TCP; they cannot determine whether a UDP transport works. If the hostname resolves to both IPv4 and IPv6, also check which address family the connection actually uses.
Takeaway: Change only one variable when switching networks
Use the same device, node, and port to test first on your usual network, then on a mobile hotspot. If only the usual network fails, focus on its network path and policies. If both fail, check the server status and configuration before switching protocols.
Check whether the local firewall blocks outbound connections from the current core process, especially if an upgrade changed the program path. On the server, check the cloud firewall or security group, the operating system firewall, and the actual listening port separately. Don’t disable every firewall as a long-term fix. A local proxy should usually listen only on the loopback address to avoid exposing an unauthenticated entry point to the LAN.
Step 4: Check TLS, transport, and authentication settings
If the remote port is reachable but the connection still fails, shift your focus from reachability to whether both sides are using the same protocol settings. VLESS and VMess are proxy protocols; TCP, WebSocket, and gRPC are transport options; TLS and REALITY provide transport security. Changing only the protocol name while keeping other old settings often leads to a different handshake error.
| Setting | What to check | Common pitfall |
|---|---|---|
| Protocol and authentication | VMess or VLESS, the UUID, and any other authentication settings required by the server | Assuming authentication must be correct just because the port is open |
| TLS serverName | The SNI name required by the server and the domain covered by its certificate | Setting the connection address, SNI, and HTTP Host to the same value by default |
| WebSocket | path, Host, and reverse-proxy forwarding rules | Forgetting the leading slash in a path or reusing an old path |
| gRPC | serviceName, TLS, and HTTP/2 support in the reverse proxy | Using a WebSocket path directly as the serviceName |
| REALITY | The server-specified serverName, public key, shortId, and supported flow | Using a regular TLS certificate test in place of REALITY authentication verification |
REALITY is part of the Xray ecosystem; this type of configuration cannot be used directly with the V2Fly core. On Android, v2rayNG uses the Xray core, while v2flyNG uses the V2Fly core. Before choosing, confirm that the protocol and specific fields are supported by your core version. For desktop v2rayN, check the core currently in use and its logs—not just the client name.
For nodes using regular TLS, you can inspect the certificate and TLS handshake in a Linux or macOS terminal with OpenSSL installed. Both domains below are fictional examples; replace them with the actual connection address and the SNI required by the server, respectively:
openssl s_client -connect node.example.com:443 -servername tls.example.com -verify_hostname tls.example.com -verify_return_error < /dev/null- This command does not verify VMess or VLESS authentication, a WebSocket path, or a gRPC service name.
- If certificate validation fails, check the system clock, hostname match, and certificate chain first. Don’t hide the problem by disabling certificate validation long term.
- REALITY requires its own matching parameters. A response from a regular TLS tool does not prove that a REALITY node is working.
- If the connection address is an IP, a separate domain may still be required for serverName. Follow the server configuration.
Step 5: Use the original log messages to pinpoint the failure
Restart the core, trigger one failed request, and capture the logs from around that time. Error text can vary by operating system and core version, so also check nearby lines for the connection address, target port, and outbound tag. The snippets below are common errors, not complete log lines produced by every environment.
Error: bind: address already in use
Cause: The local listening address and port are already in use, so the core could not bind to the entry point.
Fix: Identify the process with a port lookup command and resolve the conflict, then restart the core. If you change the port, update the system proxy and app settings too.
Error: no such host
Cause: A hostname could not be resolved. It may be the node hostname or the hostname of the requested destination.
Fix: Use the logs to identify the hostname that failed, then check its spelling and DNS path. Don’t mistake a failure to resolve the destination for a server outage.
Error: connect: connection refused
Cause: The connection was explicitly refused, often because no service is listening on the port or a firewall actively rejected it.
Fix: Check the port in your subscription. If you manage the server, check its listener and firewall; otherwise, send the provider a redacted report.
Error: i/o timeout
Cause: A connection or read/write operation timed out. This message alone cannot tell whether the issue is the network, handshake, or destination response.
Fix: Use the preceding log lines to identify the stage that timed out. Check the remote TCP port first, then the handshake settings, and retest on another network while changing only one variable.
Error: x509: certificate has expired or is not yet valid
Cause: Certificate validity checks failed. The device clock may be wrong, or the server certificate may actually have expired.
Fix: Sync the system clock first. If the error persists with the correct time, the server administrator should renew the certificate and check the certificate chain.
If you need more verbose logs, enable them only while reproducing the issue, then restore the previous level. Detailed logs may include destination hostnames and connection information, and generate additional disk writes. When asking for help publicly, include the time of the test, client and core versions, failure stage, and exact error text; don’t share the full configuration file.
Common questions and final checks
Why do my nodes still time out after a successful subscription update?
Downloading a subscription and connecting to a node use separate paths. First confirm that your account is active, then check that you selected a newly updated node. Test the remote port to distinguish an unreachable network from a handshake failure. Downloading a configuration does not mean it has been verified to work.
What if the test returns a result but my browser still can’t load pages?
First, use the explicit proxy command with curl.exe from this article to test the same destination. If it succeeds, check that the system proxy is enabled, the port matches, and the browser is not using a separate proxy. If only some sites fail, check their routing and DNS settings; there’s no need to replace every node right away.
Will increasing the timeout fix the problem?
Waiting longer helps only when a connection is slow but eventually completes. A wrong port, mismatched UUID, or incorrect certificate hostname won’t fix itself after a few more seconds. Identify the failure stage first, then decide whether to adjust the test timeout.
Where should I look if my connection drops only after enabling TUN?
Turn off TUN first and test the basic node connection with an explicit local SOCKS proxy. Once that works, check the permissions, route handling, and DNS settings required by TUN. Avoid repeatedly switching between TUN and the system proxy while also changing nodes; that makes the same failure harder to reproduce.
Takeaway: Recording the failure stage is more useful than saving a “timeout” screenshot
Record results in this order: system clock and account → local listener → hostname and port → TLS and transport → app traffic routing. The first step that clearly fails is where to focus next. After fixing it, retest from that step, then confirm that the browser can load pages.
After fixing the issue, restore any temporary log-level or test-setting changes and make sure the local entry point is still exposed only where needed. If you still can’t pinpoint the cause, see the site’s connection troubleshooting guide. For subscription update issues, see subscription management. When reporting a problem, list the checks you’ve already completed to reduce follow-up questions and avoid repeating unrelated changes.