How to Read v2rayN Logs: Common Errors and Troubleshooting Order

At a Glance

v2rayN keeps two logs, GUI and core, and the core log is arranged in three stages: load, handshake and routing. This article covers where to open each log and where the files live, what six common error messages mean and how to fix them, and a five-step order that traces a failure from its timestamp to the outbound node — useful for failed connections, failed subscription updates and routing rules that never match.

Two Logs: GUI and Core

The short answer: v2rayN shows two separate logs. The GUI log records interface actions — starting and stopping the core, switching nodes, updating subscriptions, toggling the system proxy. The core log records the full path of every connection from inbound to outbound. For connection problems, the GUI log usually only tells you that the core started; the reason for the failure is not there.

The log entry point is the Logs tab at the bottom of the main window, where you can switch between the GUI log and the core log. The GUI log is also written to the guiLogs subdirectory of the program folder, named by date; the core log is only shown in the interface by default. When you need finer rule-match and DNS resolution records, go to Settings → Parameter Settings and raise the log level (loglevel) from warning to info or debug, then set it back to warning when you are done.

Log layer	Where to open it	What it records	When to use it
GUI log	Logs tab, GUI side	Core start and stop, subscription updates, node switching, system proxy toggle	Tells an interface failure from a connection failure
Core log	Same tab, switched to the core log	Inbound acceptance, routing decisions, outbound dialing, error stacks	Pinpoints which stage a failed connection died in
Log files	`guiLogs` subdirectory of the program folder, named by date	Keeping GUI log history	Reviewing the previous startup after a restart

Of the three records, the core log is what matters for connection problems; the GUI log is there to confirm whether the core actually started. If the GUI log does not even show a startup entry, nothing further can be analyzed — fix the core startup failure first.

The Three Stages of the Core Log: Load, Handshake, Routing

A normal request leaves four to six lines in the core log, split across three stages in time order: the load stage, where the core reads its config and listens on local ports; the handshake stage, where the inbound receives the request and the outbound starts dialing; and the routing stage, where rules are matched and the final outbound is chosen. The first step in troubleshooting is deciding which stage the error belongs to.

2026/07/02 09:14:02 [Info] infra/conf/serial: Reading config: config.json
2026/07/02 09:14:02 [Info] transport/internet/tcp: listening TCP on 127.0.0.1:10808
2026/07/02 09:14:31 [Info] [4821937461] proxy/vless/inbound: received request for tcp:example.com:443
2026/07/02 09:14:31 [Info] [4821937461] app/dispatcher: default route for tcp:example.com:443
2026/07/02 09:14:31 [Info] [4821937461] transport/internet/tcp: dialing TCP to tcp:node.example.net:443
2026/07/02 09:14:32 [Info] [4821937461] proxy/vless/outbound: tunnelling request to tcp:example.com:443

The number in square brackets is the request ID, and every log line for the same connection shares it. When the log scrolls too fast to read line by line, search for one ID and the whole chain lines up.

Stage	Typical log line	What it means
Load	`Reading config`、`listening TCP on 127.0.0.1:10808`	The core reads its config and listens on local ports; if this line is missing, the core never started
Handshake	`received request for tcp:...`、`dialing TCP to tcp:...`	The inbound receives the request and the outbound starts dialing; if only the first appears, the problem is in routing or the local network
Routing	`default route for`、`tunnelling request to`	Rule match result and final outbound; `direct` means a direct-connection rule matched

The routing stage is the one most often overlooked. When a target domain is matched to direct, no outbound dialing line appears and no error is logged — the page just spins. In that case, go back to Routing Settings and check the rule order instead of switching nodes.

Six Common Error Messages Explained

These six are the most frequent error messages in the core log, listed in inbound-to-outbound order. Each comes with a cause and a fix, and the exact text can be pasted into the log window search box to locate it.

Error: address already in use

Cause and fix: a local listening port is already taken. v2rayN uses 10808 (SOCKS) and 10809 (HTTP) by default, and any other proxy tool or leftover core process holding the same port triggers this. End the leftover process in Task Manager, or change the local listening port to 20808 under Settings → Parameter Settings and restart the core.

Error: failed to find an available destination

