Clash Verge Rev 日志怎么看:常见报错含义与定位思路
逐条解读日志页里的连接超时、DNS 解析失败、配置解析错误等报错,说明日志级别切换方法与按关键字缩小问题范围的步骤。
先复现一次请求，再查看同一时间的日志
Clash Verge Rev 的日志用于判断故障发生在哪一层：配置有没有加载、域名有没有解析、请求命中了哪条规则、代理节点是否连通。红色报错不一定代表全部连接中断；一条失败记录也不能直接证明订阅失效。先确定具体操作，再读对应时间附近的记录。
客户端界面与 mihomo 内核负责的事情不同。订阅下载、界面操作、服务管理可能产生客户端日志；代理连接、规则匹配和 DNS 处理主要由内核记录。遇到“订阅更新失败”时，应先看更新操作的提示；遇到“浏览器网页打不开”时，优先看内核连接日志。
- 打开侧边栏的「日志」页面，记下当前时间，暂停其他下载或测速任务。
- 只访问一个出现问题的网站，刷新一次，避免同时打开十几个标签页。
- 在日志中定位这一时刻的目标域名、端口以及错误文本。有搜索框时输入关键词；没有时复制必要片段，在本地文本编辑器中查找。
- 打开「连接」页面核对目标地址、命中规则和代理链。短连接可能很快消失，此时以已记录的日志为依据。
日志级别怎么切换：日常用 info，定位时用 debug
日志级别决定记录的详细程度，不会直接修复连接。在「日志」页查找顶部的日志级别选择项；提供该控件的版本可从 info 临时切换到 debug。如果界面只有筛选项，要区分“过滤已收到的日志”和“修改内核日志级别”：只改变显示筛选，并不会让内核补发先前没有记录的细节。
| 级别 | 记录范围 | 使用场景 |
|---|---|---|
silent | 关闭日志输出 | 不适合排查正在发生的问题 |
error | 错误 | 只关注明确失败，容易遗漏前置线索 |
warning | 警告和错误 | 观察异常，部分连接过程不会显示 |
info | 信息、警告和错误 | 日常使用与初步定位 |
debug | 加入调试细节 | 短时间复现 DNS、规则或连接问题 |
界面没有级别控件时
mihomo 对应的配置字段是顶层 log-level。需要通过配置调整时，先备份，再使用当前版本支持的覆写或合并入口写入下面一行，并重新加载配置。不要只修改随后会被订阅更新覆盖的原始内容，也不要假定编辑后已经生效。
log-level: debug复现后检查是否出现更详细的记录，确认生效。排查结束将其恢复为 info。调试日志可能包含访问域名、内网地址和代理名称，不适合长时间开启后整份公开上传。
连接超时：先看超时的是节点还是目标网站
i/o timeout、context deadline exceeded 和 connect: connection timed out 都表示某项操作在期限内没有完成，但发生位置可能完全不同。错误前后若出现 dial tcp，应继续看它连接的 IP 与端口，而不是看到 timeout 就更换 DNS。
dial tcp 203.0.113.10:443: i/o timeout
context deadline exceeded这里的 203.0.113.10 是文档示例地址，不能作为可用节点测试。实际日志中的地址如果属于代理服务器，应检查本机到节点的链路；如果请求命中了 DIRECT，地址可能属于目标网站。涉及多层代理链时，还要看失败发生在链路的哪一跳。
按同一目标做对照
- 只有一个节点超时：在同一策略组切换到另一个已知可用节点，再访问相同网址。若恢复，优先检查原节点的地址、端口、服务状态或网络可达性。
- 多个节点都超时：检查本机网络、门户认证、防火墙，以及代理服务器地址是否解析正常。多个节点共用同一域名时，也可能是共同入口异常。
- 只有一个网站超时：核对规则与出口。目标服务故障、出口限制或路由异常都可能造成相同表象。
- 测速成功但网页失败：测速通常只访问配置的测试 URL。它不能保证任意网站、UDP 流量或所有协议都可用。
不要先把超时时间调得很长。延长等待只能改变多久报错，不能修复错误的节点地址，也不能让被阻断的链路恢复。
DNS 解析失败：区分没有解析到地址与解析服务不可达
遇到 no such host、DNS resolve failed 或带有 DNS 上游地址的超时，应先确认失败的域名。代理服务器域名解析失败，会让许多网站一起不可用；单个网站域名解析失败，则应围绕该域名检查。
| 关键词或现象 | 可能含义 | 先检查什么 |
|---|---|---|
no such host | 本次解析没有得到可用结果 | 域名拼写、域名是否存在、当前解析路径 |
| DNS 请求超时 | 上游响应未按时返回 | 解析服务是否可达、上游连接走向 |
connection refused | 解析服务所在地址或端口拒绝连接 | 本地 DNS 服务是否启动、监听地址与端口 |
| 只有代理服务器域名失败 | 代理建立前的解析环节异常 | 节点域名解析与代理依赖关系 |
系统 DNS 测试不等于内核 DNS 测试
可以用系统命令做对照，下面命令查询文档示例域名：
nslookup example.com系统查询成功，只能说明该命令使用的解析路径返回了结果。mihomo 可能使用单独的 dns.nameserver、加密 DNS、域名策略或代理服务器专用解析配置，结果不能直接互相替代。浏览器自身的安全 DNS 也可能形成另一条路径。
启用 TUN 后，还应核对 DNS 劫持是否接管了预期流量。使用 Fake-IP 模式时，连接信息中出现配置的合成地址段不必然是异常；例如 198.18.0.0/16 常用于 Fake-IP 地址池，最终连接仍需结合域名映射与规则判断。不要仅凭该地址就删除整段 DNS 配置。
配置解析错误：按行号查缩进，再查字段引用
配置加载失败通常发生在连接建立之前。常见提示包括 yaml: line 12: did not find expected key、字段类型不匹配，以及规则引用的策略组不存在。此时反复切换节点没有意义，应先让配置通过解析和内核校验。
缩进错误与字段类型错误
# 错误示例：nameserver 的层级不一致
dns:
enable: true
nameserver:
- 1.1.1.1
# 正确示例：同级字段对齐，列表位于 nameserver 下方
dns:
enable: true
nameserver:
- 1.1.1.1YAML 缩进使用空格，不要混入 Tab。行号往往指向解析器发现问题的位置，实际错误可能在前一行，例如漏写冒号、引号未闭合或列表缩进错误。检查报错行时，至少连同前后各几行一起阅读。
- 字段类型：
mixed-port: 7897应提供端口数值；列表字段不能随意改成一整段字符串。 - 名称引用：规则中的策略名称必须对应存在的代理或策略组。重命名策略组后，应同步检查
rules内的引用。 - 规则提供者：
RULE-SET引用的名称应在rule-providers中定义。下载失败与名称不存在是两类问题。 - 配置来源：若只在更新订阅后失败，先保留错误提示与旧配置，再判断是订阅返回内容异常，还是本地覆写与新配置发生冲突。
端口拒绝与地址占用：确认报错地址属于哪一端
connection refused 表示连接遭到明确拒绝。若地址是 127.0.0.1:7897，优先检查本机代理监听，而不是远端节点。打开客户端「设置」，查看当前混合端口，并确认内核运行正常；应用手动填写的代理端口也必须与它一致。
connect to 127.0.0.1:7897: connection refused
listen tcp 127.0.0.1:7897: bind: address already in use第二种错误表示监听端口已被占用。Windows 可在终端执行下面的命令，查看监听记录及其 PID：
netstat -ano | findstr :7897macOS 与安装了 lsof 的 Linux 可查看同一 TCP 端口的监听进程：
lsof -nP -iTCP:7897 -sTCP:LISTEN先确认进程归属，不要直接结束陌生系统进程。如果决定将客户端混合端口改为 7898，还要同步更新浏览器扩展、终端环境变量和其他手动代理配置。使用系统代理的应用应重新确认系统代理状态，避免仍指向旧端口。
若拒绝连接的是远端节点地址，则检查节点端口与服务状态。相同的错误关键词，因地址不同，处理对象也不同。
TLS 错误、连接重置与 TUN 异常怎么分辨
TLS 证书与握手错误
x509: certificate has expired or is not yet valid 应先核对系统日期、时间与时区，再检查服务器证书有效期。certificate is valid for 一类提示可能涉及证书域名不匹配，需要核对节点的服务器地址、TLS 服务名及订阅参数。
TLS handshake timeout 则不等同于证书错误，还可能是链路阻断、丢包或远端没有按预期响应。不要把关闭证书验证作为通用修复手段；它既不能解决所有握手失败，也会降低身份验证能力。
连接重置与 EOF
connection reset by peer 表示连接被对端或链路中的设备重置；EOF、unexpected EOF 表示读取遇到连接结束。它们可能来自目标服务、代理服务器或中间网络，单靠这几个词不能判定责任方。
若记录只在关闭网页或结束下载后出现，且实际访问正常，可以先观察。若每次访问同一地址都立即失败，记录目标、所用节点和发生时刻，再通过更换节点或网络进行对照。
TUN 创建失败与权限问题
出现与虚拟接口、路由安装或权限相关的错误时，先检查客户端服务模式是否正常，以及当前系统是否允许创建虚拟网络接口。TUN 接管的是网络流量，不能修复节点本身的失效；系统代理正常而 TUN 失败时，应集中检查虚拟接口、路由与其他 VPN 的冲突。
测试时不要同时改变 TUN、DNS、节点和规则。先记录原状态，再一次只调整一个变量。需要理解两种接管方式时，可参阅客户端使用教程；字段含义可对照进阶配置。
按关键词缩小范围，保留可复现的排查记录
一份有效记录应能把“哪个操作失败”与“哪条日志相关”连起来。先搜索目标域名，再看同一时间窗口的错误，通常比单独筛选全部 error 更有用。后台健康检查、规则集更新和其他应用也会产生日志，不应把所有异常归到当前网页。
- 写下环境：操作系统、客户端实际版本、mihomo 实际版本，以及系统代理和 TUN 是否开启。版本从客户端显示的信息读取，不凭安装时间推断。
- 固定复现操作：记录目标网址、发生时间、应用名称和具体表现，例如“页面一直等待”或“立即提示代理连接失败”。
- 保留上下文：复制首次失败前后约 10 至 20 行相关日志，保留时间、错误关键词、端口和规则信息。
- 做一次对照：只切换节点或只更换网络，注明是否恢复。不要同时重写配置后再声称某个开关有效。
- 恢复日常状态：将日志级别调回
info，撤销临时测试项，保存最终有效配置。
排查顺序可以固定为：配置是否加载 → 本地端口是否监听 → 域名是否解析 → 规则命中是否符合预期 → 节点与目标是否连通。先处理链路中最早失败的一环，再看后续错误。这样既能减少重复修改，也能避免把同一次失败产生的多条日志误认为多个独立故障。