How to Read V2Ray Logs: Common Errors and How to Diagnose Them

1. Find the Right Logs: Separate Client Messages from Core Errors

v2rayN is a desktop GUI client; the selected core handles connections. Subscription updates, speed tests, and system proxy notices in the client may appear near Xray connection logs, but they're different types of events. Before troubleshooting, note the selected node, core, proxy inbound, and time of the operation. Interpret configuration fields as Xray settings only when you've confirmed the output came from Xray. A client name containing V2Ray doesn't guarantee it uses a particular core.

On desktop, start by checking startup output in the log or information area of the v2rayN main window, then look for log-related options under Settings → Parameter Settings. Option names may vary between layouts, so use what the current client displays. On Android, v2rayNG uses the Xray core, while v2flyNG uses the V2Fly core. Check logs through each app's own log screen; don't assume another client's configuration paths apply.

1. Check startup output first: Confirm that the configuration loaded, rule resources were found, and local ports are listening. If startup has already failed, hold off on testing remote websites.
2. Narrow down the test: Note the current time, stop repeated speed tests and background requests, then make one request you can reproduce reliably.
3. Keep the context: Copy the relevant lines around the first failure. If the logs include a connection ID, follow that same ID instead of mixing together interleaved connections.
4. Follow the full error chain: When you see nested failed to messages, read through to the underlying cause rather than copying only the outermost message.

2. Log Levels and Entries: Check the Time, Then the Connection Stage

Common Xray error log levels are debug, info, warning, and error. The none setting disables the corresponding log output. For troubleshooting, temporarily raise the level to info, then use debug briefly if you still need more detail. Restore the original setting afterward to avoid logging connection details for too long. Access logs and error logs serve different purposes; raising the error log level does not enable access logging.

2026/11/03 10:15:20 [Info] [123456789] proxy/socks: TCP Connect request to tcp:example.com:443

This is a redacted format example, not a result measured by this site. The timestamp helps correlate actions, [Info] is the level, the number may help track the same connection, proxy/socks identifies the module, and the final address is the destination associated with the message. The exact format varies by core and output settings; not every line will have the same fields.

Follow this chain one stage at a time. A record showing the local inbound received a request proves only that the app passed it to the core. A route selecting an outbound doesn't prove the remote handshake succeeded. In access logs, accepted usually means the request was accepted for processing, not that the webpage finished loading. EOF or context canceled can also result from a browser canceling a request; consider whether the failure happens every time, at what stage, and in what context.

• Stops on startup: Check configuration syntax, listening ports, resource files, and directory permissions first.
• Inbound seen, expected outbound missing: Check the matched routing tag, direct-connection rules, and default outbound.
• Dial starts, then fails: Identify whether the issue is DNS resolution, TCP connection, TLS handshake, or protocol parameters.

3. Timeouts and Connection Refused: Don't Stop at “timeout”

First determine whether the address in the error is the node server or the website you're trying to reach. If a proxy outbound can't connect to the server, check the node address and port. If a direct outbound can't reach the destination, check the direct network path or routing rules. When a hostname has multiple address records, check whether the connection attempt used IPv4 or IPv6 so one unreachable path isn't mistaken for a general outage.

On Windows, use the command below to test TCP reachability. The domain and port are examples; replace them with the address and port of a node you're authorized to use. Run the test on a network where it's permitted. The result covers only the TCP layer; it doesn't validate VMess, VLESS, or TLS parameters.

Test-NetConnection -ComputerName example.com -Port 443

• TCP test fails too: Check whether the address is outdated, the port is correct, the current network restricts connections, and the server is listening properly.
• TCP succeeds but the core fails: Investigate the handshake, transport, authentication parameters, and corresponding server logs instead of assuming the node is working.
• Only some websites fail: Compare the outbound, resolution result, and destination type for those requests. Start by checking for routing differences.

4. Certificate Verification Errors: Check the Time, Name, and Trust Chain

