Capture the logs around a failed request, then troubleshoot in order: local listener, DNS resolution, remote connection, and authentication. This guide covers startup failures, connection timeouts, and pages that won't load, with pointers to the logs in v2rayN and v2rayNG, V2Ray/Xray log levels, and what to check next for each error.
Reproduce the failure, then find the matching logs
Note when the issue occurs. Pause downloads and background updates, then open just one page to test. Log entries for different connections can interleave; without a timestamp and destination to refer to, it's easy to mistake a background failure for the page you're testing. Don't capture only the last line—keeping about 10–20 lines before and after the error usually makes the sequence clearer.
- v2rayN desktop: Start with the runtime information or log area in the main window, and distinguish client startup messages from core output. To increase detail, open Settings → Parameter Settings and look for core or logging options. Names and groups vary by version; check the interface for “log level” or the
loglevelfield. - v2rayNG for Android: Open Logs from the main screen menu, start the service, then reproduce the issue. If your version has a log-level option in Settings, raise it temporarily and restart the service. Don't mistake Android's VPN permission prompt for a core error.
- Custom V2Ray/Xray config: Check the
logsection in the config actually used at startup.errorpoints to the error log file, andaccessto the access log file. If no file is specified, output location depends on how the core is launched and how the client handles console output. - Can't find the log file? First check whether file logging is configured. A desktop client's executable, working, and config directories may be different, so don't assume logs are always in the install directory. Resolve relative paths against the actual working directory.
Set loglevel: start with info, use debug briefly if needed
loglevel controls how much detail the logs include. Start with info, save, restart the core, and reproduce the issue. Use debug briefly only if you need more detail. Log level is not a network mode: increasing it won't fix a connection or make the proxy handle more apps.
| Level | When to use | What to look for |
|---|---|---|
debug | Briefly investigating a complex issue | Detailed context; available detail depends on the core and version. |
info | General connection troubleshooting | Startup, connection, and routing information. |
warning | Monitoring for issues during normal use | Warnings and more serious issues; fewer routine connection details. |
error | Viewing errors only | You may not see the full sequence of a request entering the core. |
none | Disable this type of log output | Not suitable while reproducing an issue. |
The snippets below can be added to an existing top-level config; they are not a complete proxy config. They omit file paths to avoid introducing directory-permission issues during the first round of troubleshooting. If a client generates the config, change it through the interface when possible—direct edits may be overwritten on the next launch.
{
"log": {
"loglevel": "info"
}
}- To write logs to files, set
errororaccessto a path the current process can write to, and make sure the parent directory already exists. - Don't write logs to system directories that require extra permissions, and don't run all your programs as an administrator just to save logs.
- When you're done reproducing the issue, restore your usual log level and delete any debug files you no longer need. Access logs may contain destination domains, addresses, and connection times.
Understand the error chain: find where the connection stops
The core is the program that actually handles proxy traffic. Inbound accepts requests from local apps; outbound sends them to a direct destination or proxy server. First check whether the request reached inbound, then inspect outbound routing and the network handshake. This is more effective than changing settings one by one.
An error line often chains several causes together: the outer message might say “failed to process outbound traffic,” while the underlying cause is connection refused or i/o timeout. Read the most specific cause first, then check which address it was connecting to. The destination in the log might be a proxy server, a directly accessed site, or a DNS server—not necessarily a problem with your node.
These numbers are just clues for identifying connection roles, not settings you should change across the board. Use the client settings for the actual listening port and the server-provided details for the remote port. Seeing 443 in a log alone doesn't tell you whether that connection went through the proxy.
Connection errors: refused, timed out, or no available destination
Error: connection refused
Cause: The connection was explicitly rejected. This commonly means nothing is listening on the destination port, or a firewall actively blocked it.
Fix: Check the destination address first. If it's 127.0.0.1:10808, check that the local core is running and listening on that port. For a remote address, verify the node port and whether the server is listening.
Error: i/o timeout
Cause: A network read or write didn't complete before its deadline. This can happen while connecting, during the TLS handshake, or while waiting for a response.
Fix: Use the surrounding log messages to identify where the timeout occurred. Test the same node over Wi-Fi and mobile data for comparison; don't assume every timeout is a DNS issue.
Error: failed to find an available destination
Cause: No usable connection was established after attempts to reach the current destination. This is usually a summary error and doesn't identify the root cause on its own.
Fix: Look earlier in the same error chain for a resolution failure, refused connection, or timeout. Then check the domain, port, and network path separately.
Error: no such host
Cause: The resolver couldn't find a valid address for the domain. The address may also be misspelled, or the DNS request may have taken the wrong route.
Fix: First check whether the domain in the log belongs to the node or the destination site. Then check which DNS server is actually being used and review the routing rules.
On Windows, v2rayN users can first check whether the example local port is listening. The command below only queries TCP status; it doesn't change system settings. No results don't prove the remote node is down. Check the client's startup logs first, and confirm the port really is 10808.
Get-NetTCPConnection -State Listen -LocalPort 10808If you've confirmed that the port offers a SOCKS proxy, run an explicit proxy request. socks5h sends the destination domain to the proxy for resolution. The 15-second limit here is set manually for this test; it is not the core's default timeout.
curl.exe --proxy socks5h://127.0.0.1:10808 --connect-timeout 15 --max-time 30 -I https://example.com/- Immediate local refusal: First check whether the core failed to start, the port is wrong, or the proxy type doesn't match.
- Remote timeout after the request reaches the core: Check the node address, network reachability, and handshake parameters.
- The command works but the browser doesn't: Check the system proxy, any browser-specific proxy settings, and the relevant routes. Reinstalling the client shouldn't be your first step.
Authentication and TLS errors: check the config; don't bypass verification
A successful TCP connection only shows that the port is reachable; it doesn't mean proxy protocol authentication succeeded. A UUID identifies a user in some proxy protocols. TLS verifies the server's identity and encrypts traffic. Troubleshoot these separately—changing the log level or local port usually won't fix either one.
Error: invalid user
Cause: User authentication failed. This message often appears in server logs and may indicate mismatched credentials, a removed user, or inconsistent protocol settings.
Fix: Compare the user ID and protocol settings on the client and server. For VMess, also check the system clock. If needed, ask the server administrator to compare logs from the same time.
Error: x509: certificate has expired or is not yet valid
Cause: The certificate's validity period doesn't match the system time. The certificate may have expired, or the device date may be wrong.
Fix: Turn on automatic date and time on the device, then ask the server administrator to check the certificate's validity and deployment.
Error: x509: certificate signed by unknown authority
Cause: The current environment can't build a trusted certificate chain. Possible causes include a missing intermediate certificate, a self-signed certificate, or certificate replacement somewhere on the network.
Fix: Check the server's full certificate chain and the system's trust store. Confirm the expected certificate with the administrator; don't disable verification as a permanent fix.
Error: EOF
Cause: The connection closed before the read completed. On its own, this doesn't prove authentication failed.
Fix: Check the surrounding logs for TLS, transport, and server response details. If this is the only line on the client, ask the administrator for the corresponding server-side log.
- Update the subscription, then select the config you want to use. Updating a subscription refreshes the list but may not switch the active connection automatically.
- Check the server address, port, protocol, user ID, transport, and TLS setting one by one. For WebSocket, also check the path and Host. Don't copy these fields over to other transport types.
- Check SNI, the server name sent during the TLS handshake. It may not match the IP address used for the connection; follow the server's config requirements.
- For REALITY, verify the public key, short ID, and server name against the server's requirements. The fixes for regular certificate errors don't apply.
Startup failures: check port conflicts and config parsing first
If the service exits immediately after starting, troubleshoot the startup logs before testing a web page. If the core never starts listening, a proxy connection failure in the browser is just a downstream symptom. Switching nodes won't fix invalid local config syntax or a conflict on the listening address.
Error: address already in use
Cause: Another process is using the listening address and port, or the core was started more than once.
Fix: Find the process using the port and exit any duplicate instances normally. If you change the local listening port, update the settings of any apps that use it.
Error: failed to load config files
Cause: The config failed to load. The path may be unreadable, the JSON may be invalid, or the current core may not support a field.
Fix: Check the following messages for the file name, field name, and line or column details. Restore the last working config and confirm it's compatible with the core.
On Windows, use the earlier port query command to find OwningProcess, then run the command below to identify the process. Once you know what it is, close the relevant app normally. Don't force-quit an unknown system process just because it is using the port.
Get-NetTCPConnection -State Listen -LocalPort 10808 |
Select-Object LocalAddress, LocalPort, OwningProcess
Get-Process -Name *v2ray*, *xray* -ErrorAction SilentlyContinueCommon questions: warnings, missing logs, and successful speed tests
There are warnings in the logs, but pages load. Do I need to change the config?
First check the warning's time and destination. A background app canceling a request or a failed direct connection may have nothing to do with the page you're using. Act only on errors that reliably reproduce and affect you. Compare the surrounding logs; warning counts don't indicate node quality.
I set the level to info, but no new entries appear when I visit a page. Why?
First confirm the core is running, then test the verified local port with an explicit proxy command. If that request appears in the logs but the browser request doesn't, check the browser or system proxy settings. In v2rayNG, check the VPN service status and whether per-app proxy settings exclude the app.
Why do connections still time out when the latency test succeeds?
First check what kind of speed test it was. A TCP latency test verifies only part of the connection process; it doesn't guarantee authentication, TLS, or access to the destination. Make a real web request through the same node, then use the logs to see whether it stalls while connecting to the remote host or later in the handshake. Don't rule out a node config issue based on latency alone.
Should I send the full subscription and logs to the administrator?
First remove subscription links, user IDs, tokens, passwords, and personal addresses. Include only the original error text, timestamp, and necessary context. Label the roles of “local address,” “node address,” and “destination address.” Delete sensitive values and note that they've been redacted; don't send screenshots of the full config.
Summarize your troubleshooting: make the next test conclusive
After a round of troubleshooting, test again with the same node, destination, and network. One successful attempt only proves that request worked at that moment. If the issue is intermittent, keep testing under the original conditions. When reporting back, describe what you did and what happened—that's more useful than “still not working.”
- Environment: OS version, client version, core name and version, and whether traffic is handled through the system proxy or VPN/TUN.
- Steps to reproduce: Which config you started, which destination you accessed, when the issue occurred, and whether it still happens after switching networks.
- Evidence: The original error text with sensitive details removed, plus surrounding context. Specify whether the error came from the client or server.
- Changes made: Record which fields you changed, what happened before and after, and whether the same error returned after restoring the original config.
Finally, restore your usual log level and keep a copy of the working config. For refused connections, check the listener and port; for timeouts, identify where they occur; for authentication errors, check credentials and protocol; for certificate errors, check the clock and trust chain. Troubleshoot layer by layer to avoid repeatedly changing unrelated settings.