Understanding Xray Core Logs: Common Errors and How to Troubleshoot

Identify the log source first, then find where the request stalls

v2rayN is a graphical client; Xray is the core that actually handles proxy traffic. Subscription download failures, startup issues in the interface, and outbound proxy failures may appear in different logs. Seeing “Service started” only confirms that startup reached a certain point. It doesn't prove that node authentication succeeded or that the destination site is reachable.

Check the startup output for the core name and version, then confirm which core the current node actually uses. v2rayNG uses Xray; v2flyNG uses V2Fly, and their supported fields aren't interchangeable. For VLESS and REALITY issues in particular, check the core that's running—not just the client package version.

This is a guide to the order of investigation, not a claim that every connection has six distinct stages. Some protocols combine authentication and the handshake, and the destination domain may be resolved on the server. When investigating an error, ask whether its address is the local listener, the node, or the final destination. The same port—443—can point to very different causes depending on where it appears.

Enable logging and capture a reproducible request

warning is usually enough for everyday use. To observe connection activity, start with info; switch briefly to debug if you need more detail. Xray's loglevel accepts debug, info, warning, error, and none. This controls error log verbosity; access logs are also affected by the access setting. Raising the log level won't fix a connection.

1. Check the core

   In v2rayN, check the startup output under runtime information on the main screen. Note the name and version of the core actually launched. If there's no core startup entry, resolve the startup failure first rather than troubleshooting the remote node.

2. Change the log level

   In v2rayN, go to “Settings” → “Parameter Settings,” find “Log level,” and set it to info. In v2rayNG, open the side menu and go to “Settings” → “Log level.” Menu groups and labels may vary by version. If you can't find the option, check the client version rather than applying settings for a different core.

3. Reproduce the issue

   Save your changes and restart the proxy service to apply them. Close pages that refresh continuously, open one fixed test address, note when you do it, and keep about 10 seconds of logs from before and after that time.

4. Restore the log level

   Once you find the cause, set the level back to warning. Before sharing logs, remove account identifiers, subscription URLs, node addresses, and visited domains. Keep the timestamps, protocol names, ports, and error chain intact.

If you use a custom Xray configuration, check the log snippet below. It's one configuration field, not a complete, runnable config. When the client generates the configuration, change the setting through the client; direct edits to temporary files may be overwritten on the next start.

{
  "log": {
    "loglevel": "info"
  }
}

failed to dial: trace the error chain to the actual failure

failed to dial means an attempt to dial or establish a connection failed; it's usually just a wrapper from a higher layer. The details that follow—such as lookup, connection refused, or i/o timeout—are more likely to reveal the cause. Read the full nested error before changing DNS, ports, or routing. Don't re-enter the UUID just because you see “dial.”

For example, if the error explicitly says a TCP connection to the node on port 443 timed out, there's not enough evidence yet to blame VLESS user authentication. Conversely, if the connection to the node succeeded but reading from the destination failed, checking only local connectivity to the node won't help. Always consider the address, stage, and timing together.

TLS handshake and invalid user: troubleshoot security and authentication separately

TLS handshake errors usually occur after a connection enters security negotiation, but that doesn't necessarily mean there's a certificate problem. For a standard TLS node, check serverName, the certificate chain, system time, and transport settings. For VLESS + REALITY, also check the public key, shortId, serverName, and server configuration. These are different setups; “disable verification” isn't a universal fix.

invalid user is more likely to provide a direct clue in server-side inbound authentication logs; the exact wording varies by protocol and version. The client may show only EOF or a closed connection. If you can access the server, align the two logs by time and check that the UUID matches, the user has been loaded, and the port maps to the expected inbound. For VMess, also check the system time; don't carry over VMess's alterId setting to VLESS.

• VLESS + TLS: Check the UUID, transport type, port, serverName, and any flow required by the server. For WebSocket, also verify the path and Host; TCP node settings aren't a substitute.
• VLESS + REALITY: Check the UUID, the public key for the corresponding server, shortId, serverName, fingerprint, and flow. Field names can differ between clients, so compare them against the same set of node parameters.
• System time: On Windows, go to “Settings” → “Time & language” → “Date & time” and sync the clock. On Android, search for “Date & time” in system Settings and enable automatic time. Menu groups may vary by manufacturer.

context canceled: first check whether the request was simply canceled

context canceled means the context associated with an operation was canceled. Closing a tab, a browser opening a connection and then abandoning it, switching nodes, or restarting the core can all produce this message. It doesn't mean the node is necessarily down, and it doesn't by itself prove a DNS or certificate problem.

Local ports and routing: confirm the request is actually reaching the proxy

If address already in use or Windows' Only one usage of each socket address appears right after the core starts, investigate a local listener conflict first. Make sure another client instance isn't still running, then check which process has the port open. If you change the proxy port, update the browser's manual proxy settings and the system proxy too—not just one setting in the client.

The example below uses local port 10808 on Windows. These commands only check which process is using the port; don't terminate another program's PID without confirming what it is. Ports aren't fixed defaults, so replace this with the port your configuration actually listens on.

netstat -ano | findstr :10808

If the port provides a SOCKS inbound, use the command below to send a test request explicitly through the proxy. On Windows, curl.exe avoids cases where the terminal treats curl as an alias. socks5h sends the destination domain to the proxy to resolve instead of resolving it locally with curl. If the inbound provides only an HTTP proxy, use the appropriate HTTP proxy option; don't copy the SOCKS command.

curl.exe --proxy socks5h://127.0.0.1:10808 --connect-timeout 10 --max-time 20 -I https://example.com/

• Connection refused locally: Confirm the proxy service is running, the listening port is correct, and the inbound protocol matches. The request hasn't reached the remote node yet.
• Request reaches the proxy but uses the wrong outbound: Check the routing tag and matching rule. If the destination is routed directly, the page may not load even when the node itself is working.
• Command succeeds but the browser fails: Compare the browser's actual proxy settings, extension controls, separate DNS settings, and the test command's resolution path.
• Only some domains fail: Keep one working and one failing example, then compare domain rules, resolution results, and outbounds instead of replacing the entire configuration right away.

Keep useful troubleshooting notes: change one variable at a time

Useful troubleshooting notes don't need thousands of log lines. The core version, time of failure, how the request was made, and one complete error chain are more helpful than “it won't connect.” If you change DNS, flow, port, and transport all at once, even a successful fix won't tell you what worked—and the next failure means starting over.

1. Describe your setup: Operating system, client version, actual core version, and whether you're using the system proxy, an app's manual proxy, or TUN.
2. State what should happen: For example, “The request should enter through SOCKS 10808, then reach the test address through the specified VLESS outbound”—not just “connected.”
3. Keep the context: Include the startup completion entry, the time you made the request, and about 10 seconds of logs from before and after. Preserve the full nested error, not just its last line.
4. Record each change: Change one setting per test round, restart, and repeat the same test. If it doesn't help, restore the original value before trying the next change.
5. Wrap up: Restore the usual log level and confirm that both the browser and test command behave as expected. For more detailed basics, see the client setup guide.

The key to reading Xray logs is finding where the request fails: if the local listener isn't running, fix that first; if the node address won't resolve, investigate DNS; if TCP connects but the handshake fails, check security and transport settings; if the failure comes after authentication, look at access to the destination. Putting the error back into the request flow is more reliable than repeatedly tweaking settings based on one keyword.