How to Read V2Ray Runtime Logs: Common Errors and Troubleshooting

Quick overview

This guide is for users who have already imported a subscription but are seeing node timeouts, inaccessible websites, or unstable connections. First distinguish client logs from core logs, then follow the request time, destination, outbound tag, and final error to determine whether the problem is with the system proxy, local port, DNS, node parameters, or the remote server.

First distinguish client logs, access, and error entries

Before troubleshooting, confirm which layer the log belongs to. v2rayN and v2rayNG manage subscriptions, nodes, the system proxy, and the core process; the Xray or v2fly core actually accepts connections, applies routing, and establishes outbound connections. A “startup successful” message in the client only means the core process has started—it does not guarantee that a particular node can connect.

access records which inbound handled the request, what it accessed, and which outbound was ultimately selected. It helps answer questions such as “Did the request reach the core?” and “Which rule handled the domain?” An access entry usually means that the browser or app has sent traffic to the local proxy port.

error entries are closer to the underlying cause. Common examples include DNS resolution failures, connection timeouts, port conflicts, protocol handshake failures, and remote disconnects. Typical log levels are debug, info, warning, and error. Keep the level at info for normal use; switch to debug temporarily when reproducing a difficult issue, since debug can generate a large volume of entries quickly.

Log source	What it mainly contains	What to check first
Client logs	Configuration generation, core startup, subscription updates, and system proxy changes	The core file, configuration format, process status, and subscription URL
access logs	Request destination, inbound tag, routing result, and outbound tag	Whether the app reached the proxy and whether traffic was routed as expected
error logs	Connection, resolution, handshake, transport, and listener failures	Local ports, DNS, node parameters, the network, and remote status

Collect useful logs in v2rayN and v2rayNG

Logs are useful only when tied to a specific action. Before you begin, stop continuous speed tests, automatic subscription updates, and background downloads so that dozens of concurrent requests do not get mixed together. Select one node, open the log window, and reproduce the issue once. For example, visit one known-good HTTPS page or run one actual connection test.

Using v2rayN 7.x as an example, first confirm the active server on the main screen. Then go to “Settings” → “Parameter Settings” → “Core Type” and check that the selected core matches the current configuration. Return to the main screen and watch the log area for startup messages. To increase logging detail, find the log level in Parameter Settings, temporarily change info to debug, save, and restart the core.

Confirm the active node

In the v2rayN main list, check the active server and note its address, port, and protocol. Common remote ports include 443, 8443, and other ports specified by the provider. Do not substitute the local listening port.
Restart the core

After saving the settings, select “Restart Service” once. Confirm that the log shows the configuration loaded and the local listener started successfully before opening a webpage, so entries left by the old process are not mistaken for the current result.
Reproduce the issue once

Open one webpage or run one connection test, then wait 10 to 15 seconds and stop. Testing 20 nodes at once creates multiple timeout sequences and makes it difficult to identify the entry for the current node.
Save the surrounding context

Save the first target request together with the next 10 to 20 lines. Do not capture only the final line: context canceled often appears merely as cleanup after the preceding connection failure.

In v2rayNG, open the side menu and select “Logs” to view runtime entries. When v2rayNG uses the Xray core, the log includes both Android startup messages and core output. Focus on the current node name, destination domain, outbound tag, and failure time; there is no need to read every line from the beginning.

The default local SOCKS port is often 10808 and the HTTP port is often 10809, but use the values shown in the client’s current settings. If another app is manually configured with 127.0.0.1:10809 while the client has been changed to 10811, the app’s requests never reach the active core, so the error log may contain no matching entry.

2026/07/15 14:32:10 [Info] transport/internet/tcp: listening TCP on 127.0.0.1:10808
2026/07/15 14:32:12 from 127.0.0.1:53142 accepted tcp:example.com:443 [socks -> proxy]
2026/07/15 14:32:22 [Warning] app/proxyman/outbound: failed to process outbound traffic
2026/07/15 14:32:22 [Warning] common/retry: all retry attempts failed

These entries show that local port 10808 is listening, and that a request from temporary port 53142 entered the SOCKS inbound and was sent to the outbound named proxy. The failure occurred while establishing the outbound connection, so focus on the node address, remote port, network reachability, and protocol parameters—not on changing the browser’s proxy settings.

