v2rayN 运行日志怎么看:常见报错含义与故障定位顺序

本文速览

v2rayN 的日志分 GUI 与内核两层,内核日志又按加载、握手、路由三段排列。文中给出两类日志的打开路径与文件位置、六条常见报错原文的含义与处理办法,以及从时间戳追到出站节点的五步定位顺序,适合连接失败、订阅更新失败、路由规则不生效三类场景。

日志分两层:GUI 日志与内核日志

结论先给:v2rayN 里能看到的日志是两份。GUI 日志记录界面动作,包括启动与退出内核、切换节点、更新订阅、开关系统代理;内核日志记录每一条连接从入站到出站的完整链路。连接类问题只看 GUI 日志,通常只能看到「启动成功」这类记录,失败原因不在这里。

日志入口在主界面底部的「日志」页签,可以在 GUI 日志与核心日志之间切换。GUI 日志同时写入程序目录下的 guiLogs 子目录,按日期命名;内核日志默认只输出到界面,需要更细的规则命中与域名解析记录时,到「设置」→「参数设置」里把日志等级(loglevel)从 warning 调到 info 或 debug,排查完再调回 warning。

记录层	打开位置	主要记录内容	适用场景
GUI 日志	「日志」页签切到 GUI 一侧	内核启动与退出、订阅更新、节点切换、系统代理开关	判断是界面操作失败还是连接失败
内核日志	同一页签切换到核心日志	入站接收、路由判定、出站拨号、错误堆栈	定位连接失败发生在哪一段
日志文件	程序目录 `guiLogs` 子目录,按日期命名	GUI 日志的历史留存	软件重启后回看上一次的启动记录

三份记录里,排查连接问题主要看内核日志;GUI 日志的作用是确认内核到底有没有起来。如果 GUI 日志里连启动记录都没有,后面的分析都没有意义,先解决内核启动失败的问题。

内核日志的三段结构:加载、握手、路由

一条正常的请求在内核日志里会留下四到六行记录,按时间顺序分属三段:加载段是内核读取配置、监听本地端口;握手段是入站收到请求、出站开始拨号;路由段是规则判定与最终出站结果。定位故障的第一步,是判断报错落在哪一段。

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

方括号里的数字是请求 ID,同一条连接的所有日志共用同一个 ID。日志刷得快时不必逐行读,直接搜其中一个 ID,就能把一条链路的记录串起来。

段	典型日志行	说明
加载	`Reading config`、`listening TCP on 127.0.0.1:10808`	内核读取配置并监听本地端口;这一行缺失说明内核没有起来
握手	`received request for tcp:...`、`dialing TCP to tcp:...`	入站收到请求、出站开始拨号;只有前者没有后者,问题在路由判定或本地网络
路由	`default route for`、`tunnelling request to`	规则判定结果与最终出站;出现 `direct` 说明命中了直连规则

三段里最容易被忽略的是路由段。目标域名被规则判给直连时,日志里不会出现出站拨号行,也不会报错,表现是页面一直转圈;这种情况要回到「路由设置」检查规则顺序,而不是换节点。

六条常见报错原文对照

下面六条是内核日志里出现频率最高的报错原文,按从入站到出站的顺序排列。每条给出原因与处理办法,原文可以直接复制到日志窗口的搜索框里定位。

报错:address already in use

原因与解法:本地监听端口被占用。v2rayN 默认使用 10808(SOCKS)与 10809(HTTP),其他代理工具或没退干净的内核进程占着同一端口就会报这条。先在任务管理器里结束残留进程,或在「设置」→「参数设置」里把本地监听端口改成 20808 后重启内核。

报错:failed to find an available destination

原因与解法:出站服务器地址解析不到结果。节点地址拼写错误、DNS 解析失败或被污染都会触发。先在「参数设置」的 DNS 设置里换成 1.1.1.1 或 223.5.5.5 重启内核;仍报错就把节点地址换成 IP 再试一次,以区分是域名解析问题还是地址本身写错。

