How to Read V2Ray Logs: What failed to dial, rejected, and Other Common Errors Mean

When a client shows “Connected,” it only means the core has started or the local proxy port is listening. It does not mean the target website, node server, and remote outbound path are all reachable. The most useful clues are usually at the end of the log: which inbound received the request, which route matched, which address failed to connect, and whether the failure occurred during DNS resolution, TCP connection, the TLS handshake, or user authentication.

First, distinguish access logs, error logs, and client output

When the V2Ray or Xray core handles a request, it passes through several stages: the local application, inbound proxy, route matching, outbound protocol, and remote destination. Each log type answers a different question. Focusing on one red line can make the result look like the cause; first identify the log type, then read the surrounding entries in chronological order.

A destination domain in the access log only proves that the request reached the local core. If failed to dial appears immediately afterward, the problem is still in the outbound connection. Conversely, if clicking a page produces no new access entry at all, check the system proxy, browser proxy, or per-app rules before changing node settings.

Finding useful logs in v2rayN, v2rayNG, and v2flyNG

Fix the test conditions first: select one node, note the current time, close downloads or other apps that keep making network requests, and open one fixed page. This reduces background noise. Start with the warning or info log level; debug produces extensive connection details and is best enabled briefly when normal output is insufficient.

1. Confirm the active core

   In v2rayN 7.x, open “Settings” → “Parameter settings” → “Core type” and note whether the current configuration uses Xray or v2fly. Protocol support and error wording can vary by core.

2. Open the information panel

   Return to the v2rayN main window and check the information area at the bottom. Run “Restart service” once and confirm entries for core startup, configuration loading, and local port listening.

3. Reproduce one request

   Keep the log window visible and open the target page only once. If the local HTTP port is 10809, first check whether the log shows a request to the destination domain.

4. View Android logs

   After connecting a node from the v2rayNG 1.9.x or v2flyNG main screen, open “Logs” from the menu in the upper-right corner. Clear the old entries first, then return to the target app and reproduce the issue once.

5. Raise the log level briefly

   If warning does not show the failure chain, switch the log level to info or debug, restart the core, and reproduce the issue. Restore the original level afterward to prevent the log from growing rapidly.

If the client interface only shows simplified output, you can explicitly specify a log file in a custom configuration. The example below shows the general structure; replace the path with a directory the current account can write to. Reload the configuration afterward, or you will still be viewing output from the old process.

{
  "log": {
    "access": "D:/v2ray-logs/access.log",
    "error": "D:/v2ray-logs/error.log",
    "loglevel": "warning"
  }
}

If no log file is created, first check that the directory exists, the process has write permission, and the client has not overridden the custom log configuration. Do not change the protocol, DNS, routing, and ports all at once just to collect more information; changing several variables together makes the effective fix impossible to identify.

Read an error’s structure: trace it backward from the final cause

V2Ray and Xray errors are often wrapped layer by layer by multiple modules. A single entry may include modules such as transport, proxy, common, and internet, with the call chain joined by greater-than signs. Start with the timestamp, destination address, and final cause, then work backward to identify the protocol or transport stage involved.

