For users who have imported a config but are having trouble connecting or seeing intermittent failures. First identify whether the log comes from the client or the core, then check the local listener, DNS resolution, remote connection, TLS, and protocol settings in sequence. This guide includes an error reference, Windows commands, and repeatable troubleshooting steps. The goal is to find which layer is failing—not to change every setting at the first red error.
Distinguish client, access, and error logs
v2rayN is a desktop client that manages configurations, starts the core, and handles system proxy settings. The selected core is what actually handles connections. On Android, v2rayNG primarily uses the Xray core, while v2flyNG uses the V2Fly core. Client-side warnings and core connection errors are not the same thing: a failed subscription update does not necessarily mean proxy traffic is failing, and changing browser DNS will not help if the core never started.
Before troubleshooting, note the client version, the core name, and its version. Error formats and supported config options vary between core versions, so don't paste an entire config for one core into another. The explanations below focus on what the log messages mean. Addresses, ports, and snippets are illustrative and do not represent the complete output for any particular version.
| Log source | What it records | Check first |
|---|---|---|
| Client logs | Subscription updates, process startup, config generation | Runtime environment, file permissions, subscription requests |
| Core access logs | Destination requests received, inbound and outbound details | Whether app requests reach the core and which routing rules apply |
| Core error logs | Parsing, dialing, handshakes, and config errors | The underlying cause and destination address |
An accepted entry in the access log usually means the local inbound accepted the request. It does not mean the remote connection was established, much less that the webpage received a complete response. Conversely, if there is no access log entry, access logging may simply be disabled—it doesn't necessarily mean the app bypassed the proxy.
Choosing a log level: start with warning, then enable debug briefly
Common Xray/V2Fly log levels are debug, info, warning, error, and none. The warning level typically includes warnings and errors; debug adds diagnostic detail, while none disables error log output. Access logging has its own setting and should not be confused with the error log level.
-
Check the core
In the v2rayN startup information, note the core name, version, and startup result. Confirm that the expected core is running instead of relying on whether the node uses VMess or VLESS.
-
Change the log level
In v2rayN, the usual path is “Settings” → “Parameter Settings” → “Core: Basic Settings” → “Log Level.” Labels or menu groups may vary by version, so follow the options in your current interface. Select debug temporarily, save, and restart the core.
-
Reproduce the issue once
Note the system time and open just one test address. Collect the continuous logs from about 10 seconds before and after the failure. Don't run a speed test, update subscriptions, and open several pages at the same time.
-
Restore the setting
After reproducing the issue, switch back to warning and disable access logging if needed. Before sharing logs, redact subscription URLs, user identifiers, credentials, and private domain names while retaining the error type and relevant ports.
If you use a custom core config, the log section can look like this. This is only a top-level log config snippet, not a complete, runnable config. A config generated by the client may be overwritten the next time it starts, so make changes through the client interface when possible.
{
"log": {
"loglevel": "debug"
}
}Follow the connection path: find the failed request, then the underlying cause
This illustrates a troubleshooting sequence; not every request follows these steps in precisely this order. Routing may trigger DNS lookups earlier, and direct outbound connections may not go through a proxy server. When reading logs, check the request destination, selected outbound, and actual dial address together. This helps avoid mistaking “destination site unreachable” for “proxy server port unreachable.”
Here is a simplified error chain. The outer message says the proxy request did not complete; the inner dial tcp identifies the TCP connection failure. 203.0.113.10 is a documentation-only example address, and 443 is an example remote port. Neither should be copied as a real node setting.
proxy: failed to process outbound traffic
transport/internet: failed to open connection
dial tcp 203.0.113.10:443: i/o timeout- Check the timing first: Focus on the current reproduction window so you don't mistake a failure from a previous node switch for the current issue.
- Then match the request: If the logs include a connection ID, use it to follow the same connection through the context. Adjacent lines may belong to different concurrent requests.
- Finally, trace the cause: Follow the nested errors to the specific issue, such as failed resolution, a refused connection, a timeout, or certificate verification failure.
Diagnosis: verify the failing layer before changing protocols
If the lowest-level error is still a remote TCP connection timeout, test the address and port first. Changing a VMess user ID or VLESS settings usually won't help before a TCP connection is established.
Common errors explained: refused connections, timeouts, DNS failures, and port conflicts
The same keyword can appear at different layers. Take connection refused: a refusal when connecting to local 127.0.0.1:10808 calls for a very different fix than a refusal from remote server port 443. Here are common log snippets; prefixes and OS-specific error details may vary.
Error: connection refused
Cause: The connection was explicitly refused. This commonly means no service is listening on the destination port, though a firewall may also actively reject it.
What to do: Check the destination IP and port in the log. For a local address, confirm the core is running. For a remote address, verify the node port and whether the server is listening.
Error: i/o timeout
Cause: A network read or write exceeded its time limit. This can happen while establishing TCP, during a handshake, or later during data transfer. The message alone does not prove the node is down.
What to do: Check the preceding operation and address. If the timeout occurred during dialing, check the network path and port. If the connection was already established, check the handshake settings and remote response.
Error: no such host
Cause: The current resolution path could not find a usable DNS result for the domain. Possible causes include a typo, a missing DNS record, or resolver behavior.
What to do: Check the node domain for typos, then verify the result with the system's DNS tools. If the core uses its own DNS, also check that its DNS servers are reachable and that the rules are correct.
Error: address already in use
Cause: Another process is using the local listening address and port, or the same program has been started more than once.
What to do: Identify the process using the port and close any duplicate instance. If you change the inbound port, update the app's proxy settings too; changing it only in the core is not enough.
Error: failed to find an available destination
Cause: The core could not find a usable connection destination. This is a general error that may accompany DNS failures, unreachable addresses, or repeated dialing failures.
What to do: Read the nested error that follows and troubleshoot the specific resolution or dialing issue. Don't assume this line alone means there is a DNS problem.
TLS handshake failures: check the certificate name, system time, and transport settings
A TLS error usually means the connection reached the security handshake stage, but it doesn't guarantee that the client reached the right service. A wrong port, mismatched forwarding config, or interference from an intermediary can all cause unexpected data to reach the client. If the config uses a different security mechanism, the usual TLS certificate troubleshooting steps may not apply.
| Error snippet | Meaning | What to check |
|---|---|---|
x509: certificate has expired or is not yet valid | Certificate validity period does not match the local system time | Correct the system date, time, and time zone, then check the server certificate's validity period |
x509: certificate is valid for | The certificate does not cover the expected name | Check that serverName/SNI matches the certificate domain |
tls: first record does not look like a TLS handshake | The received data does not look like an expected TLS record | Check whether the remote port serves TLS and inspect the reverse proxy entry point |
EOF or connection reset by peer | The stream ended or the connection was reset; there can be several causes | Use the failure stage to check the transport type, path, Host, and server logs |
The server address and serverName are not always the same: the former determines where to connect, while the latter is used for TLS name verification and SNI. With WebSocket, the path and HTTP Host also serve distinct purposes. Connecting to the right IP does not mean these fields match. VMess and VLESS identity settings must also match the server; an EOF alone cannot tell you which field, if any, is wrong.
Windows troubleshooting: test local port 10808 and remote port 443 separately
The examples below assume the client uses local port 10808 for its HTTP or mixed inbound and remote port 443 on the server. These are specific troubleshooting examples and may not match your default settings. Before running them, replace the ports and domain with your actual config values. example.net is a documentation-only domain, not a usable node.
# PowerShell: check whether the local port is listening
Get-NetTCPConnection -LocalPort 10808 -State Listen
# Check the system DNS resolution result
Resolve-DnsName example.net
# Check the specified remote TCP port
Test-NetConnection -ComputerName example.net -Port 443
# Only for a local inbound confirmed to provide an HTTP proxy
curl.exe --proxy http://127.0.0.1:10808 --connect-timeout 10 --max-time 20 https://example.com/- No local listener: Check the core startup logs, config parsing errors, and port conflicts first. Repeatedly switching the browser proxy won't help at this point.
- Remote TCP test failed: This test did not establish a TCP connection to the specified destination. Check the address, network, firewall, and server listener separately. This command does not test UDP.
- Remote TCP test succeeded: This only confirms that a TCP connection can be established to the port. It does not confirm that TLS, VMess/VLESS authentication, or transport settings are correct.
- The command succeeded but the browser failed: First check whether the browser uses the same proxy endpoint, then review the system proxy, extensions, and any app-specific proxy settings.
If the local port only offers a SOCKS inbound, use curl.exe --proxy socks5h://127.0.0.1:10808 https://example.com/ instead. socks5h sends the destination domain to be resolved by the proxy, which helps distinguish that path from local DNS resolution. It does not mean all DNS requests are automatically handled the same way. Match the command's test time with the logs so you don't mistake a background app's connection for the test result.
Bottom line: change one variable at a time
Keep the node, destination, and proxy endpoint fixed, then test each part in turn. Change just one setting per attempt and repeat the same request. That way, you can tell whether the result came from the port, DNS, or handshake settings—not an accidental change in network path.
Log troubleshooting FAQs and what to include when asking for help
The logs keep filling with warnings. Does that mean every connection is failing?
Not necessarily. Background app retries and canceled probes can also produce warnings. Pause batch speed tests, visit a single destination, note the time, then use the destination address or connection ID to find the context for that request.
System proxy is on, but there are no browser requests in the logs?
First confirm that access logging is enabled, then check that the system proxy points to the same port as the client's inbound. Compare with a curl command that explicitly specifies the proxy. Some programs don't use the system proxy, so the toggle alone doesn't show which traffic is being routed.
Subscription update timed out, but the selected node can still load webpages?
Troubleshoot subscription fetching as a separate HTTP request. Check whether the update uses a direct connection or the proxy, whether the subscription service is reachable, and whether the subscription URL is valid. Don't delete a working node config just to troubleshoot a failed update.
Why does Android show no Windows-style port information when a connection times out?
v2rayNG and v2flyNG use a VPN traffic-routing path, unlike the system proxy on desktop. Start by checking the in-app logs and noting the core version, network type, and time of failure. Check the node domain, port, and security settings; don't reuse desktop local inbound port values.
When preparing information for help, continuous context around the error is more useful than a single cropped line. Use the checklist below, save a redacted copy locally, and share only what's needed. Subscription URLs often contain access tokens, even if they don't look like passwords, so don't post them publicly.
- Operating system, client version, and the name and version of the core actually in use.
- Exact time of the issue, and whether you were using the system proxy or TUN.
- Steps to reproduce, type of destination, whether it happens every time, and what changes on a different network.
- The complete redacted error chain, local and remote ports, and whether the commands above succeeded or failed.
- Your most recent changes, such as updating the config, switching cores, changing DNS, or switching networks.
The goal isn't to make every log disappear; it's to get a verifiable result at each layer of the same request. For more on DNS, inbound settings, and routing fields, see the Complete Configuration Guide. If startup or runtime issues remain, check the basics in the Troubleshooting FAQ before continuing with network analysis.