How to Read V2Ray Runtime Logs: What “connection refused” and Other Common Errors Mean

First identify which part of the connection the log recorded

A proxy request does not send a webpage directly from the client to the remote node. With the local SOCKS port 127.0.0.1:10808 commonly used by v2rayN, the browser or another app first connects to the local inbound. The core then resolves the node domain, establishes a TCP or UDP connection, completes a TLS or REALITY handshake, and finally authenticates with protocols such as VMess or VLESS. A failure at any stage may appear in the interface simply as “connection failed.”

So don’t capture only the final word in the log. Find the timestamp for clicking “Test latency,” opening a webpage, or starting a configuration, then read 10 to 30 lines upward. Repeated entries such as retry and failed to process outbound traffic are often only higher-level summaries; the actual cause is usually in an earlier dial, lookup, handshake, or authentication line.

Access logs confirm whether a request reached the core. They commonly show the target domain, target port, inbound tag, and selected outbound tag. Error logs show where the connection stopped. If no new access log entry appears, first check the system proxy, TUN, or the app’s own proxy settings. If the target address appears in the access log and the error log then reports a dialing failure, focus on the node address, port, and network path.

Set the log level and preserve useful context

Log levels are usually debug, info, warning, error, and none. Use warning or error for everyday operation to limit output. When diagnosing connection issues, start with info; switch temporarily to debug only when handshake parameters or routing matches remain unclear. Restore the original level afterward to prevent continuous log growth.

In v2rayN 7.x, open “Settings” → “Parameter Settings” → “Core Type” to confirm whether the current node uses the Xray core or the V2Fly core, then watch the log area on the main screen after restarting the core. After changing the log level or Core Type, stop and restart the current configuration; an existing process will not adopt the new parameters automatically.

1. Set a fixed test time

   Clear the log, or note its current ending timestamp. Within 10 seconds, perform only one “Test real connection latency” action or open one test page.

2. Confirm the core type

   In v2rayN 7.x, open “Settings” → “Parameter Settings” → “Core Type” and verify which core the node actually uses, so you do not inspect logs from the wrong process.

3. Raise the log level

   Reproduce the issue once with info; switch to debug only if routing, handshake, or DNS details are missing.

4. Restart the core

   Stop the current service and start it again. Confirm that the new log shows a listener on 127.0.0.1:10808 or on the port configured for the client.

5. Save the complete excerpt

   Keep 10 to 30 lines before and after the error, and record the node protocol, transport, port, and reproduction steps.

To inspect the generated core configuration directly, look at the top-level log object. The example below writes error and access records to standard output; the exact file location is managed by the client. Manual changes to a temporary configuration generated by the client may be overwritten at the next startup, so use the client’s settings whenever possible.

{
  "log": {
    "access": "",
    "error": "",
    "loglevel": "info"
  }
}

The same approach applies to v2rayNG 1.10.x and v2flyNG on Android: start the target configuration, open the log viewer from the main-screen menu, and reproduce the issue immediately. The system may restrict background processes. If logs stop updating after switching apps, keep the client in the foreground for one test; do not assume “no new logs” means the node is working.

Use the exact error text to diagnose network and port issues

connection refused means the TCP connection reached an address, but the target actively rejected the connection on that port. Unlike a simple timeout, a refusal usually returns quickly. Common causes include a server process that is not listening on the port, an incorrect port, DNS resolving to the wrong host, or a local inbound port mistakenly being used as the remote port.

context deadline exceeded means an operation exceeded its deadline. This can happen during DNS lookup, TCP connection setup, the TLS handshake, or while waiting for a remote response. The message alone does not prove that the node is down; check whether the preceding line identifies a specific target, such as dial tcp, lookup, or TLS handshake.

Elapsed time can help identify where a timeout occurs. A local port conflict usually appears within one second of startup; a remote port refusal often returns within a few hundred milliseconds to several seconds. A deadline exceeded only after roughly 10 seconds is more consistent with packet loss along the network path, a firewall silently dropping traffic, or no response during the handshake. Timing alone cannot prove the cause, but it helps prioritize checks.

