For v2rayN users who have imported a node but can’t load websites, are seeing connection timeouts, or can’t start the core. Capture the full error chain from a failed request, then check local listening ports, traffic routing, DNS, the remote port, and the protocol handshake—in that order. This guide covers log level settings, common error messages, and Windows commands for local tests, so you don’t mistake every problem for a dead node.
1. Open the runtime log and reproduce the failure
v2rayN is a GUI client; the core it launches handles proxy connections. A client UI issue, a core startup failure, and a failed individual connection are three different problems. Before reviewing logs, note the selected node, core type, and time of the failure. Don’t mix errors from switching between nodes.
-
Note your current settings
From the main window, note the client version, the selected node’s protocol and transport, then open Settings → Parameter Settings to check the local listening port. Settings groups may differ between the desktop and classic interfaces; refer to the options shown in your version.
-
Enable diagnostic logging
In Settings → Parameter Settings, look for the core’s “Log level” setting; in some versions, it’s under “Core: Basic Settings.” With Xray, start with
info. If that doesn’t provide enough detail, temporarily switch todebug. Save your changes and restart the core to apply them. -
Reproduce the issue once
Expand the runtime information or log panel at the bottom of the main window and note the time. Pause batch latency tests, select a single node, and try loading the failing website once. Copy the logs from around that time—not just the last line.
-
Restore the log level
When you’re done troubleshooting, restore the level to
warningor its previous value. If file logging is enabled, check the file location and size as well. Diagnostic logs may include visited domains, local addresses, and outbound tags.
Common Xray log levels include debug, info, warning, error, and none. The level controls how much detail is recorded; it doesn’t change connection behavior. Setting it to error may hide useful connection details. Leaving debug on can generate a large volume of logs and expose more browsing metadata.
2. Follow the error chain: check the address, then the underlying cause
A log entry often wraps several layers of errors. The outer message may say a connection failed, the next layer may say no destination is available, and the innermost message may identify a refused connection or timeout. First identify which address appears in the error chain, then find the most specific system error. Don’t change protocols just because you see failed.
| Log clue | What it means | Next step |
|---|---|---|
127.0.0.1:10808 | A local loopback address and port, often used by an app connecting to the local proxy. | Check the listener and confirm the port configured in the app. |
dial tcp | A TCP connection is being attempted. | Check whether the address that follows belongs to the node server or the destination website. |
lookup、no such host | A problem occurred during DNS resolution. | Check the domain in the error, the DNS path, and the response. |
accepted | The core accepted an inbound request. | Check the corresponding outbound result; this doesn’t mean the remote connection succeeded. |
direct、proxy | Possibly an outbound tag in the current configuration. | Compare it with the routing configuration; tag names aren’t standardized. |
This simplified snippet illustrates the order in which to read a log; it isn’t from a real test. It shows a local TCP port refusing a connection. This message alone says nothing about the quality of the remote node.
dial tcp 127.0.0.1:10808: connectex: No connection could be made because the target machine actively refused it.Key point: the address tells you what to troubleshoot
If the error points to a loopback address, check the local listener first. If it points to the node server, check the remote port. Identify both ends of the connection before deciding whether to change node settings.
3. Common errors and how to fix them
The exact wording may vary between cores and operating systems. The examples below show common error messages. Include the surrounding context when matching them, especially the address, port, transport type, and certificate name. A warning that appears once while everything works doesn’t need an immediate configuration change; it’s worth investigating when it recurs and coincides with an actual failure.
Error: connection refused
Cause: The destination refused the connection. Common reasons include no service listening on the specified port or a firewall actively rejecting the connection.
Fix: Check the address first. For a local port, confirm the core is running. For a remote port, verify the server and port in your subscription and ask the server administrator to confirm that the service is listening. Retrying won’t replace checking the port.
Error: i/o timeout
Cause: A read or write operation didn’t complete before its deadline. This can happen while establishing a TCP connection, during the TLS handshake, or while transferring data.
Fix: Use dial, read, or write in the error to identify the stage. Keep the same node and test again on a different network. A timeout alone doesn’t mean the password is wrong, and simply increasing the timeout may not help.
Error: failed to handshake
Cause: The handshake failed, but this message is only a summary. The certificate, authentication, EOF, or timeout details that follow point to the specific cause.
Fix: Check the protocol, TLS, SNI, transport, and authentication settings against the server’s requirements. For REALITY, also verify the public key, shortId, serverName, and client support.
Error: bind: Only one usage of each socket address
Cause: On Windows, another listener is already using the local address and port. A duplicate app instance is a common cause.
Fix: Find and close the process holding the port, or choose a different local port. If you change the port, update the proxy address in your browser, terminal, and any apps configured manually.
Error: no such host
Cause: DNS resolution didn’t return a usable result. The domain may be misspelled, DNS may have returned that it doesn’t exist, or the lookup path may have a problem.
Fix: First determine whether the domain belongs to the node or the destination website. Check the spelling and subscription update, then review the relevant DNS settings. Don’t replace every domain with an IP address; that can break TLS hostname matching.
Error: x509: certificate has expired or is not yet valid
Cause: Certificate validity checks failed. The server certificate may have expired, or your device’s date and time may be wrong.
Fix: Sync your system clock first, then ask the server administrator to check certificate renewal and the certificate chain. Don’t disable certificate verification as a permanent fix.
Error: failed to find an available destination
Cause: This is usually a summary of a failed destination connection, not necessarily a DNS problem. The underlying error may indicate a refused connection, timeout, or unreachable address.
Fix: Expand the full error chain and find the most specific lookup, dial tcp, or system error. Follow the guidance for that error rather than changing DNS as soon as you see this message.
EOF and connection reset by peer don’t prove an authentication failure on their own. They mean the remote end closed or reset the connection, possibly because of mismatched transport settings, server policy, connection reuse, or an intermediate network device. If this happens occasionally only when closing a page and new requests work, monitor it. If it occurs at every handshake, compare the server logs.
4. Narrow down the cause, from local ports to remote settings
The examples below use Windows PowerShell and assume the local proxy is listening on 127.0.0.1:10808. This is an example port, not a value used by every version. First check the local listening port and inbound type under Settings → Parameter Settings. Don’t assume the system proxy, a dedicated HTTP port, and a mixed port are interchangeable.
Layer 1: Is a process listening locally?
Get-NetTCPConnection -LocalPort 10808 -State Listen
Test-NetConnection -ComputerName 127.0.0.1 -Port 10808The first command displays the listener and its OwningProcess. If there’s no match, it reports that no matching object was found. The second command’s TcpTestSucceeded : True means only that the local TCP port is reachable; it doesn’t confirm SOCKS negotiation or a working remote proxy. To identify the process, run Get-Process -Id followed by its process ID, so you don’t accidentally stop another service.
Layer 2: Send a request explicitly through the proxy
curl.exe --proxy socks5h://127.0.0.1:10808 --connect-timeout 5 --max-time 15 -I https://example.com/This command requires the port to support SOCKS5. socks5h sends the destination domain to the proxy to resolve, instead of having curl resolve it locally first. The core’s actual DNS behavior still depends on its DNS and routing settings. example.com is a test destination, not the node server. Receiving HTTP response headers means this request completed the relevant connection path; it doesn’t mean every website is working.
- The command immediately returns a connection error: Check the local port and listening process; there’s no need to change remote settings yet.
- The local port is reachable, but the request times out: Check the core logs from the same time for DNS, the node address, and handshake errors.
- The command succeeds, but the browser fails: Check the browser’s proxy settings, system proxy, and proxy bypass list.
- Only one website fails: Test another destination and check the domain’s routing, DNS results, and the destination service’s status.
Layer 3: Distinguish routing from remote connectivity
The system proxy controls how apps that honor it connect; routing rules control which outbound route the core uses for traffic it receives. To isolate the problem, temporarily switch to a routing mode that sends the test destination through the proxy outbound, then restore your original settings. To test the node’s port, set the computer name and port in Test-NetConnection to the actual values shown in the node details. A successful TCP test confirms only that the port is reachable; it doesn’t verify VLESS, VMess, or Trojan authentication or handshakes.
Key point: verify explicit proxy access before checking system proxy settings
If curl’s explicit proxy request succeeds but your browser still fails, leave the node settings unchanged and check the system proxy and browser settings first. This avoids introducing new variables when the remote connection is already working.
5. If the handshake fails, check the protocol and transport settings
Successfully importing a subscription only means the client read the configuration. It doesn’t mean the server is still reachable or that the current core supports every field. After updating, confirm that you’ve selected the updated entry. Don’t troubleshoot against a new subscription while still using an old node.
| Configuration | Check first | Common mistake |
|---|---|---|
| VMess | User ID, server-side authentication settings, local system time, and transport settings. | Changing authentication fields without confirming the server’s requirements. |
| VLESS + REALITY | User ID, public key, shortId, serverName, flow, and core support. | Copying the public key or flow setting from another node. |
| Trojan + TLS | Password, server address, port, SNI, and certificate chain. | Disabling certificate verification to hide a hostname or certificate problem. |
| WebSocket transport | Path, Host, TLS settings, and reverse proxy configuration. | Treating path capitalization or a trailing slash as irrelevant. |
| gRPC transport | serviceName, TLS settings, and HTTP/2 support in the reverse proxy. | Changing the node port without checking the reverse proxy. |
The transport and proxy protocol are separate layers: VLESS doesn’t automatically mean REALITY, and TLS isn’t the same as WebSocket. Use the full server configuration as your reference. Don’t switch a node to a different combination just because an option appears in the client’s menu. Change one field at a time, reproduce the same request, and record the result.
6. Common questions and what to check before sharing logs
Why can I run a latency test but still not load websites?
TCP latency reflects the connection to a particular port; it may not include protocol authentication or access to a website. Rerun the explicit proxy request above and compare it with the core logs from that time. A single latency result doesn’t verify the entire connection path.
Does a subscription update timeout mean the node is definitely broken?
Downloading a subscription and connecting to a node are separate requests. First check whether the subscription URL has expired under Subscription Groups, then confirm whether updates use a direct connection or the proxy. If updates use the proxy, you need a working node first. Don’t share the full subscription URL when posting logs.
Why does the browser work while command-line tools and games can’t connect?
Some apps don’t use the system proxy. For command-line tools, specify the proxy explicitly to test it; for other apps, check whether they support proxies. Before trying TUN, check permissions, routing, and DNS. Avoid changing both the connection method and node settings at once, or you won’t be able to compare results.
Why can’t I find the problem even with debug logging enabled?
Reduce background requests, keep one node and one destination, and reproduce the issue once. Save the full error chain and note the client, core, and operating system versions, as well as the time of the failure. If needed, ask the server administrator to check the server logs for the same time window.
When asking for help, keep the structure needed for troubleshooting but remove sensitive values. Don’t share usernames, subscription tokens, node credentials, or unnecessary browsing records. A screenshot showing only “timeout” usually doesn’t reveal which layer failed; a short, redacted error chain is more useful than a screenful of scrolling logs.
- Keep environment details: Client version, core version, operating system version, and whether the system proxy or TUN is enabled.
- Keep reproduction details: Time of failure, type of destination, whether it happens every time, and results on another network.
- Keep configuration structure: Protocol, transport, whether TLS or REALITY is enabled, and whether the error concerns a local or remote address.
- Remove secrets: Full subscription URLs, UUIDs, passwords, private keys, and query parameters containing tokens. You can also redact full server addresses that aren’t needed.
Finally, retest in the original order: the core starts successfully, the local port is reachable, the explicit proxy request gets a response, and your everyday apps connect as expected. Once all four checks pass, restore your usual routing and log level. This sequence makes it easier to verify results than changing DNS, ports, and protocols all at once.