How to Read V2Ray Runtime Logs: Common Error Messages and Troubleshooting

First identify which stage the log describes

A connection through V2Ray or Xray is not a single action. The application first passes the request to a local listening port; the core reads the routing rules, resolves the destination domain, selects an outbound, connects to the remote server, and then completes protocol authentication and the transport handshake. Logs usually identify only the stage where the failure occurred, not a complete fix. During troubleshooting, place the error back into the connection flow instead of reinstalling the client as soon as a red line appears.

The most useful approach is to read several records from the same operation that appear close together in time. First clear or pause the old logs, open a specific URL or launch a specific application, then immediately inspect the new entries. This prevents subscription update errors from hours ago, background probes, and the current connection failure from being mixed together.

Check the log level as well. info is commonly used for normal startup, accepted connections, and routing results; warning indicates an abnormal condition but does not necessarily mean all connections will fail; error is the key signal when the current task has clearly failed. After an error, a browser may retry automatically and succeed, so also check whether the page opens, whether the node test passes, and whether the error keeps recurring.

Where to view logs in v2rayN and v2rayNG

v2rayN: check core output first, then client notifications

The v2rayN interface may vary slightly by version and layout settings. In general, runtime output appears in the log or information area at the bottom of the main window; if that area is collapsed, reopen it from the View, Log, or a related menu. When starting a node, updating a subscription, testing latency, or switching the system proxy, client notifications and core logs may appear in different areas. For connection troubleshooting, prioritize core entries containing terms such as Xray, V2Ray, inbound, outbound, and transport.

If no new logs appear at all after clicking Start, first confirm that the core process actually started. Configuration generation failures, a local listening port already occupied by another program, or file access problems can all stop the process before a connection is attempted. Repeated latency tests will not provide useful evidence at this point; fix the first startup error instead.

If the log shows accepted and a connection from a local address, the browser or application has successfully handed traffic to the local proxy. Any subsequent timeout, rejected, or handshake failure usually points to node parameters, the network path, or the remote service. Conversely, if the browser keeps failing but the logs show no corresponding new connection, focus on the system proxy, whether the application follows it, and whether the local listening port matches the one configured in the application.

v2rayNG: open the log page from the side menu

In v2rayNG, the log page is usually available from the side menu. Before troubleshooting, start the configuration, switch back to the target application to trigger one connection request, and then return to the log page to inspect the latest entries. Android background management may pause the app or recreate network connections, so also confirm that v2rayNG is still running properly.

When v2rayNG uses the Xray core, protocol, DNS, routing, and transport errors are output by the core. Information about network changes and virtual network interface status may appear interleaved with core entries. Use the same principle when interpreting them: find the first failure timestamp and read forward from the earliest error instead of looking only at the last line.

If the v2rayNG log shows that local requests are entering successfully but every node times out at the same stage, switch networks once and test again. If only one node fails while other nodes in the same subscription work, first verify that node's parameters or status. This comparison is more useful than focusing on a single error line.

rejected: which side rejected the request

The literal meaning of rejected is that the request was refused, but the party refusing it is not necessarily the remote server. It may be a local routing rule, the destination host, proxy protocol authentication, the transport handshake, or the peer closing the connection. Always use the module name and additional information before and after the line to determine the cause.

If the log also contains blocked, a routing rule name, or an explicit blocking outbound, the request may have been sent to a blocking outbound by a local rule. For example, a custom rule may place a domain on a deny list, or rule ordering may match the destination before it reaches the proxy outbound. Check the current routing mode and temporarily route the domain through the proxy or directly for comparison instead of changing the UUID.

If connection refused appears, the network connection to the destination IP was usually explicitly rejected. Common causes include no process listening on the remote port, a server service that is not running, an incorrect port, or an intermediate network device returning a rejection. This differs from a simple timeout: refusal usually returns quickly, while a timeout often waits several seconds or longer.

When rejected appears together with handshake, authentication, or invalid user, shift your focus to whether the node parameters match the server configuration. Compare the protocol, server port, user identifier, transport, security settings, hostname, and path one by one. Avoid guessing at individual fields in an imported subscription node; update the subscription first, then compare the configuration before and after the update.