Read the log as a request flows through the chain

A proxy request typically passes through the app, local inbound, routing decision, proxy outbound, and remote destination. The order may not correspond line by line because multiple connections can run concurrently, but the destination domain, connection identifiers, and outbound tags within the same time window can still reconstruct the path.

App sends requestLocal port accepts itRouting rule matchesNode establishes connectionDestination returns data

First, look for accepted. If refreshing a webpage produces no new access entry at all, the system proxy may be off, the app may ignore system proxy settings, or the app may be using the wrong port. In v2rayN, also distinguish “start the core” from “set the system proxy”: the former only starts the local listener, while the latter directs traffic from apps that support system proxy settings to that port.

Second, check whether the destination is correct. The log may show tcp:example.com:443 or a resolved IP address. Port 443 usually indicates HTTPS, while port 80 usually indicates HTTP. If a webpage request shows only a LAN address or an unrelated domain, close other background apps and reproduce the issue once.

Third, check the routing result in brackets. For example, [socks -> proxy] means the request entered through the socks inbound and was handed to the proxy outbound; [socks -> direct] means the rules sent it directly. If a destination that should use the proxy goes to direct, check the routing mode, domain rules, and rule order instead of changing VMess or VLESS node parameters.

No access entry: Check the system proxy, local listening address, and the port used by the app.
Fails after going to direct: Check whether routing rules incorrectly classify the destination as direct.
Timeout after going to proxy: Check the node address, remote port, local network, and server status.
Handshake error appears immediately: Compare the protocol, security type, transport, Host, path, and SNI with the subscription.
Frequent disconnects after a successful connection: Check whether they occur only on a particular network, node, or during high-volume transfers.

Common error messages and what to check first

An error log often contains several layers of wrapped messages. The outer layer may say only failed to process outbound traffic; the actual cause is usually near caused by, dial, lookup, or handshake later in the entry. Read backward from the specific end cause instead of searching only the first line.

Error: context canceled

Cause and fix: The current request was canceled by an upper layer, commonly after switching nodes, restarting the core, closing a page, or cleaning up after an earlier connection failure. Check the previous 5 to 20 lines at the same time; if you just restarted the core and connections work afterward, this entry usually needs no separate action.

Error: i/o timeout

Cause and fix: The connection or read/write operation did not finish within the allowed time. Confirm that ordinary internet access works, verify the node address and remote port, then test another node from the same subscription. If several nodes time out, check the local network, system time, and DNS first.

Error: connection refused

Cause and fix: The destination host explicitly refused the connection on that port. The remote service may not be listening, the port may be wrong, or a local app may be connecting to an inactive 10808 or 10809. Use the destination IP in the log to determine whether the refusal occurred locally or remotely.

Error: failed to find an available destination

Cause and fix: The core could not obtain a usable destination, often because the node hostname could not be resolved or the destination configuration is invalid. Check for spaces or extra characters in the server address, switch to a reliable DNS service, restart the core, and look for a more specific lookup error.

Error: rejected

Cause and fix: The request was rejected by a routing rule, protocol check, or destination policy. Check the outbound tag and reason nearby. If it went to the block outbound, adjust the routing rules; if it includes invalid request or authentication details, re-import the node parameters from a valid subscription.

Error: EOF

Cause and fix: The peer closed the connection before the expected data was complete. A single occurrence may simply mean that a webpage canceled a request; if it appears immediately on every connection to the same node, verify the VMess or VLESS transport, TLS, security settings, Host, path, and SNI.

rejected does not always mean that a node is unusable. For example, when routing sends an ad domain to the block outbound, rejection is expected. Judge it by checking both the destination domain and outbound tag. If only a rule-blocked request is rejected while the main page loads normally, there is no need to change the node.

context canceled is often a result rather than the cause. When a user switches nodes before a speed test finishes, the old connection is canceled; restarting the core also ends in-progress DNS lookups and outbound connections. Continue investigating only when there was no manual action and every request is canceled—then check for repeated process restarts, automatic configuration refreshes, or network changes.

Narrow the issue down to DNS, ports, parameters, or remote status

