For v2rayN users dealing with node timeouts, inaccessible websites, failed core startup, or subscription update errors. Learn to distinguish UI, core, and access logs, extract clues by time, destination, outbound tag, and trailing error text, then turn timeout, rejected, invalid user, connection refused, and port-conflict entries into concrete checks.
Start by separating v2rayN’s three log types
Before troubleshooting, do not capture only the line in red. v2rayN manages configuration, subscription updates, the system proxy, and core processes; Xray is usually responsible for establishing VMess and VLESS connections. The two layers log different events. A single failure may first appear as a connection error in the core log and only later show up as a test timeout in the UI log.
Button names in v2rayN 7.x may change between minor releases, but the relevant information is usually available in the log panel at the bottom of the main window, the log entry in the tray menu, and log files in the application directory. Record the v2rayN version, core version, node name, and failure time first, then inspect entries from 10 to 30 seconds before and after the event.
| Log source | Primary contents | Best for diagnosing |
|---|---|---|
| UI runtime log | Subscription updates, latency tests, configuration generation, core startup, and shutdown | Subscription parsing failures, file read/write errors, and repeated core exits |
| Core error log | DNS, routing, inbound listeners, outbound dialing, TLS, and protocol handshakes | Node timeouts, parameter mismatches, certificate-name errors, and port conflicts |
| Access log | Source address, destination domain or IP, matched outbound, accepted, or rejected | Determining whether a request reached the core and whether it matched a direct or proxy rule |
Read logs along the request path. If the browser never reaches the local inbound, the issue is likely the system or application proxy settings. If the request arrives but a rule sends it to the wrong outbound, inspect routing. If the correct node is selected but dialing times out, check the network, DNS resolution, address, and port. This is more effective than replacing the protocol as soon as you see timeout.
Set the log level and capture one complete reproduction
For everyday use, keep the level at warning or info. warning is quieter and works well for clear failures; info adds inbound, routing, and outbound details and is better for an initial diagnosis. debug is much more verbose and can quickly produce large log files, so enable it briefly only when the issue is hard to reproduce or the normal levels lack context.
In v2rayN 7.x, start with 「Settings」 → 「Parameter Settings」 and review the logging options. Some minor releases place core logging under 「Settings」 → 「Parameter Settings」 → 「Core Type Settings」. If the labels differ, look for entries mentioning log, log level, or access log. Restart the core after changing them; an existing process may otherwise keep the old configuration.
- Note the current time, such as 14:32:10, and stop download and speed-test tasks running at the same time.
- Clear the old display in the UI or mark the end of the log with a timestamp so yesterday’s errors are not mistaken for the current failure.
- Select one node and restart the core. Wait 3 to 5 seconds and confirm that the local inbound listener has started.
- Perform one action only, such as opening one webpage, running one real-connection latency test, or updating a subscription once.
- When the failure appears, stop clicking repeatedly and keep at least 20 lines before and after the error.
- Restore the original log level, then align the UI and core logs by timestamp.
2026/06/25 14:32:11 [Info] transport/internet/tcp: dialing TCP to tcp:198.51.100.24:443
2026/06/25 14:32:16 [Warning] transport/internet: failed to dial outbound
2026/06/25 14:32:16 [Error] proxy/vless/outbound: failed to find an available destination
2026/06/25 14:32:16 [Error] common/retry: dial tcp 198.51.100.24:443: i/o timeoutIn this example, the last line is the direct error, while the first line provides the destination IP, port, and start time. The five-second gap shows that the connection stalled during TCP dialing, before the remote handshake. Check reachability, firewall rules, and the port first—not the UUID, flow control, or transport path.
Takeaway: reproduce once at info level
If warning shows only the final timeout, temporarily switch to info and reproduce the issue once. Use debug briefly only if info still does not show the request entering, route selection, or dialing target.
Common errors: original text, causes, and fixes
Error messages often combine causes from multiple layers. The beginning identifies the module where the failure occurred; the short phrase after caused by or the final colon is usually closest to the direct cause. Do not search only for the first failed—read backward from the end of the full entry and consider the destination, port, and outbound tag.
Error: failed to find an available destination
Cause and fix: The core tried the available destinations but could not establish a connection. This line is usually a summary from a higher layer. Check the following timeout, connection refused, or DNS error, then verify the node address and port and test whether the domain resolves locally.
Error: dial tcp 198.51.100.24:443: i/o timeout
Cause and fix: The TCP connection was not completed within the allowed time. Common causes include an unreachable network, a blocked port, no response from the remote host, or an incorrect address. Confirm that ordinary internet access works and the system clock is accurate, then verify the server address and port 443 in the subscription.
Error: context deadline exceeded
Cause and fix: An operation exceeded its deadline. This may occur during subscription downloads, DNS queries, node tests, or outbound connections. Check the operation named in the previous line. For subscription failures, review the subscription URL and proxy update settings; for node failures, check connectivity to the destination.
Error: connectex: No connection could be made because the target machine actively refused it
Cause and fix: The target host explicitly refused the connection, usually because no service is listening on that port or the address or port is wrong. Unlike timeout, this suggests the network path probably reached the target. Verify the port and the service status first.
Error: proxy/vless/encoding: invalid user
Cause and fix: The remote side rejected the authentication identity. Common causes include an incomplete UUID, a subscription that was updated while the local node remained old, or mismatched client and server settings. Update the subscription and select the node again, then compare the UUID, protocol type, and related authentication parameters.
Error: rejected proxy/vmess/encoding: invalid user
Cause and fix: The VMess user identity or time check failed. Enable automatic synchronization for the date, time, and time zone, then confirm that the node comes from the current valid subscription. If multiple devices report the same node error, ask the configuration provider to verify the account details.
Error: rejected by rule
Cause and fix: The request matched a blocking route; this does not mean the node is offline. Check the domain, port, and rule tag in the same access entry. Look for an ad-blocking, private-address, or custom rule that matched incorrectly, and add the destination to an explicit proxy or direct rule if needed.
Error: listen tcp 127.0.0.1:10808: bind: Only one usage of each socket address is normally permitted
Cause and fix: Local port 10808 is already in use by another process, so the new core cannot listen on it. Fully exit duplicate v2rayN instances or old core processes. You can also choose an unused port under 「Settings」 → 「Parameter Settings」, then update the proxy port in your browser or application.
Error: remote error: tls: handshake failure
Cause and fix: The remote side rejected the TLS handshake. Common causes include mismatched server names, transport settings, or remote certificate configuration. Check serverName, the transport method, and the port after importing the subscription. Do not hide a parameter error simply by disabling certificate checks.
Error: no such host
Cause and fix: The node domain did not resolve to an address. Possible causes include a misspelled domain, a temporary DNS failure, or local network restrictions. Check the copied node address for spaces, verify the resolution result with system diagnostics, then try an available DNS server and restart the core.
accepted in the log does not necessarily mean the request ultimately succeeded. It usually means that an inbound accepted the request or handed it to a specified outbound. If a remote reset, TLS failure, or DNS error follows accepted, continue reading through the same time window. Conversely, if the request is missing entirely, return to the system proxy, browser proxy, or TUN settings and check whether traffic entered v2rayN.
A fixed troubleshooting order from symptoms to log clues
The same page symptom can originate at different layers. A page that spins indefinitely may indicate that the local port never started, or that node dialing timed out. A latency result with no page loading may mean the test path differs from real browsing. A fixed order rules out one layer at a time instead of changing the protocol, DNS, routing, and system proxy simultaneously.
Step 1: Confirm the basic environment
- Disable the system proxy and open an ordinary website to confirm that the local network itself works.
- Enable automatic synchronization in the system date and time settings; VMess and other authentication flows are sensitive to clock drift.
- Record the v2rayN version and current core version. Do not use old logs to explain a new issue after an upgrade.
- When updating a subscription, make sure the link was copied completely and check that it is still valid.
Step 2: Confirm that the core actually started
After switching nodes, look for messages showing configuration generation, core startup, and local listening. If the core exits immediately, address bind errors, configuration syntax, file permissions, or core-file problems first. The system proxy has a usable entry point only after the log clearly shows that the local port is listening.
Step 3: Confirm that requests reach the local port
The common local SOCKS port is 10808, while some configurations use 10809 for HTTP or a mixed port. Do not assume these numbers; use the port shown in v2rayN under 「Settings」 → 「Parameter Settings」. The browser, command-line tools, and system proxy must all connect to the same port that is actually listening.
| Visible symptom | Log to check first | Priority action |
|---|---|---|
| The core exits immediately after startup | bind, failed to start, or configuration-load errors | Free the port or restore a valid configuration |
| No webpage requests appear in the log | Local inbound listener and access log | Check the system proxy and application proxy port |
| The request shows rejected | Domain, destination port, and routing tag | Correct the rule order or matching conditions |
| i/o timeout after the request enters | Outbound address, IP, and port | Check node reachability and subscription parameters |
| Only some domains fail | DNS results and split-routing outbound | Compare the matched rules for working and failing domains |
Step 4: Change one variable at a time
If you change the node, DNS, routing mode, and port simultaneously, even a restored connection will not reveal the real cause. Keep the original node and fix only the item identified by the log; if the retest still fails, move to the next layer. Wait 3 to 5 seconds between tests so the old core can exit and the new configuration can finish loading.
Takeaway: the trailing error determines what to check first
For timeout, check reachability first; for connection refused, check the listening port; for invalid user, check identity parameters; for rejected by rule, check routing. Do not reduce all four errors to a node-speed problem.
Common log questions and practical fixes
Troubleshooting logs does not mean eliminating every warning. Network changes, closed browser connections, and canceled application requests can all produce warnings. What matters is whether the timestamp matches the visible failure, whether it reproduces reliably, and whether entries consistently point to the same destination and outbound.
The log is scrolling too quickly—where should I start?
Stop speed tests and bulk subscription updates first. Note the current second and visit the failing destination once. Then find the first Warning or Error after that timestamp, keeping the dialing address, routing tag, and inbound entry immediately before it.
Does a timeout mean the node is dead?
Not necessarily. Test two other working nodes on the same network. If all three time out after about five seconds, check the local network or egress restrictions first. If only one address repeatedly times out while the others work, the node address or port is the more likely cause.
Latency looks normal, so why will the webpage not open?
First confirm the test type. Basic TCP latency checks only port connectivity; real-connection latency is closer to the complete proxy path. Then verify that the webpage request entered 10808 or the actual configured port, and check whether the access log selected the proxy, direct, or block outbound.
What should I do when a subscription update reports context deadline exceeded?
Check that the subscription URL is complete, then confirm in the subscription group settings whether updates must go through a proxy. If so, connect to a verified working node first. Also check whether the failure occurred during DNS lookup, TCP connection, or download reading.
Why does address already in use still appear after changing the port?
Fully exit v2rayN and confirm that the old core process has ended before restarting. Check whether the new port is also occupied, and update the port in the system proxy and manually configured applications. Changing only the core port leaves applications connecting to the old entry point.
Organize reproducible details before continuing
Complex failures require the environment, actions, and logs together. A single failed to dial outbound line is usually insufficient because DNS, TCP, TLS, authentication, or routing could have triggered it. Preserve the smallest set of information that can reproduce the problem.
- Client: the full v2rayN version and Xray core version.
- Environment: Windows version, current network type, and whether you recently switched networks.
- Configuration: VMess or VLESS, TCP or WebSocket transport, and other transport details without authentication data.
- Reproduction steps: for example, start the core, wait 5 seconds, and open one webpage of the specified type.
- Expected versus actual: expected a normal load; actually timed out after 10 seconds or was refused immediately.
- Log range: 10 seconds before through 10 seconds after the failure, including the first anomaly and the lowest-level cause.
- Comparison: whether other nodes work on the same network and whether ordinary internet access works with the system proxy disabled.
After one fix, retest with the same destination and the same steps. If invalid user disappears but TLS handshake failure appears, authentication has passed and troubleshooting can move to transport and TLS parameters. The fix was not ineffective; a deeper error has become visible.
If the error appears intermittently, compare the duration and destination across at least three entries. Reaching timeout at about five or ten seconds each time usually indicates a fixed deadline. Durations that vary widely from tens of milliseconds to several seconds point more toward packet loss, changing DNS results, or node load. Exact time differences are more useful than saying it is occasionally slow.
Takeaway: use a timeline instead of an error screenshot
Arrange core startup, request arrival, rule matching, outbound dialing, and the final error by second. This usually reveals exactly where the failure stopped; a screenshot containing only the last line loses the crucial context.