Also consider rejection by the destination website itself. The node connection and proxy channel may be working normally while a particular destination imposes access restrictions or closes the connection. Test the same node against several different sites: if most destinations work and only one keeps failing, do not immediately blame the V2Ray core or node authentication.

timeout: first determine where the timeout occurred

timeout is both the most common and the broadest error. It only means that a step did not finish within the allowed time. DNS queries, TCP connection setup, TLS handshakes, WebSocket connections, and response reads can all time out. After seeing timeout, look for a verb on the same line or in the preceding error, such as lookup, dial, connect, handshake, or read. These terms indicate where the wait occurred.

Timeout while connecting to the server address

If the record points to a server IP and port and includes dial or connect, the local device has attempted to establish an external connection but it did not complete in time. Test other nodes in the same subscription, then switch networks and test again. If only one node times out, the node status or port is the more likely cause. If all nodes time out on one network but recover on another, the current network path is more likely. If every node fails on every network, return to the local configuration and core startup state.

Timeout during the handshake

After the underlying connection is established, the protocol and transport still need to exchange data. If the log stops at a TLS, WebSocket, or other transport handshake, verify the server name, transport type, path, host field, and security parameters. A reachable server address does not guarantee that the upper-layer parameters match. An incorrect system clock can also affect connections that depend on certificate validity or time windows, so enable accurate system time on both desktop and Android devices.

Timeout while reading data

read timeout or an expired context deadline may mean that the connection was established but no subsequent data arrived. If this happens only during large downloads or long-lived connections, observe network stability. If every webpage fails after the same number of seconds, continue checking the remote service, transport parameters, and DNS results. Do not substitute a latency test for a real access test: latency probes and full webpage connections may use different request flows.

Timeout troubleshooting comparison order
1. Same node, try a different website
2. Same network, try a different subscription node
3. Same node, switch the current network
4. Update the subscription and select the node again
5. Compare the dial, handshake, read, or DNS stage shown in the logs
6. Change only one variable, then run the next test

invalid user: authentication details do not match the server

invalid user usually appears while processing protocols such as VMess that identify users. It means the server could not match the received authentication details to a valid user. The most common causes are a mismatched UUID, changed node configuration, an old subscription node still in use, or the request reaching the wrong server port.

First update the subscription and confirm that the selected node is actually the updated one. v2rayN may retain old groups, manually added nodes, and nodes from a new subscription at the same time; similar names do not mean identical parameters. Duplicate configurations may also exist in v2rayNG, so check the item currently in use rather than only whether the subscription update succeeded.

For manually created nodes, compare the UUID, protocol, and port character by character. One extra space, one missing character, or pasting the UUID into the wrong field can cause authentication to fail. Do not enter the subscription URL as the node address, and do not split node share content and fill in fields based on guesswork. With VLESS, the exact wording for authentication or request parsing failures may differ, but the focus remains the user identifier, flow control, security layer, transport, and server entry point.

If several devices use the same recently updated configuration but only one keeps showing invalid user, delete the old node on that device, import the subscription again, and make sure an older item with the same name is not selected. If all devices started failing at the same time and the configuration was not changed locally, ask the service provider to check the user status and server configuration.

DNS lookup failure: the domain did not resolve to a usable address

DNS converts domain names into IP addresses. Errors such as failed to lookup, no such host, DNS query failed, or a DNS timeout indicate that the connection may not have reached the destination server. First distinguish between two types of domains: the node server address and the destination domain the user is visiting. Failure to resolve the former prevents the node from connecting at all; failure to resolve the latter may affect only a specific website.

When the node server uses a domain name and that name fails to resolve, the log usually reports the error before connecting to the remote server. Check the spelling and whether the current network can complete DNS queries normally, then update the subscription to rule out a changed address. If the server address is an IP, server-domain resolution is not involved, but the destination website still requires DNS.

When only some domains fail, check whether the routing and DNS rules work together. For example, a domain may be routed through the proxy while its DNS query is sent to a resolver unreachable from the current network, or a custom rule may return a result unsuitable for the connection. Temporarily switch back to the client's default routing and DNS settings to determine whether a custom option introduced the failure.