Handle invalid user and handshake authentication errors

Messages such as invalid user, invalid account, or authentication failures usually mean that the connection has reached protocol processing, but the identity information submitted by the client does not match the server configuration. For VMess, check the UUID, server time, and whether the node has been disabled. For VLESS, check the UUID, encryption field, Flow, and security method. An extra space introduced while copying a node can also invalidate authentication parameters.

VMess is sensitive to system time. If a desktop or Android device clock is significantly out of sync, authentication may fail even when the address and port are correct. Enable automatic date and time and automatic time zone in the system, then restart the client. Do not simply adjust the minutes manually in the interface; the time zone and second-level drift also need to be corrected.

When using WebSocket, gRPC, or REALITY, verify the transport layer as well as the authentication parameters. Common WebSocket issues include a mismatched path, an incorrect Host, and an HTTP 404 response. For gRPC, check serviceName. For REALITY, check serverName, the public key, shortId, and the fingerprint. A reachable address proves only that the TCP path exists; it does not prove that these fields are correct.

• VMess: Check the UUID, alterId, encryption method, system time, transport type, and TLS settings.
• VLESS: Check the UUID, Flow, transport type, security method, and server name.
• WebSocket: Check path and Host. Slashes and letter case in the path must match the server configuration.
• gRPC: Check serviceName; do not enter the node remark or domain in this field.
• REALITY: Check the combination of serverName, public key, shortId, fingerprint, and Flow. Do not change just one field and reuse the configuration without verifying the rest.

Distinguish node failures, subscription issues, and routing

If every node in the same subscription fails at once, first check the local environment, subscription update result, DNS, and system time. If only one node fails, changes to that node’s address, port, or account status are more likely. If node testing succeeds but a specific website does not open, focus on routing rules, split DNS, and the destination site connection instead of repeatedly reimporting the subscription.

A typical routing issue is that the target domain appears in the log but the wrong outbound tag is selected. For example, a domain that should use the proxy is sent to direct, or a local-network address is sent through the proxy outbound. After changing the rules, reload the configuration and check the outbound tag for the same target again; do not rely only on the client’s status icon.

A successful subscription update only means that the client received a subscription response; it does not mean every node in the subscription is reachable. After updating, check the node count, update time, and whether key fields changed. If the list is empty, first check the subscription-group filters. If old nodes remain, confirm that the client updated the correct subscription group.

Follow a fixed sequence for the final diagnosis

Efficient troubleshooting depends on sequence, not random setting changes. First confirm that the core is listening on the local port, then confirm that the request reaches the inbound. Next check DNS, remote dialing, transport handshake, and protocol authentication. A later stage is meaningful only after the previous one passes.

For example, if the log first shows accepted tcp:example.com:443 and then shows connection refused for the node address, the path from the app to the local inbound is working; there is no need to keep adjusting the system proxy. Focus instead on the remote node port. Conversely, if opening a webpage produces no new access log entry, first check whether the browser or system is actually pointing to 127.0.0.1:10808.

1. Check the listener

   After starting the client, confirm that the log contains no address already in use and that the local inbound port is listening successfully.

2. Check the request

   Open the fixed test page and confirm that the access log shows the target domain and port 443. If it does not, check the system proxy or app proxy.

3. Check resolution

   Search for lookup, no such host, and the node domain to confirm that DNS returned a usable address.

4. Check dialing

   Use refused, timeout, or unreachable to distinguish a rejected port, a path timeout, and an unreachable network.

5. Check the handshake

   Verify the TLS, REALITY, WebSocket, or gRPC parameters, then check the VMess or VLESS authentication fields.

6. Restore the log level

   After locating the issue, change debug back to warning or the original setting, then restart the core.

When sharing troubleshooting details, include the client name and version series, core type, node protocol, transport, error time, and a complete log excerpt. Redact credentials, subscription URLs, UUIDs, public keys, and other private connection details as needed, but keep the stage markers, target port, and outbound tag around the error.