For users whose node is selected but websites won't load, or whose core exits right after startup. First distinguish client logs from core logs, then check errors in this order: local listener, node connection, TLS handshake, and destination access. This guide maps common error messages, provides Windows port-check commands, and shows how to capture a single failure—so you can narrow down the cause instead of changing every setting.
Identify which layer the log comes from
v2rayN is the client interface; the selected core handles the actual connections. Subscription download failures, interface issues, and core startup failures may appear in client messages. Node connections, DNS lookups, and outbound handshakes are usually logged by the core. These happen at different stages: a successful subscription update does not mean the proxy connection works, and one failed speed test does not prove that all apps are offline.
This guide focuses on v2rayN running the Xray core. Check the main window's messages or log area to confirm the active core, then open Settings → Parameter Settings and review the logging options. Menu names may differ across desktop interfaces and versions; use the Log Level field shown in your version. Do not paste the Xray fields below into the subscription URL field.
Follow this chain through the logs: Did the app send the request to the local port? Did routing select the expected outbound? Did the core connect to the node? Did the node complete the protocol handshake? The next error is useful for diagnosis only after the previous step is confirmed. With TUN enabled, also check the virtual adapter and permissions; the node connection and handshake checks still apply.
Log levels and one-time reproduction: capture a readable sample
Xray commonly uses loglevel values such as debug, info, warning, error, and none. More detail provides connection context, but may also log destinations you access. Use a conservative level day to day. For troubleshooting, temporarily switch to info; if that is not enough, use debug briefly.
| Level or log | Useful for | Does not prove |
|---|---|---|
debug | Details about parsing, dialing, and handshakes | More information does not mean more failures |
info | Connection flow and general runtime events | No error does not mean the page loaded completely |
warning | Connection issues worth investigating | One warning does not mean the entire core has stopped |
error | Serious errors and some startup issues | Does not capture every failed request |
| Access logs | Request destination, inbound, and outbound tags | accepted does not guarantee a successful remote handshake |
Access logs and error logs are different, and whether access logs are emitted depends on the configuration. Do not enable every log just to see “accepted.” Capturing one request is usually more useful than copying hundreds of unrelated lines.
Record your environment
Note the client version shown under Help → About, and record the core version from its startup messages. If your interface does not have that menu, note the version information actually displayed in the window.
Adjust the log level
Open Settings → Parameter Settings, find Log Level, and temporarily set it to info. Save, restart the current core, and confirm the new setting took effect.
Limit variables
Use one node, one browser, and one destination page. Pause batch speed tests and subscription updates. Keep the startup errors, then clear old entries from the displayed log; do not delete log files you still need for comparison.
Reproduce once
Note the request time, refresh the page once, and collect the full error chain around that time. If the log includes connection IDs, follow the same ID rather than assuming adjacent lines belong together.
Restore your settings
After troubleshooting, restore the original log level. Before sharing logs, redact subscription URLs, authentication parameters, node addresses, and visited domains. Include only the necessary error messages and port roles.
connection refused and ports in use: find out what's refusing the connection
connection refused means a connection attempt was actively rejected. Common causes include no service listening on the port or a network device rejecting the connection. This differs from a timeout. The key is the destination address in the error: 127.0.0.1 points to your local machine; a node address points to the node connection; a remote destination may indicate a failed direct outbound connection.
Error: dial tcp 127.0.0.1:10808: connect: connection refused
Cause: The caller could not reach an available listener on local port 10808. The core may have exited, the port may have changed, or the proxy address may be incorrect.
Fix: Check the core startup messages first, then verify the local listening port under Settings → Parameter Settings. Make sure the app uses the correct address, port, and proxy type.
Error: bind: address already in use
Cause: Another process is already using the address and port the core is trying to listen on. Windows may also report, “Only one usage of each socket address is normally permitted.”
Fix: Identify the process listening on the port, close any duplicate client instance, or change the local port and update the app's proxy settings. Do not terminate unknown system processes.
The port numbers below illustrate their roles; they are not defaults for every version. 10808 is an example local listening port, and 443 is an example node port. Always check the values in your current configuration.
In Windows PowerShell, check the listener first, then use the returned PID to find the process. If the first command returns no listener, check whether the core started successfully before changing the node's TLS settings.
Get-NetTCPConnection -LocalPort 10808 -State Listen |
Select-Object LocalAddress, LocalPort, OwningProcess
Get-NetTCPConnection -LocalPort 10808 -State Listen |
ForEach-Object { Get-Process -Id $_.OwningProcess }These commands check a local port; they do not verify that a node is usable. A listener bound to 127.0.0.1 accepts local connections only. Do not expose it to your local network just for troubleshooting.
i/o timeout: distinguish dial timeouts from read timeouts
i/o timeout means an operation exceeded its wait time. Read it alongside the preceding context, such as dial tcp, read tcp, or a DNS lookup. A dial timeout means the connection was never established; a read timeout means the program did not receive a timely response while waiting for data. Check different things for each.
Error: dial tcp 192.0.2.10:443: i/o timeout
Cause: The connection to the node's port did not complete in time. An incorrect address, an unreachable service, packet loss along the route, or a firewall silently dropping traffic can all cause this. The address is for documentation only and must not be used for real connectivity tests.
Fix: Verify the node address and port in your subscription, then compare using a different network or a known-working node. Do not change all transport settings based on a single timeout.
Error: read tcp …: i/o timeout
Cause: A connection timed out while waiting to read data. This may involve a handshake, a remote response, or an idle connection; it does not automatically mean the node port is unreachable.
Fix: Check the handshake entries for the same connection. Determine whether the timeout occurred before the node handshake or after the request reached its destination, then verify the node configuration or destination site accordingly.
- Every node times out: Check your local network, proxy loops, firewall, and system clock first. Also make sure batch speed tests are not causing congestion.
- Only one node times out: Keep the network unchanged and compare other nodes. Focus on the affected node's address, port, and service status.
- Only one site times out: Check which outbound the domain matched and whether the destination itself is reachable. Do not reset the entire subscription.
A successful TCP port test only proves that a TCP connection was established at that moment; it does not verify the VMess, VLESS, or TLS handshake. Conversely, a lack of ICMP response alone does not prove that the proxy service is unavailable.
TLS handshake failures: check certificates, names, and transport settings separately
A node port can be reachable while the TLS handshake still fails. First determine whether the failure is between the client and the node, or between the browser and the destination site. A certificate warning in the browser is not usually an Xray node handshake log; use the core error chain for the same connection.
Error: x509: certificate has expired or is not yet valid
Cause: The certificate validity period does not match the current system time. The node certificate may have expired, or the local date or time zone may be incorrect.
Fix: In Windows, open Settings → Time & language → Date & time, check the clock, and sync it. If the time is correct, ask the node administrator to check the certificate.
Error: x509: certificate signed by unknown authority
Cause: The certificate chain cannot be verified against a root certificate trusted by the current environment. Possible causes include an incomplete server certificate chain, a self-signed certificate, or TLS inspection on the network.
Fix: Verify the node source, certificate deployment, and system trust environment. Do not treat disabling certificate verification as a routine fix.
Error: remote error: tls: handshake failure
Cause: The remote server aborted the TLS handshake. An SNI mismatch, incompatible TLS settings, or server-side policy could be responsible; this message alone does not identify which one.
Fix: Compare the server name and transport settings provided for the node, update the subscription, and reconnect. Check server logs to confirm why the connection was rejected.
In the node editor, check the server name for serverName, the TLS toggle, and the selected transport. WebSocket Host and path are separate from TLS SNI; do not set every field to the same value just because they contain a domain name. The gRPC service name must also match the server configuration.
DNS, EOF, and routing tags: add the missing context
For DNS errors, first distinguish a failure to resolve the node's domain from a failure to resolve the destination. The former may prevent the proxy connection from being established at all; the latter may affect only certain sites. With domain rules, IP rules, and different DNS outbounds, resolution may happen at different points. Do not assume every DNS error can be fixed by changing Windows network adapter settings.
Error: no such host
Cause: The domain lookup returned no usable host. The domain may be misspelled or inactive, or the resolver may have returned a negative result.
Fix: First determine whether the failed domain belongs to the node or the destination. Then check the spelling, DNS server, and DNS outbound. Do not permanently replace every domain with an IP address.
Error: unexpected EOF
Cause: The remote side closed the connection before the program received all the expected data. A protocol mismatch, faulty forwarding configuration, or remote disconnect may be responsible.
Fix: Identify whether the disconnect happened during TLS, the proxy protocol, or the destination response. Check the transport method against the server configuration; this error alone does not prove that the authentication parameters are wrong.
The simplified access log below is an example, not a real speed test. http is an inbound tag, and proxy is an outbound tag; names depend on the configuration. accepted means the request was received and handled. It does not mean the node completed authentication or the destination page responded.
from 127.0.0.1:52134 accepted tcp:example.com:443 [http -> proxy]- If a request expected to use the proxy shows
direct, check the order of routing rules, domain matching, and the currently selected routing configuration. - If you see
block, check whether a blocking rule matched. This is not a node connection failure. - No matching log entry when reproducing the request? Check whether access logging is enabled, then verify that the browser uses the system proxy or that the app's traffic is routed through TUN.
- If requests are interleaved, match them by timestamp, destination, and connection ID. Do not attribute an error from a background request to the page you are testing.
Common questions and what to include in a troubleshooting report
The log keeps filling with warnings. Does that mean the node is broken?
Pause batch speed tests and reproduce one real request. If the page works and the warnings are for canceled background requests, do not switch nodes based on the warning count alone. If the same request keeps failing, capture the full error chain before drawing conclusions.
The subscription updates successfully. Why can't the proxy connect?
A subscription update only downloads configuration data. Return to the main window and confirm that a node in the group is selected, then check whether the core started successfully. Next, verify the local listener and node handshake logs; a successful subscription update guarantees neither.
The page won't load, but there are no errors in the log. What should I do?
First check that you are viewing the right log area and that the log level is appropriate. Make one request in the browser and check which port the system proxy points to. With TUN, check adapter and permission messages. If the request never reaches the core, there will be no corresponding outbound error.
Do I need to send someone the entire log file?
Usually, start with the startup messages, a small section of context around the reproduction time, the client and core versions, and whether TUN is enabled. Redact authentication parameters, full subscription URLs, and personal destinations. Check screenshots for node names and addresses in the window, too.
A useful report includes your operating system, client and core versions, whether the issue affects one node or all nodes, the exact time of the error, and the single-variable tests you have already tried. For example, “Local port 10808 is listening; the same node still fails during TLS after switching networks” is more actionable than “The software doesn't work.”
- First, startup: Rule out a core crash, configuration parsing errors, and port conflicts.
- Next, connection: Distinguish connection refusals, dial timeouts, and DNS failures.
- Then, handshake: Check the system clock, certificate, server name, and transport settings.
- Finally, destination: Use outbound tags and destination responses to identify routing or site-specific issues.