A TLS error means the connection reached the corresponding handshake stage, but different certificate errors call for different fixes. With standard TLS certificate verification, the server address and the serverName used to verify the certificate name can differ, but must match the server's deployment. Don't enter an arbitrary reachable domain in this field or copy settings for other security modes into a TLS configuration.

If the system date is correct and the configuration hasn't changed, but an unknown issuer error appears suddenly, check whether the current network uses HTTPS inspection or the server's certificate chain was recently changed. Follow your organization's certificate trust policies; don't import an unfamiliar root certificate just to silence the error.

5. Port Conflicts: Get the Local Inbound Listening First

When you see address already in use, start by resolving the local listener conflict. Common causes include launching the client twice, an old core process that hasn't exited, or another program using the same address and port. On Windows, a similar issue may appear as Only one usage of each socket address. Changing the remote node won't fix a local port conflict.

These numbers distinguish port roles; they aren't instructions to standardize your configuration. The client determines the local proxy port, the server deployment determines the node port, and DNS may use encrypted transport instead of a traditional port. Use the listening address and port shown in the actual logs. Binding to 127.0.0.1 limits access differently from binding to all network interfaces; don't widen the listening scope just to troubleshoot.

# Windows PowerShell: Find the process listening on the example port
Get-NetTCPConnection -LocalPort 10808 -State Listen |
  Select-Object LocalAddress, LocalPort, OwningProcess

# Linux: Show TCP listeners and process details
ss -ltnp 'sport = :10808'

# macOS: Check TCP listeners on the example port
lsof -nP -iTCP:10808 -sTCP:LISTEN

6. Rule Files and DNS: Tell Startup Failures from Resolution Failures

If the logs contain failed to load geosite, failed to load geoip, or file errors referencing geosite.dat or geoip.dat, check the rule resources before switching nodes. Rules that reference geosite: or geoip: depend on the corresponding data. Missing files, insufficient read permissions, incompatible data formats, or nonexistent categories can all prevent the configuration from loading.

1. Confirm the failing path: Find the file at the exact path shown in the log. Data directories vary by client and installation method; don't assume the resources are next to the executable.
2. Check the resource source: Prefer the client's built-in rule resource updater, and confirm the downloaded file isn't an error page. Keep a copy of the original so you can roll back.
3. Check category names: Having the file doesn't mean it contains every category. Confirm that the categories referenced by routing rules exist in the current resource.
4. Restart and check startup output: Test requests only after the resources load and the core starts listening. The client may overwrite manually edited generated configuration the next time it starts.

System DNS and the core's built-in DNS may use different paths. Successful resolution from a system command doesn't prove the core's DNS outbound is working; conversely, a browser may use a resolver that bypasses the core's DNS. Start by checking the node hostname with a system lookup command, then inspect the DNS server, queried hostname, and failure stage in the core logs. In particular, check whether resolving the node address depends on a proxy tunnel that hasn't been established yet, creating a startup dependency loop.

7. Retest and Ask for Help: Change One Variable and Share Complete Evidence

The goal isn't to eliminate every warning from the logs; it's to find a cause that consistently explains the failure. Change only one thing per round. For example, fix the TLS name, restart the core, and repeat the same request. Don't change the node, DNS, routing mode, and transport all at once; even if the connection recovers, you won't know which change fixed it.

• Startup check: The core stays running, the local inbound listens successfully, and rule resources load.
• Inbound check: Make one request and confirm the logs show it. If there's no record, check that the app is using the correct proxy address and port.
• Outbound check: The request uses the expected outbound, and dialing or handshaking no longer produces the same failure repeatedly.
• App check: Open the page or feature that originally failed. A successful TCP probe or a latency-test result doesn't replace testing the actual app.
• Restore settings: Turn off temporary debug logging, undo any test settings you no longer need, and keep a record of the changes you made.

If you still need help, provide your OS, the actual client and core versions, when the failure occurred, steps to reproduce it, and logs from before and after the same connection. Get version details from the current client or core startup output; don't guess based on the installer name. Before sharing, redact subscription URLs, authentication IDs, passwords, private keys, and other sensitive settings. Keep the error type, port, connection stage, and consistently anonymized address relationships.