After finding an error, do not change several settings at once. Test one hypothesis at a time so you know which action actually helped. Confirm the local path first, then DNS resolution, then compare multiple nodes, and only afterward inspect protocol parameters one by one. Deleting every configuration and importing again may restore service temporarily, but it also destroys useful troubleshooting clues.

If the log contains lookup, no such host, or no usable destination address, check DNS first. Confirm that the node server address was copied correctly, then compare a domain-based node with an IP-based node. If only domain nodes fail while IP nodes work, DNS is the stronger lead; if all nodes fail, also check the local network and core startup status.

Observed result	Most likely area	Next check
10808 failed to listen	Local port conflict	Exit the old process or switch to an unused port; after restarting, confirm a listening entry
No new access entries	System proxy or app proxy settings	Check the app’s 127.0.0.1 address and the actual HTTP and SOCKS ports
lookup fails for multiple domain-based nodes	DNS or the current network	Switch to a stable network and resolve again; do not change node protocol parameters at the same time
Only one node times out repeatedly	Node port or remote service	Compare another node from the same subscription to confirm whether it is isolated to one node
All nodes fail the handshake immediately	System time or parameter mismatch	Synchronize the system clock, update the subscription, and verify the transport parameters
proxy succeeds but a specific domain goes through direct	Routing	Check the domain rules, rule priority, and current proxy mode

Distinguish local ports from remote ports. Local 10808 and 10809 are used by apps to connect to the client; node ports such as 443 and 8443 are used by the core to connect to the server. If the log says it cannot listen on 127.0.0.1:10808, address a local port conflict. If it says a connection to a server address on port 443 timed out, changing the local SOCKS port will usually have no effect.

Protocol parameter problems usually appear as a TCP connection that succeeds but a handshake that fails almost immediately. VMess requires the correct user ID, transport, and security settings; VLESS requires the correct user ID, transport-layer parameters, and TLS or other security settings matching the server. For WebSocket, also verify the path and Host; with TLS, verify SNI. The safest approach is to update from a valid subscription rather than guessing at missing parameters.

Commonly misunderstood log situations

A warning in the log does not mean every connection failed. When a browser opens a page, it may request images, scripts, analytics endpoints, and background APIs concurrently. A timeout on one minor request may occur while the main page loads normally. To assess the impact, check the destination domain, failure count, and actual page behavior together.

The log keeps filling with timeouts—is the subscription invalid?

Stop batch speed tests and use one node to open one page. If that node fails, test a second node from the same subscription. Only when multiple nodes time out on the same network should you continue checking subscription validity, the local network, system time, and DNS.

Should I switch nodes when context canceled appears?

Check whether you had just switched nodes, restarted the service, or closed the test page. If so, it is probably connection cleanup. Without any manual action, look backward for the first timeout, EOF, or process-exit entry.

The core started successfully—why won’t the webpage open?

Check whether refreshing the webpage creates an access entry. If not, verify the system proxy and the actual listening ports such as 10808 and 10809. If there is an entry, check whether the request went to the direct, proxy, or block outbound.

How do I troubleshoot just one website that won’t open?

Clear the current log, visit only that website, and note the destination domain and outbound tag. If it goes to direct, temporarily adjust the corresponding domain rule to test the theory; if it goes to proxy and still fails, check the DNS result and destination connection entries.

v2rayN works, but v2rayNG times out—what should I do?

Do not assume the node is broken. First confirm that both clients use the same latest subscription and the same node, then compare the network environment, system time, Xray core version, transport parameters, and DNS settings. Results from different networks cannot be substituted directly.

Another common mistake is relying only on latency tests. A latency value reflects the duration of one probe, but it does not fully validate the real proxy path. A node showing 180 ms does not guarantee that its protocol handshake, TLS parameters, and webpage transfers will work; conversely, a timeout in one test method does not necessarily mean that real connections are unavailable. Use actual browsing and the corresponding logs as the final reference.

After troubleshooting, restore the debug log level to info and keep a brief conclusion. For example: “Local 10808 is listening normally; access enters proxy; two nodes both time out about 10 seconds after connecting to remote port 443.” This is much more useful for comparison the next time than “the client doesn’t work.”