报错:dial tcp ...: i/o timeout

原因与解法:出站连接在超时时间内没有收到回应。先确认服务器地址与端口可达:同一节点在其他网络下能否连通。超时只集中在个别节点就直接换节点;所有节点都超时,再检查本地防火墙是否放行 v2rayN 与内核进程。

报错:tls: first record does not look like a TLS handshake

原因与解法:传输层配置与服务器不匹配,常见于服务端没开 TLS 而客户端开了,或两边参数不一致。把节点分享链接重新导入一次,确认「传输协议」与「传输层安全」两项与服务器实际配置一致,不要手工拼接这两项的值。

报错:rejected proxy/vless: invalid user

原因与解法:UUID 或密码与服务端登记值不一致。订阅更新后出现这条,多半是服务端换了 UUID 而本地还在用旧值;重新复制分享链接或重新导入订阅即可,其余设置不用动。

报错:connection reset by peer 或 EOF

原因与解法:连接建立后被对端主动断开。服务端进程重启、协议参数不匹配、链路上有中间设备干预都会产生这条。先用同一配置换一个节点验证:换节点就正常说明是单个节点的问题,所有节点都断才需要回到配置层检查。

结论:先分段,再对照关键字

同一句 i/o timeout,出现在出站拨号行之后是服务器或链路问题,出现在内核启动阶段则要查本地网络与 DNS。对照关键字之前,先用请求 ID 确认这条报错属于哪一段。

定位顺序:从时间戳到出站节点

日志量大时逐行读没有效率。按下面五步走,每一步只回答一个问题,通常两三分钟能锁定失败位置。

应用发起请求入站接收路由匹配出站拨号回包返回

对齐时间戳。在日志里搜 failed 或 error,记下那一行的时间;往上翻到同一秒或前一到两秒,找到同一请求 ID 的最后一条正常记录。故障就发生在这两行之间。
确认流量有没有进内核。搜 received request:完全没有这一行,说明请求根本没到 v2rayN,先检查系统代理开关、浏览器代理插件,以及系统代理端口是否与本地监听端口(默认 10808 / 10809)一致。
看路由判定结果。搜 default route 与 direct:目标被判给直连时,日志里不会出现出站拨号行,表现是连不上但不报错,要回到「路由设置」调整规则顺序。
看出站结果。dialing TCP to 后面紧跟的那条报错就是根因,直接对照上一节的六条原文处理;拨号成功但随后出现 EOF,把该节点标记为不可用。
固定变量复现一次。只留一个失败目标,关掉自动更新订阅与延迟测速,复现一次后立即停止,再清空日志重来。这样日志量会从几千行降到几十行,后面每一步判断都不再靠猜。

结论:能复现的日志才有用

把失败目标固定成一个域名、复现一次、只截取该请求 ID 的完整链路,通常不超过 30 行;翻几千行历史日志的命中率远低于这一步。

日志排查的常见疑问

下面五个问题来自实际使用的反馈,答案都落到具体操作上。

日志里全是 Info,是不是哪里出问题了?

不是。Info 是正常连接记录,只有 Warning 与 Error 需要处理;把日志等级调回 warning 只是让输出变短,不会改变连接结果。

日志刷屏太快,根本看不清怎么办?

先关掉自动更新订阅与延迟测速,固定一个目标域名复现一次;排查结束后把日志等级从 debug 调回 warning,减少无效输出。

换了三个节点还是同一个报错?

报错位置决定换节点有没有用:入站段与路由段的报错换节点无效,只有出站段的超时、EOF 类报错才值得换节点验证。

日志里出现真实域名和 IP,正常吗?

正常,内核会记录每条连接的目标地址。把日志发给别人之前,先替换掉自己的服务器地址和目标域名。

订阅更新失败,核心日志里什么都没有?

订阅更新走 GUI 层,应该看 GUI 日志而不是核心日志;也可以先连上任一可用节点,再在订阅设置里勾选「通过代理更新」重试。