2026/06/02 10:18:42 [Warning] transport/internet/websocket:
failed to dial WebSocket > transport/internet:
failed to dial to (wss://node.example:443/path):
dial tcp 203.0.113.20:443: i/o timeout

This example already contains a numeric address, so “the local machine cannot resolve the node domain” is not the leading hypothesis. The final cause is a TCP connection timeout, and VMess or VLESS user authentication has not been reached. Repeatedly changing the UUID is unlikely to help; first verify whether port 443 is reachable.

If the final cause is connection reset by peer, the connection was actively reset after being established by the remote side or an intermediate device. If it is connection refused, the host is usually reachable, but no service is listening on that port or a policy is explicitly rejecting it. timeout, reset, and refused describe different network states and should not all be labeled “node failure.”

What to check for failed to dial, rejected, and invalid user

Classify frequent errors by their final cause rather than searching only for the outer message failed to process outbound traffic. The outer text often merely summarizes an outbound failure; the last few segments determine where to look. Here are common messages and the first actions to take.

VLESS does not use VMess’s time-based authentication mechanism. When invalid user appears, first confirm the actual protocol and which node the log belongs to. A subscription may contain VMess, VLESS, and other node types; the selected client entry provides the context for this log.

Trace the request layer by layer instead of changing the entire configuration

A request from the browser to the remote destination passes through at least five layers. The most effective approach is to verify the layer closest to you first, confirming one fact at a time. If one layer has not passed, leave the next layer’s settings alone for now.

1. Verify the system proxy. Open v2rayN and confirm that the system proxy is set to the expected mode. If opening a page produces no new log entry, the request may not be reaching the local proxy port at 127.0.0.1.
2. Verify local listening. Use the value shown in the client status bar. Common configurations use SOCKS 10808 and HTTP 10809, but users can change these ports, so do not rely solely on tutorial defaults.
3. Verify the routing result. Temporarily switch to a simpler global proxy mode for testing. If global mode works but rule mode fails, focus on domain rules, IP rules, the block outbound, and the final match order.
4. Verify the node connection. After the destination node address appears in the log, identify whether the failure occurs during DNS, TCP, TLS, WebSocket, gRPC, or user authentication.
5. Verify destination differences. If several common sites fail, the node or local network path is more likely at fault. If only one domain fails, first check the DNS result, routing match, and the destination site’s own status.

Use curl for a minimal test of the local port. The commands below request this site through the HTTP proxy port 10809 and SOCKS port 10808; replace them with the actual ports shown by your client. A 10-second limit helps distinguish an immediate refusal from a sustained timeout.

curl --proxy http://127.0.0.1:10809 https://v2help.com -I --max-time 10
curl --proxy socks5h://127.0.0.1:10808 https://v2help.com -I --max-time 10

If the command immediately cannot connect to 127.0.0.1, check local listening or the port value. If the local port accepts the connection but times out after about 10 seconds, return to the core log and inspect the remote connection. If HTTP response headers arrive but the browser still cannot open the page, check browser proxy overrides, extension settings, and whether another program has changed the system proxy.

Typical DNS, routing, and time issues in logs

DNS problems do not only appear as “domain not found.” The same node domain may return both IPv4 and IPv6 addresses, and reachability can differ between networks. If the log repeatedly tries an IPv6 address and times out, then works after switching to IPv4, resolution succeeded but the current network cannot reach that address family.

Routing mistakes usually have a clear pattern of selectivity: some domains always work, while others consistently enter the direct or block outbound. The outbound tag in the access log is more useful than the error log here. After changing rules, restart or reload the configuration and confirm that new requests have updated timestamps.

Time issues mainly affect authentication processes that require clock validation. Check more than the displayed clock: verify the date, time zone, and automatic synchronization status. Even if the hour looks correct, an incorrect time zone combined with manual time can still create a real clock offset.

What to keep in a shared log, and what to hide

When describing an issue to someone else, the complete environment is more useful than a cropped failed message. At minimum, include the client name and version, active core, node protocol, time of failure, whether all nodes fail, network type, and the comparison tests you ran. This avoids repeated questions and helps determine whether the errors came from the same operation.

• Keep: Failure time, log level, module names, the error chain, destination port, transport type, and local listening port.
• Keep: Client version ranges such as v2rayN 7.x and v2rayNG 1.9.x, along with the Xray or v2fly core type.
• Hide: Full subscription URLs, UUIDs, passwords, authentication strings, node domains, and personally identifiable network information.
• Note: Replace the node address with node.example, but clearly state whether the port, protocol, TLS switch, and path match.
• Include: Reproduction steps and results, such as “global mode works, rule mode fails” or “HTTP 10809 connects, remote 443 times out.”

The key to reading logs is not memorizing every English phrase, but identifying the failing layer. If there is no access entry, check the proxy entry point; for no such host, check DNS; for timeout, refused, or reset, check the network and port; after TLS or transport handshaking begins, verify the relevant parameters; only for invalid user should you return to authentication details and time synchronization.

After making one change, reproduce the issue with the same destination, node, and test method, then compare the old and new logs. Only controlled variables can show that the problem was actually fixed rather than temporarily bypassed or hidden by another background request.