Cause and fix: the outbound server address cannot be resolved. A typo in the node address, a failed DNS lookup or DNS poisoning all trigger it. First switch the DNS servers under Parameter Settings to 1.1.1.1 or 223.5.5.5 and restart the core; if the error persists, replace the node address with its IP and try again to tell a DNS problem from a wrong address.

Error: dial tcp ...: i/o timeout

Cause and fix: the outbound connection got no response within the timeout. First confirm the server address and port are reachable — does the same node work on another network? If timeouts are limited to a few nodes, just switch nodes; if every node times out, check whether the local firewall allows v2rayN and the core process.

Error: tls: first record does not look like a TLS handshake

Cause and fix: the transport settings do not match the server — typically TLS is off on the server but on in the client, or the two sides disagree on parameters. Re-import the node share link and make sure Transport Protocol and Transport Layer Security match the server's actual configuration; do not assemble those two values by hand.

Error: rejected proxy/vless: invalid user

Cause and fix: the UUID or password does not match the value registered on the server. If this appears right after a subscription update, the server most likely rotated its UUID while the local copy is still old; copy the share link again or re-import the subscription, and leave the other settings alone.

Error: connection reset by peer or EOF

Cause and fix: the peer closed the connection after it was established. A server process restart, mismatched protocol parameters, or an intermediary device on the path can all produce it. Test the same config against another node first: if switching nodes fixes it, the problem is that one node; only if every node drops should you go back and check the config.

Conclusion: Split by Stage, Then Match Keywords

The same i/o timeout means a server or network-path problem when it follows an outbound dialing line, but points to the local network and DNS when it appears during core startup. Before matching keywords, use the request ID to confirm which stage the error belongs to.

Troubleshooting Order: From Timestamp to Outbound Node

Reading a large log line by line is inefficient. Follow the five steps below — each answers a single question — and you can usually pin down the failure in two or three minutes.

App sends requestInbound receivesRoute matchOutbound dialResponse returns

Line up the timestamps. Search the log for failed or error and note the time on that line; scroll up to the same second or one or two seconds earlier and find the last normal entry with the same request ID. The failure happened between those two lines.
Check whether traffic reaches the core. Search for received request: if the line is completely absent, the request never reached v2rayN — check the system proxy toggle, any browser proxy extension, and whether the system proxy port matches the local listening port (10808 / 10809 by default).
Read the routing decision. Search for default route and direct: when the target is matched to direct, no outbound dialing line appears and no error is logged — the connection just fails silently, so go back to Routing Settings and reorder the rules.
Read the outbound result. The error immediately after dialing TCP to is the root cause; match it against the six messages above. If dialing succeeds but EOF follows, mark that node as unusable.
Reproduce once with fixed variables. Keep a single failing target, turn off automatic subscription updates and latency testing, reproduce once and stop immediately, then clear the log and start over. That cuts the log from thousands of lines to dozens, and every later judgement stops being a guess.

Conclusion: Only a Reproducible Log Is Useful

Fix the failing target to one domain, reproduce once, and capture only the full chain for that request ID — usually under 30 lines. Digging through thousands of lines of history has a far lower hit rate than this one step.

Common Questions About Log Troubleshooting

The five questions below come from real user feedback, and every answer ends in a concrete action.

The log is full of Info — is something wrong?

No. Info lines are normal connection records; only Warning and Error need attention. Setting the log level back to warning just shortens the output; it does not change the connection result.

The log scrolls too fast to read — what should I do?

Turn off automatic subscription updates and latency testing first, then reproduce with a single target domain. When you are done, set the log level back from debug to warning to cut the noise.

I switched three nodes and still get the same error?

Where the error appears decides whether switching nodes helps: errors in the inbound and routing stages will not be fixed by another node; only outbound-stage timeouts and EOF-type errors are worth testing with a different node.

Real domain names and IPs show up in the log — is that normal?

Yes — the core records the destination address of every connection. Before sharing a log with anyone, replace your own server address and target domains.

Subscription update failed and the core log shows nothing?

Subscription updates run at the GUI layer, so check the GUI log rather than the core log; you can also connect to any working node first, then tick Update through proxy in the subscription settings and retry.