When a webpage won’t load, first check whether the local listener started successfully, then whether the request reached the core, and finally distinguish DNS resolution, remote connections, and protocol handshakes. Using v2rayN and the Xray core on Windows, this guide covers port-check commands, common errors, and a one-request reproduction workflow. It’s for users who have already imported a node and need to identify which layer is failing.
1. Client Messages vs. Core Logs
v2rayN is the client that manages connections; Xray is the core that handles them. Subscription download failures and errors saving settings may occur in the client, while listener ports, routing, connections to servers, and TLS handshakes are primarily reported by the core. A running client doesn’t mean the core is listening successfully, and a node in the list isn’t necessarily able to connect.
Before troubleshooting, note the versions of both v2rayN and Xray. Find the client version under Help → About, and record the Xray version from the core’s startup output. Menu layouts vary between desktop versions. This guide refers to settings under Settings → Parameter Settings and doesn’t assume a default port is the same across all versions.
Use this chain to narrow down the problem in reverse: if the local connection is refused, don’t start by changing the node password. If a dial timeout appears after the node address, don’t focus only on browser settings. A certificate error means processing reached TLS validation, but doesn’t mean proxy protocol authentication succeeded.
2. Log Levels and How to Read an Entry
Common Xray error log levels are debug, info, warning, and error. none disables this type of logging. At warning, lower-level info and debug messages usually won’t appear. Access logs are a separate type of record and shouldn’t be confused with info-level error logs.
| Level | Purpose | When to use it |
|---|---|---|
| debug | Inspect connection handling in more detail | Enable briefly while reproducing the issue |
| info | Confirm general events such as startup and connection handling | A good starting point for troubleshooting |
| warning | Check abnormal connections and potential configuration issues | Assess impact alongside the affected request |
| error | Identify more serious execution errors | First check whether startup or listening is affected |
The access log below is a simplified illustration, not a real test result. Log date formats, connection IDs, and outbound tags vary by core version and generated configuration. Bracketed tags are configuration names; their names alone don’t prove that routing is correct.
2026/10/03 10:20:31 from tcp:127.0.0.1:52134 accepted tcp:example.com:443 [socks -> proxy]127.0.0.1:52134is the local source of the connection. 52134 is usually an ephemeral port, not the proxy listening port to enter in your browser.example.com:443is the destination for this request. Distinguish the destination website from the node server address when troubleshooting.acceptedmeans the inbound request was received. It doesn’t prove that the remote connection succeeded or that the webpage finished loading.- If a connection ID is present, follow the entries with that ID to trace the context. Otherwise, correlate nearby entries by time and destination address.
Bottom line: Find the same request, then read down to the root cause
For a failed request, keep about 10–20 surrounding log lines and follow the error chain to the final system or TLS error. A screenshot showing only the outermost “failed to process” message usually isn’t enough to know which setting to change.
3. Port Conflicts: Did the Core Start?
If the core exits right after startup or keeps printing startup messages, search for bind and address already in use. A port conflict occurs on your computer; changing subscriptions or switching remote nodes usually won’t fix it. The English snippets below are common error keywords; actual output may include several layers of error prefixes.
Error: address already in use
Cause: Another process is already using the local address and port the core is trying to listen on.
Fix: Identify the process using the port and close any duplicate client instances. If both programs need to run at once, assign them different listening ports.
Error: Only one usage of each socket address
Cause: Windows reported a socket binding conflict, often because an old core process is still running.
Fix: Check which application owns the process in Task Manager, close it, and restart v2rayN. Don’t terminate unfamiliar system processes.
Go to Settings → Parameter Settings and check the local listening port. If the interface shows 10808, run the following two commands in a Windows terminal. In the second command, 4321 is only an example PID from the last column of the first command’s output; replace it with the actual number.
netstat -ano -p tcp | findstr ":10808"
tasklist /FI "PID eq 4321"Check the local address column and the LISTENING state. A search result containing 10808 alone doesn’t prove that the port is in use. If another process is still listening after you close the client, identify which process owns it. Once the port is free, restart the core and check whether the binding error returns.
4. Timeouts and Refused Connections: DNS or Remote Network?
A “timeout” only means a stage didn’t complete within the allowed time; it doesn’t automatically mean the node is down. First check whether the error refers to a local port, the node server, or the destination website. Then determine whether it occurred during DNS resolution, TCP dialing, or data transfer over an established connection.
Error: lookup … no such host
Cause: A DNS lookup didn’t return a usable result. The name could belong to the node server or the destination website.
Fix: Check the domain in the log for typos, then review the DNS configuration used for that lookup. A domain resolving in your browser doesn’t rule out a DNS issue in the core.
Error: dial tcp … i/o timeout
Cause: The TCP connection attempt didn’t complete in time. Possible causes include an unresponsive server, packet loss, a firewall, or address selection.
Fix: Check the node address and port. Compare results using a different network or another working node, changing only one variable at a time. Note whether failures occur with the same server only.
Error: connection refused
Cause: The connection was explicitly refused, often because no service is listening on that port or a network device actively rejected it.
Fix: If the destination is 127.0.0.1, check the local listener. If it’s a node server, verify the remote port and ask the service provider to confirm that the service is running.
On Windows, use the command below to check whether the node’s TCP port is reachable. The domain shown is an example; replace it with the actual server address in your node configuration, and use the matching port. This tests TCP connectivity from your current network, not the full proxy connection.
Test-NetConnection -ComputerName node.example.com -Port 443TcpTestSucceeded : Trueonly confirms that this TCP connection succeeded. It doesn’t validate the UUID, TLS, REALITY, or transport configuration.- If the result is False, compare it with a test to the same port over another network. One failed test doesn’t identify which hop is blocking the connection.
- A successful lookup of the node address doesn’t mean DNS for the destination website is working. They may use different resolution paths.
- Speed tests and webpage requests may use different destinations and routes. Use the logs for the webpage that failed.
5. Handshake Failures: Check TLS and Node Settings
If TCP is reachable but the connection still fails, check the handshake stage. VLESS and VMess are proxy protocols, TLS is part of secure transport, and WebSocket and gRPC are transport methods. These settings depend on one another but aren’t interchangeable. Choosing the right protocol and port is only part of the configuration.
Error: x509: certificate has expired or is not yet valid
Cause: The certificate validity period doesn’t match the current time. The certificate may have expired, or the device’s clock may be wrong.
Fix: First sync the time under Windows Settings → Time & language → Date & time. If the time is correct and the error persists, ask the server administrator to check the certificate’s validity period.
Error: x509: certificate is valid for …, not …
Cause: The server name used for verification doesn’t match a domain covered by the certificate.
Fix: Compare the TLS server name or serverName with the service provider’s configuration. Don’t enter the node’s IP as the certificate domain without confirming it’s correct.
Error: websocket: bad handshake
Cause: The WebSocket upgrade request didn’t receive the expected response. Common causes include a mismatched path, Host header, or reverse proxy configuration.
Fix: Check the WebSocket path, Host, TLS setting, and port one by one. Preserve the path’s capitalization and slashes; changing only the UUID won’t fix a mismatch.
If the only errors are EOF or connection reset by peer, you can conclude only that the connection ended early—not that the password is wrong. The server closing the connection, incorrect proxy protocol settings, or a reset somewhere along the network path can all produce similar messages. Check the full configuration, then compare the same node over another network.
- Check the server address, port, protocol, and user ID. When editing manually, don’t apply VLESS settings to a VMess node.
- Check the TLS server name and transport settings. The WebSocket Host and TLS serverName are separate fields; don’t use one in place of the other.
- For REALITY, check the public key, shortId, serverName, and other parameters against the original configuration. Don’t troubleshoot it as a standard certificate error.
- Re-import a valid node configuration from the service provider first, then compare settings one by one. This avoids losing track of changes after repeated manual edits.
Bottom line: Check handshake settings before disabling verification
If the certificate name or validity period is wrong, fix the time, serverName, or server-side certificate first. Disabling certificate verification hides the real issue and shouldn’t be left on as a routine setting.
6. Reproduce the Issue with a Single Request
One of the least effective troubleshooting approaches is to change DNS, routing, nodes, and TUN settings all at once. Even if the connection starts working afterward, you won’t know which change fixed it. In each round below, use one node, one destination, and one connection method so you can compare results.
-
Record the current setup
Note the client and core versions, current node, routing mode, local port, and whether TUN is enabled. Keep the original configuration so you have a baseline to restore during troubleshooting.
-
Adjust the log level
Go to Settings → Parameter Settings, find Log level, and temporarily set it to info. If there still isn’t enough detail, switch to debug. Save the setting, restart the core, and confirm the startup log has refreshed.
-
Use a single entry point
Turn off TUN first. In the main window, select System Proxy → Automatically configure system proxy, then test with a browser that follows the system proxy settings. If testing a specific proxy port, don’t mix those results with automatic proxy handling.
-
Reproduce the issue once
Turn off automatic page refresh and background downloads. Note the current time, then visit the failing address once. Copy the startup, request, and error entries around that time—not just the final line.
-
Change one variable
Change only the node or the network, then visit the same address again. Once it works, restore the original log level and check that the system proxy and TUN settings are back as expected.
To compare results without relying on the browser’s proxy settings, use the command below. It assumes that 10808 is the active SOCKS listening port and waits up to 15 seconds; if your port is different, update the command first. socks5h sends the destination domain to the proxy for resolution but doesn’t determine which DNS strategy the core uses internally.
curl.exe --proxy socks5h://127.0.0.1:10808 --max-time 15 --head https://example.com/An HTTP status code means the request received an HTTP response—even 403 or 405 should be treated differently from a connection timeout. If this command succeeds but the browser fails, check the browser’s own proxy settings, extensions, and system proxy handling first. If both fail at the same stage, continue tracing the core’s error chain.
7. Common Questions and Sharing Logs Safely
Why does the node show a latency value if webpages still won’t load?
First check whether the test measured TCP latency or tested a full connection. A TCP connection doesn’t verify the complete proxy path. In the main window, select the node, right-click, and check Test server real connection latency. Then use the failing webpage’s logs to check the destination, route, and handshake stage.
What if there are no errors and no request logs at all?
First check the log level and whether access logging is enabled. Reproduce the issue with a curl command targeting a specific SOCKS port, then compare it with the browser. If the browser is the only one not reaching the core, check System Proxy → Automatically configure system proxy and the browser’s own proxy settings.
Should I troubleshoot a subscription update timeout like a node handshake error?
First determine whether the subscription download or the node connection failed. Under Subscription groups, check the subscription URL and current update method. If the subscription needs a proxy, confirm that a node is already working before selecting update through proxy. A subscription download error doesn’t prove that every node in the list is down.
Should I switch nodes as soon as I see an occasional EOF in the logs?
Not based on that line alone. First check whether the page actually failed at the same time. Closing a page or canceling a request can also produce a connection-ended message. Compare node settings and network conditions only if the error consistently matches the affected request.
What should I remove before sharing logs for troubleshooting?
Remove the full subscription URL, access tokens, UUIDs, passwords, private keys, and personal browsing records. Keep the error keywords, event order, protocol and transport type, port, and a consistently substituted hostname. Don’t post the full original configuration publicly.
A useful issue report can be brief: include the versions, operating system, connection method, type of destination that failed, reproduction time, and whether changing the node or network made a difference. Preserving the error chain matters more than taking a large screenshot. If the port isn’t listening, fix local startup; if the remote connection fails, check network reachability; if it reaches the handshake stage, verify the settings. Following this order keeps troubleshooting from looping back to the start.