V2Ray 运行日志怎么看:常见报错含义与逐条定位方法

先确定日志来自哪一层

v2rayN、v2rayNG、v2flyNG 是客户端；V2Ray、Xray 是处理连接的内核。订阅下载失败可能发生在客户端更新器里，此时内核尚未接到请求。相反，日志里出现 proxy/vless/outbound、transport/internet 等模块路径，通常已经进入内核处理阶段。两类问题的排查入口不同。

v2rayN 可先查看主窗口日志区域，再进入「设置」→「参数设置」查找日志相关选项。v2rayNG 可从主界面菜单进入「日志」，在「设置」里检查日志等级；不同版本的入口位置和译名可能调整。记录客户端版本以及启动日志里的内核名称、版本，不要只写“使用 V2Ray”。v2rayNG 使用 Xray 内核，v2flyNG 使用 v2fly 内核，不能仅按应用名称推断错误格式。

日志级别与错误链的阅读方法

V2Ray/Xray 常见的 loglevel 值为 debug、info、warning、error、none。定位故障时可以短暂使用 info，信息不足再提高到 debug。只显示 error 会过滤警告和普通信息；设成 none 后，没有输出不能用于证明连接正常。

{
  "log": {
    "loglevel": "info"
  }
}

上面只是核心配置中的日志片段，不是可直接替换整份配置的文件。使用客户端生成配置时，优先修改界面选项；临时改写生成文件可能在切换节点后被覆盖。访问日志与错误日志的输出位置另由 access、error 等字段及客户端启动方式决定，提高等级不保证一定生成磁盘文件。

1. 先看时间。记住点击测试或刷新网页的时刻，找前后约 10 秒的记录，避免混入后台应用的请求。
2. 再看关联信息。若有方括号内的连接编号，用同一编号串起多行；没有编号时结合目标地址、端口和时间判断。
3. 从外层读到内层。failed to process outbound traffic 通常是外层概括，后面的 connection refused 或 lookup ... 才更接近直接原因。
4. 回看第一处异常。进程启动失败可能导致后续所有测试超时。先修复启动错误，再解释业务请求的失败。

流程链用于确定检查层级，不代表所有协议都严格按同一顺序运行。例如服务器地址已经是 IP 时，不需要先解析该地址；路由规则也可能触发独立的域名解析。判断时以当前配置与日志为准。

连接超时、拒绝与解析失败

“超时”描述的是等待超过限制，没有单独说明是本地 DNS、远端端口还是握手响应出了问题。先确认报错中的目标：它可能是代理服务器，也可能是直连网站或订阅服务器。不要看到任意一个 timeout 就更换全部 DNS 与路由规则。

Windows 上分别验证解析与端口

以下命令使用保留示例域名，仅演示检查方式。运行前，将域名和端口改成当前节点的真实服务器地址与端口；不要填浏览器要访问的网站，也不要填 TLS 的 serverName，除非它恰好就是服务器地址。

Resolve-DnsName server.example.com
Test-NetConnection server.example.com -Port 443

• Resolve-DnsName 检查系统解析路径，不等同于核心内置 DNS 的解析结果。系统能解析而核心失败时，应继续查核心 DNS 的服务器与路由。
• TcpTestSucceeded : True 仅证明该次 TCP 连接成功，不证明 UUID、TLS、WebSocket 路径或远端转发正确。
• TCP 测试失败不能直接判断基于 UDP 的传输。应先确认实际传输类型，再选择对应诊断手段。

TLS 握手失败与时间不同步

握手失败说明连接在安全协商或协议初始化阶段中止，但并非都由证书引起。TCP 可达之后，才依次核对安全类型、服务器名称、证书、传输参数与认证字段。VLESS 的 UUID 校验与 TLS 证书验证属于不同层；修好证书名称不代表 UUID 也正确。

先校时，再核对节点字段

1. Windows 进入「设置」→「时间和语言」→「日期和时间」，打开自动设置时间并执行同步。可用 w32tm /query /status 查看时间服务状态；该命令报错也可能只是时间服务尚未运行。
2. Android 进入系统「设置」，搜索「日期和时间」，启用自动设置时间。核对实际日期和时刻；单纯切换显示时区不是校准系统时钟。
3. 使用 VMess 时，客户端与服务端的时钟偏差可能导致认证失败。两端都应校时，不要仅调整手机显示的时区。VLESS 则不能套用同一套 VMess 时间认证解释，但其 TLS 连接仍需要正确时间来验证证书。
4. 逐项比对服务器地址、端口、UUID、安全类型、serverName、WebSocket 的 path 与 Host，或 gRPC 的 serviceName。字段只按服务端提供值填写，不通过反复随机修改来试错。

端口占用：先让内核正常启动

日志包含 bind、address already in use，或 Windows 的 Only one usage of each socket address 时，应先看本地监听地址。若本地入站创建失败，浏览器即使开启系统代理也没有可用入口。这和远端服务器端口是否开放是两回事。

以日志显示 127.0.0.1:10808 绑定失败为例，在 PowerShell 中查监听进程。若实际报错端口不同，命令中的端口也要同步修改。

Get-NetTCPConnection -LocalPort 10808 -State Listen |
  Select-Object LocalAddress, LocalPort, OwningProcess

Get-Process -Id 1234

第二条命令的 1234 是示例进程号，应替换成第一条结果中的 OwningProcess。查不到记录时，还应检查日志是否对应 UDP 监听、进程是否已经退出，或报错是否来自旧的启动记录。

1. 如果监听者是重复启动的客户端，先从托盘正常退出多余实例，再启动一个实例验证。
2. 如果监听者是其他需要保留的程序，在客户端参数设置中调整本地监听端口，并让使用手动代理的应用同步改用新端口。
3. 修改后重新启动内核，确认出现正常启动信息，再测试网页。不要直接终止不认识的系统进程。
4. 若报错是 permission denied 或 access permissions，还可能涉及系统端口保留与安全策略，不能一概归为重复进程，也不要仅靠管理员权限长期运行来掩盖原因。

一次可复现的排查记录怎么做

同时切换节点、改 DNS、开启 TUN、调整路由后，即使恢复连接，也无法确定哪项修改有效。更稳妥的方法是固定一个目标、一个节点和一种接入方式，把每次测试与日志时间对齐。以下顺序既适用于桌面端，也适用于安卓端的同类问题。

1. 记录基线：写下客户端版本、核心版本、当前网络、代理接入方式和目标地址，暂停不必要的后台下载。
2. 验证启动：重新启动连接，先处理配置解析失败、监听失败与缺失资源等启动阶段错误。
3. 制造单次请求：记下时间，只刷新一个页面一次，保留请求前后约 10 秒的日志。
4. 定位最深错误：先分辨本地监听、域名解析、远端拨号、TLS、协议认证，再选择对应检查项。
5. 只改一项：例如只校正时间，或只修正错误端口；用相同目标重新测试，比较具体错误是否消失或转移到下一阶段。
6. 恢复日志设置：完成排查后退出调试等级，记录有效修改。分享日志前删去 UUID、订阅令牌、完整订阅地址和个人访问记录，保留模块名与错误链结构。

如需进一步理解出站标签与规则关系，可查看配置字段说明。日志显示请求走了直连出站时，应查路由匹配，不要把直连目标的失败当成代理服务器连接失败。

常见追问：哪些日志不能直接下结论