This guide is for users who have imported a subscription and can start v2rayN, but experience failed connections, pages that will not load, or intermittent node disconnects. The goal is not to translate every log line literally, but to identify whether the problem is in the local listener, DNS, network connection, TLS, user authentication, or routing, then verify the relevant setting with a one-variable test.
Understanding the Three Layers in v2rayN Logs
Not everything shown in the v2rayN window is an error. The client handles subscriptions, interface status, the system proxy, and core process management; the Xray or V2Fly core handles connections, protocols, DNS, and routing; access logs show which outbound path a target address used. These three types of entries can be interleaved by time, so focusing only on the last line can mistake an upstream result for the root cause.
In the v2rayN 7.x interface, start with the information area at the bottom of the main window. To change the level of detail, open “Settings” → “Parameter Settings” and look for options related to log level, access logs, or core output. Labels may vary slightly between minor versions, but use the options provided by the client instead of editing a runtime-generated configuration file directly, since it may be regenerated the next time the core starts.
A typical proxy request passes through the application, local listener, routing decision, protocol handshake, and remote connection in that order. The earlier the error occurs, the more important it is to check local ports and proxy settings first; later-stage errors call for checking the server address, port, transport, TLS, and user identity parameters.
Where to Start Reading a Log Entry
Check the time first, then the level and module, and finally read backward through the error chain from the end. Many Xray logs connect the call chain with multiple greater-than signs: the earlier part identifies the module reporting the failure, while the final part is often closest to the underlying cause. For example, if a line contains both “failed to process outbound traffic” and “i/o timeout,” the connection timeout is the priority—not the generic outbound-processing failure.
The target address matters too. If the failed target is the subscription domain, the problem occurred while updating the subscription; if it is the node server address, the failure is in establishing the proxy connection; if the node is already connected but a website domain cannot be resolved, check DNS or routing rules. Do not conclude from one failed subscription update that every imported node is unavailable.
2026/08/02 14:21:08 [Warning] transport/internet/tcp:
failed to dial TCP > dial tcp 203.0.113.10:443: i/o timeout
2026/08/02 14:21:24 [Info] proxy/http:
request to tcp:example.com:443 accepted [proxy]The first section shows a timeout while establishing a TCP connection to port 443 at the example node address. Check the node address, port, local network, and remote reachability. In the second section, accepted only means that the local HTTP proxy received the application request; it does not mean the target page was returned successfully. Continue checking for a proxy outbound failure in the same second.
| Log Clue | Meaning | Check First |
|---|---|---|
accepted |
The local proxy port received an application request | Continue with the routing result and outbound entries |
direct |
The request was sent to a direct outbound | Routing rules, domain categories, and rule order |
proxy |
The request was sent to a proxy outbound | Node connection, protocol parameters, and remote response |
blocked |
The request matched a blocking rule | Blocklists, ad rules, or custom rule sets |
failed to listen |
The core cannot listen on the local port | Port conflicts, permissions, and duplicate processes |
What rejected, timeout, and invalid user Mean
Keywords only narrow down the problem; they cannot provide a unique answer without context. The same timeout may come from an unreachable node port, a DNS query, or a slow target website; the same rejected may indicate an intentional routing denial or a server rejecting the protocol request. When copying an error, include at least the two lines before and after it, the timestamp, module name, and complete error chain.
Error: connection rejected
Cause and fix: The connection was rejected by a local rule or the remote service. Check whether the same line includes blocked, routing, or a VMess or VLESS module name. If it says blocked, inspect the routing rules; if it appears after a protocol module, recheck the node port, protocol type, and server status.
Error: dial tcp: i/o timeout
Cause and fix: The TCP connection was not completed before the timeout. Confirm that the node address and port are correct, then retest on another network. If only one node in a subscription times out, suspect a problem with that node’s route or port first.
Error: context deadline exceeded
Cause and fix: A connection, query, or handshake exceeded its deadline. Look backward for DNS, TLS, or transport module names, then check the resolver, system clock, transport method, and network latency for that stage.
Error: invalid user
Cause and fix: The server did not accept the current user identity. For VMess and VLESS nodes, verify the UUID, protocol type, and whether the subscription is up to date. Do not just rename the profile; restart the core after making changes and observe the authentication-stage logs again.
Error: connect: connection refused
Cause and fix: The target host explicitly refused the connection on the specified port. Usually, no service is listening there or a network policy is rejecting it. Verify the node port and compare it with another node from the same subscription.
Error: lookup server.example: no such host
Cause and fix: The node domain could not be resolved to an address. Check the spelling and local DNS, switch to a working DNS configuration, and restart the core. Do not mistake a failed domain lookup for a UUID error.
Error: remote error: tls: handshake failure
Cause and fix: The remote side terminated the TLS handshake. Check the server name, TLS setting, system clock, and transport parameters required by the node. If the provider recently updated the configuration, refresh the subscription instead of continuing to use an old node copy.
Error: listen tcp 127.0.0.1:10808: bind: address already in use
Cause and fix: Local port 10808 is already occupied by another process or a second core instance. Fully exit duplicate client processes, or choose an unused port under “Settings” → “Parameter Settings,” then update the manually configured proxy port in your applications as well.
Error: unexpected EOF
Cause and fix: The connection closed before the expected data was received. A single occurrence may mean the page canceled its request; if it appears during every handshake, check the transport method, TLS parameters, network stability, and whether the server is closing the connection.
Why invalid user Cannot Be Checked by Looking Only at the UUID
VMess and VLESS both use a user identifier, but they are not interchangeable protocols. If the protocol type was detected incorrectly during import, the server will not process the request as expected even when the UUID characters match exactly. Older VMess configurations may also include additional parameters. Use the latest subscription content as the source of truth instead of assembling the configuration from memory.
Also confirm that the error comes from the currently selected node. After a subscription update, the list may contain both an old group and a new group; similar names do not mean identical configurations. Note the current profile name, confirm the selected row in the server list, then run a test that visits only one webpage so background requests do not bury the relevant logs.
- Verify whether the protocol is VMess or VLESS; do not guess from the port number.
- Check the UUID character by character, including hyphens and any leading or trailing spaces.
- Update the relevant subscription group and confirm that an old node copy is not still selected.
- Check the system date, time, and time zone; a significant discrepancy can affect handshakes and authentication.
- Restart the core and test again so old connections do not interfere with the observation window.
From an Error Back to the Relevant Setting
Effective troubleshooting requires changing one variable at a time. After each change, clear the log or note the timestamp of its last entry, then send the same test request. If you replace the node, DNS, routing mode, and local port all at once, even a successful recovery will not reveal which change helped, making similar problems difficult to diagnose later.
Choose a known-working ordinary webpage as a fixed target. Close downloaders and sync tools that keep making network requests, then record four details: the current node, system proxy status, local port, and test time. After changing a setting, wait about 15 seconds and check whether the same error appears. Treat it as a stable fault only after it occurs at the same stage three times.
- Confirm that the core has started. If a configuration parse error or local port-listening failure appears first, do not inspect the remote node yet—the request has not left the machine.
- Confirm that the application reaches the local proxy. If a webpage request produces no accepted entry or target-domain record at all, check the system proxy, browser proxy settings, or whether the application follows system settings.
- Confirm the routing action. Whether the target goes to direct, proxy, or blocked determines whether to inspect the direct network, node outbound, or blocking rules next.
- Confirm the node connection stage. Check domain resolution, TCP connection, TLS handshake, and protocol authentication in order. Do not skip an earlier stage and modify parameters for a later one.
- Use a second node for comparison. Keep the network, application, and routing unchanged while switching only the node to distinguish general client settings from a single-node configuration problem.
| Error Stage | Typical Keywords | Related Checks |
|---|---|---|
| Configuration Generation | failed to parse、invalid config |
Node fields, routing-rule syntax, DNS configuration |
| Local Listener | address already in use、permission denied |
Local port, duplicate processes, runtime permissions |
| Domain Resolution | lookup、no such host |
Node domain, local DNS, DNS routing |
| Network Connection | timeout、refused、unreachable |
Node address, port, local network, remote status |
| TLS Handshake | handshake failure、certificate |
Server name, TLS setting, system clock |
| User Authentication | invalid user、invalid account |
Protocol type, UUID, subscription freshness |
| Traffic Routing | blocked、direct、proxy |
Rule order, domain rules, outbound tags |
What to Check When the Logs Look Normal but Pages Still Do Not Load
An accepted entry only proves that the request reached the local proxy. If a proxy entry follows without an obvious error but the page still will not load, check the DNS response, the browser’s own proxy policy, and the target site connection. Some browsers use their own DNS mechanism, and command-line tools may not automatically read the system proxy, so “one application works while another does not” usually does not indicate a general node failure.
After enabling the v2rayN system proxy on Windows, desktop applications that follow system settings will use the corresponding proxy. Applications with manually configured proxies still need the client’s current listening address and port. If the local mixed port is shown as 10808, use the actual value displayed in the interface; do not enter 10809 just because an older guide mentions it. When ports do not match, v2rayN may show no corresponding request at all.
Routing rules can also create the appearance of “connected successfully but unable to access anything.” For example, if a target domain matches direct while the current network cannot reach it directly, the core will not automatically retry through the proxy; a blocked match is denied by design. Checking the outbound tag in the access log is faster than repeatedly toggling the system proxy.
Why Does a Node Show Latency but Webpages Still Time Out?
A latency test and a real webpage request do not necessarily use the same target or transport path. Check the log for the webpage request, confirm that it matched proxy, and look for a subsequent TLS, DNS, or target-site timeout.
The Browser Works, but Terminal Commands Fail to Connect
A terminal program may not read the system proxy. First check how that program configures proxies, then set the address to 127.0.0.1 and the port to the current listening port shown in v2rayN. Do not judge the node solely by the browser result.
Are Repeated accepted Entries an Abnormal Loop?
Check the target domain first. System services, background browser tabs, and sync tools can all send requests continuously. If the entries stop after closing the relevant application, they are usually normal access logs rather than a core error loop.
The Subscription Update Times Out, but Existing Nodes Still Work
This means the subscription URL request failed; it does not mean saved nodes immediately stopped working. Confirm that the subscription URL is complete, check in the subscription settings whether update requests should use the current proxy, and run the update separately once.
All Applications Disconnected After Changing the Port
Applications with manually configured proxies do not follow a changed local port automatically. Open “Settings” → “Parameter Settings” to confirm the new port, update the affected applications, restart the core, and send a new request.
Comparing Logs Across Platforms and Cores
The interface may vary slightly by version when using the desktop client on Windows, macOS, or Linux, but the troubleshooting order is the same: confirm that the client starts the core, then check the local listener, routing action, and proxy outbound. On Android, v2rayNG uses the Xray core and v2flyNG uses the V2Fly core. Log wording may differ, but the TCP, DNS, TLS, authentication, and routing stages still map to one another.
Do not expect another core to reproduce an error in exactly the same wording. One version may show context deadline exceeded while another shows only timeout in the same situation. Compare the stage where the failure occurs—resolution, connection, or authentication. If the subscription includes VLESS configurations, also confirm that the current client and core versions support the corresponding fields.
| Platform Scope | Client and Core | What to Watch in the Logs |
|---|---|---|
| Windows | v2rayN Desktop | System proxy, local port, core startup, and routing tags |
| macOS | Matching v2rayN Desktop Versions | System network proxy, permissions, and core output |
| Android | v2rayNG or v2flyNG | VPN takeover status, active configuration, core logs, and per-app rules |
| Linux | Matching v2rayN Desktop Versions | Desktop proxy settings, environment variables, local listener, and permissions |
What to Include When Sharing Logs
A useful troubleshooting record should include the client version, core type, operating system, time of the incident, selected protocol, several lines before and after the error, and the steps already attempted. Do not publish the server address, UUID, subscription URL, or other authentication details directly. Replace them with consistent redacted labels, while preserving the port, protocol, transport method, and error structure; otherwise the failure stage cannot be identified.
Platform: Windows
Client: v2rayN 7.x
Core: Xray
Symptom: webpages time out after enabling the system proxy
Reproduction time: 14:21:08
Current protocol: VLESS
Node address: server.example
Node port: 443
Key error: dial tcp server.example:443: i/o timeout
Tried: updated the subscription, switched to another node, kept all other settings unchangedThe key to log analysis is not collecting as much text as possible, but building a timeline: what the user did, which layer received the request, where it stopped, and which change altered the result. Following that trail places rejected in routing or remote denial, timeout in a specific connection stage, and invalid user in protocol and identity parameters, instead of sending the investigation back and forth across every setting.