If every domain query times out but direct access to a known IP still receives a response, focus on DNS server reachability, the system network, and the client's DNS settings. If the log shows repeated queries or a lookup loop, also check whether the local listening port, system DNS, and proxy DNS are forwarding requests to one another. Restart the core after making changes so old connections and caches are cleared.

A domain resolving successfully does not mean the result is suitable for the current route. If the resolved address cannot be reached, the log may show successful resolution followed by a timeout during dial. The issue has then moved from DNS to network connection; continue comparing the node, network, and destination address using the timeout troubleshooting steps.

Configuration, port, and resource file errors

Some problems occur before the core starts, so the browser cannot generate any proxy connection. If the log shows a configuration parse failure, an unknown field, a missing required parameter, or a file that cannot be loaded, restore a configuration that starts successfully first. When editing JSON manually, commas, brackets, field nesting, and data types must all be valid. When importing subscriptions through v2rayN or v2rayNG, make changes in the interface whenever possible to avoid the configuration file and client-generated result overwriting each other.

address already in use or similar port-conflict messages mean that another process is already listening on the local SOCKS, HTTP, or other inbound port. Common causes include an old core that did not exit, starting the client twice, or another local service using the same port. Fully exit the current client and start it again. If the error persists, change the client's local port and update the settings of applications that depend on it.

If routing data files fail to load, rules that depend on geosite or geoip may not work, and in serious cases the configuration may not start. These logs usually identify a missing or unreadable file, or an invalid rule name. Use resource files compatible with the current client and core, and check that category names referenced by custom rules exist. Do not mistake a resource-file error for a failed node.

An unknown field in the configuration may also indicate a mismatch between the client's capabilities and the core. First use the current client version provided by the Download Center and let the client manage its corresponding core. When migrating an old configuration, import a subscription to generate a basic configuration, confirm that it connects, and only then add custom routing or DNS settings one by one.

How to tell whether the problem is local, node-related, or server-side

A single log line can show one failure symptom, but identifying where the problem belongs requires comparison tests. The most reliable approach is to track four variables—node, network, device, and destination—and change only one at a time. This quickly narrows the scope without losing your basis for comparison after multiple settings change at once.

To identify a local problem, check whether the core starts, whether requests enter the local inbound, and whether routing selects the expected outbound. To identify a node problem, check whether other nodes in the same client work. A server-side problem requires consistent results across multiple devices or networks, with logs pointing to authentication, the remote port, or the server processing stage.

“Latency looks normal, but webpages will not open” is not contradictory. A latency test may only verify that a port is reachable or complete a short connection, while a real webpage request still requires DNS, routing, protocol transport, and access to the destination. Use the actual connection logs as the source of truth and look for handshake, read, or destination-connection errors that appear after the test.

A repeatable log troubleshooting workflow

1. Confirm that the client is running. Check the running status of v2rayN or v2rayNG and make sure the core did not exit immediately after starting.
2. Update the subscription and select a specific node. Avoid continuing to use an old node with the same name, and note the current node name and update time.
3. Clear the old logs. Keep only the output from one new test to reduce interference from background requests.
4. Make a single request. Open a known-accessible site and do not run latency tests, subscription updates, or large downloads at the same time.
5. Find the first error. Read several lines upward from the first occurrence of error or warning and confirm whether it belongs to the configuration, inbound, routing, DNS, connection, or authentication stage.
6. Handle the error by type. For rejected, check the source of the rejection; for timeout, check the timed-out action; for invalid user, check the authentication details; for DNS errors, check the object being resolved and the resolver.
7. Change only one variable at a time. Switch nodes first, then networks, or restore routing first and test again; do not change multiple fields simultaneously.
8. Save useful records. Record the time, client version, core type, relevant error excerpt, and comparison tests already performed, while removing authentication details.

The key to log troubleshooting is not memorizing every English error message, but identifying which part of the connection path failed. Once you know whether the request entered the local proxy, completed DNS resolution, reached the server, and passed authentication, “cannot connect at all” becomes one actionable check.

If the current configuration has been manually modified many times, the fastest approach is usually to retain the necessary information, re-import the subscription, complete one connection using the basic routing, and then restore custom settings one by one. v2rayN, v2rayNG, and v2flyNG should all follow the same variable-control method: establish a working baseline first, then identify which change introduced the error.