Start troubleshooting by identifying the running core, then distinguish access records from diagnostic output. This guide is for users dealing with pages that won’t load in v2rayN, connection timeouts in v2rayNG, or DNS failures in v2flyNG. Reproduce one request and trace it through the local inbound, outbound routing, DNS, TCP, and TLS—rather than replacing the entire subscription whenever an error appears.
1. What access and error logs record
v2rayN is a client interface; V2Ray and Xray are cores that handle connections. Log formats depend on the core and version actually running. v2rayNG uses the Xray core, while v2flyNG uses the v2fly core. Before troubleshooting, note the core name and version from the startup output—not just the client name.
| Log type | What it typically contains | What it does not prove |
|---|---|---|
| access | Connection source and destination, and—in some formats—inbound and outbound tags. | An accepted entry does not mean the destination page loaded successfully. |
| error | Diagnostics from core startup, connection setup, DNS resolution, and data transfer. | A file named error does not mean every line in it is an error-level message. |
| Client runtime output | May combine core standard output, client events, and subscription request details. | A failed subscription update does not necessarily mean the proxy outbound connection failed. |
For example, an access log entry like accepted tcp:example.com:443 usually means the local inbound accepted the request. The node connection could still time out, TLS verification could fail, or the remote end could close the connection. If the log includes [inbound tag -> outbound tag], use it to check routing; tag names depend on the active configuration.
2. Choosing a loglevel: warning for everyday use, debug for brief tests
Common log levels in V2Ray and Xray are debug, info, warning, error, and none. Output becomes more limited as you move from debug toward error; none disables this diagnostic output. Access logging is configured separately, so loglevel alone does not tell you whether access logs are enabled.
- debug: Shows more detail about processing and is useful for a short reproduction. Fields can vary by core and version.
- info: Useful for observing connections and routing, with typically less noise than debug.
- warning: A good everyday starting point, retaining warnings and more severe messages.
- error: Shows errors only, but may omit context needed to find what led to them.
- none: Avoid this while troubleshooting; it can make “no log entries” look like “no requests.”
In v2rayN, look under Settings → Parameter Settings for the log-level option available in your version, save, and restart the core. Menu group names can vary, so follow the current interface. In v2rayNG or v2flyNG, look for logging options in Settings, then open the log viewer. The subscription list is not the core runtime log.
Here’s an example of the log field in a core configuration; it is not a complete, ready-to-run configuration. It only illustrates how the fields relate. Prefer changing client-managed settings through the interface: manual edits to generated files may be overwritten on the next start.
{
"log": {
"access": "C:/Temp/v2ray-logs/access.log",
"error": "C:/Temp/v2ray-logs/error.log",
"loglevel": "debug"
}
}This example uses a Windows absolute path. Create C:\Temp\v2ray-logs first and make sure the account running the core can write to it. With file output enabled, some entries may no longer appear in the original console window, so check the destination file too. Restore warning after reproducing the issue to prevent logs from growing indefinitely.
3. Connection timeouts and refusals: check the failing address first
The snippets below are common error fragments, not fixed, complete log templates. Module prefixes, package paths, and wrapping can vary by core version. Find the innermost cause first, then determine whether it refers to the node server, a DNS server, or the destination site.
Error: dial tcp …: i/o timeout
Cause: A TCP connection to the address shown in the log did not complete in time.
Fix: First check whether the failing address is the node endpoint. If it is, check the node port, your current network, and the server’s inbound. If it belongs to the destination site, investigate connectivity from the remote exit to that destination.
Error: connect: connection refused
Cause: The connection was explicitly refused. Common causes include no service listening on the destination port or a network device actively rejecting the connection.
Fix: Check the IP and port in the error. If it’s 127.0.0.1:10808, first confirm the local core is running and listening on that port—don’t start by switching remote nodes.
Error: context deadline exceeded
Cause: An operation exceeded its deadline. This message alone doesn’t tell you whether the failure occurred during DNS resolution, dialing, or the handshake.
Fix: Keep the surrounding log entries. Find the module name and innermost error for the same connection to identify the stage that failed.
On Windows, a refused connection may appear as a system error containing connectex rather than the English message above; the troubleshooting approach is the same. A timeout means the operation did not finish in time; a refusal means it received a negative response. Neither proves that the VMess or VLESS configuration is wrong.
Tip: The address in the error is more useful than the word “timeout”
Classify the failing address as a local listener, node endpoint, or destination service, then check only that part of the connection. If the node uses another port, follow the subscription configuration; don’t change everything to 443.
4. TLS handshake failures: check the certificate, hostname, and system clock separately
TLS negotiation happens after the underlying connection is established, but certificate issues aren’t the only cause of a failed handshake. A working TCP connection doesn’t mean the node is fully usable: SNI, the transport path, or server settings may still be wrong. VLESS nodes don’t all use the same security layer; first confirm whether the configuration uses TLS, REALITY, or another combination.
Error: x509: certificate has expired or is not yet valid
Cause: The certificate validity period does not match the current system time. The local clock may be wrong, or the server certificate may have expired.
Fix: First check the system date, time zone, and time synchronization. If the clock is correct, ask the service provider to check certificate renewal and the full certificate chain.
Error: x509: certificate signed by unknown authority
Cause: The current environment cannot build a trusted certificate chain. A missing intermediate certificate, the local trust store, or certificate replacement somewhere on the network may be involved.
Fix: Check the server certificate chain and the local trust environment. Disabling certificate verification is not a routine fix.
Error: tls: handshake failure
Cause: TLS negotiation was rejected. This fragment alone doesn’t identify which setting caused it.
Fix: Check the server name, TLS settings, and transport against the provider’s configuration, then compare with server logs from the same time.
- Server address and serverName: The address is used to connect; the server name is used for TLS and other steps. They can differ, but shouldn’t be swapped arbitrarily.
- WebSocket and other transports: Check the Host header and path. An HTTP 404 or 403 may come from a reverse proxy or an incorrect path; it isn’t automatically a certificate error.
- REALITY configuration: Check the public key, shortId, and server name against the actual configuration. Don’t apply standard certificate-renewal steps.
- EOF: Means the stream ended; by itself, it does not prove authentication failed. Consider whether it occurred before the handshake, during it, or after normal data transfer.
5. DNS resolution failures: distinguish the node hostname from the destination hostname
“DNS is broken” is still too vague. The client may first need to resolve the node server’s hostname. After the proxy connection is established, the destination site’s hostname may be resolved locally or remotely. The routing setting domainStrategy may also trigger resolution to match IP rules; it is not the same as the outbound domain-resolution strategy.
| Log snippet | What it tells you—and what it doesn’t | Next step |
|---|---|---|
lookup …: no such host | This lookup did not return a usable name result; the domain may not exist, or the resolver may have returned a negative response. | Check the spelling of the domain in the error, determine whether it’s the node or the website, then check which resolver is actually being used. |
failed to lookup ip | A higher-level component reported that the IP lookup failed; the specific cause is usually in a later or more deeply nested message. | Look for a timeout, empty result, or resolver connection error. Don’t stop at this summary message. |
read udp …: i/o timeout | If the address shown belongs to a DNS server, its response may not have arrived in time. | Check the network path to the resolver, UDP reachability, and related routing. |
On Windows, use this command to check the system’s DNS resolution. example.com is only a sample; replace it with the domain from your log when troubleshooting. A successful system lookup only confirms that the system resolver works. It does not prove that the core’s built-in DNS, encrypted DNS, or proxied DNS path is working.
Resolve-DnsName example.com6. Trace one request through the logs: local listener → routing → remote server
Before reproducing the issue, temporarily close apps that generate lots of background connections, then use one node and one proxy access method. The example below uses Windows and an HTTP or mixed inbound at 127.0.0.1:10808. If the port accepts SOCKS only, use the corresponding SOCKS test command; a protocol mismatch is not a node failure.
- Check the listener: Use PowerShell to check the local port. If nothing is listening, troubleshoot core startup or the port setting before checking remote certificates.
- Enable detailed logging briefly: Note the start time, send one test request, then review access and error output for that time window.
- Check the inbound: If there’s no access entry, confirm access logging is enabled and you’re checking the right place, then verify that the app is actually using the proxy.
- Check routing: If the output includes an outbound tag, confirm the request took the expected proxy outbound. Assess direct, blocked, and proxy outbound traffic separately.
- Trace the innermost error: Check DNS, TCP, TLS, protocol authentication, and the destination service in order. Change one related setting at a time, then repeat the same request.
Get-NetTCPConnection -LocalPort 10808 -State Listen
curl.exe --proxy http://127.0.0.1:10808 --connect-timeout 10 --max-time 20 -I https://example.com/This curl command specifies the proxy explicitly, so it doesn’t depend on browser or system proxy settings. The 10-second limit applies to the connection phase; 20 seconds is the overall command limit. These are test parameters, not core performance metrics. A successful tunnel in the HTTP proxy output does not guarantee that TLS or the webpage request succeeded; check the full result.
curl.exe --proxy socks5h://127.0.0.1:10808 --connect-timeout 10 --max-time 20 -I https://example.com/The second command is only for inbounds that actually support SOCKS. socks5h sends the destination hostname to the SOCKS proxy for resolution; with regular socks5, curl usually resolves the hostname locally. When comparing the two, note that the resolution location has changed—differences in results can’t all be attributed to node speed.
Tip: If an explicit proxy works but the browser doesn’t, check how traffic enters the proxy first
With the same node and destination, if an explicit proxy request succeeds but the browser has no corresponding access entry, check system proxy settings, browser extensions, and bypass lists first. Repeatedly changing VMess or VLESS settings is unlikely to address the problem.
7. Log troubleshooting FAQs and what to include when asking for help
Why do warnings keep appearing when webpages still load?
First match each warning to a request by time and destination. Background apps, canceled connections, and unreachable secondary resources can all generate log entries. One warning doesn’t mean all traffic is failing. Reproduce the issue with a fixed destination and check whether that specific request actually failed.
What if the log window is still blank after enabling debug?
First confirm that you saved the setting and restarted the core, then check whether file output is configured. If logs are written to a file, verify the absolute path and directory permissions. Also make sure you’re viewing core output, not subscription update records.
Does an accepted entry mean the node connected?
No. It usually only means the inbound accepted the request. Follow the same connection for outbound dialing and handshake entries, then verify the destination’s response with curl. Don’t draw conclusions from an accepted line alone.
Should a subscription update timeout be treated like a node connection timeout?
First distinguish the subscription URL request from proxy data connections. Check whether subscription updates use the proxy, whether the current proxy works, and whether the subscription service is reachable. When sharing logs, redact tokens in the subscription URL; never post the full link.
If you need more help, a concise set of details that traces one failed request is more useful than a full-screen screenshot. Logs may contain visited domains, server addresses, and local paths. Review them before sharing: keep the error type and relationships between entries, but remove account identifiers, UUIDs, passwords, private keys, and subscription tokens.
- Environment: Operating system, client version, and the name and version of the core actually running. Find version details in the local interface or startup output.
- Connection method: System proxy, explicit HTTP/SOCKS proxy, or TUN; include the local listening port in use.
- Reproduction details: Type of destination, when it happened, whether all nodes fail, and whether the issue persists on another network.
- Log excerpt: Include context around the same request, the error chain, and outbound tags. Replace sensitive addresses with consistent labels.
- What you tried: List each setting you changed and the result. Restore your everyday loglevel when troubleshooting is complete.