Clash 报错日志怎么看：Clash Verge Rev 常见错误与排查步骤
简答：先复制日志中第一条与失败请求直接相关的 error 或 warning，再按“配置验证→DNS→节点连接→本地端口→规则策略”的顺序排查。Windows 上 Clash Verge Rev 的应用日志通常位于 %APPDATA%\io.github.clash-verge-rev.clash-verge-rev\logs；如果是内核或 TUN 问题，还要检查 service、sidecar 或服务日志目录。
定义：Clash 报错日志是 Clash Verge Rev 应用层、mihomo 内核、订阅更新或 TUN 服务记录的运行信息，用于判断配置、解析、连接、端口和规则在哪一层失败。
先做这一步：找到正确日志并复现一次
本文是第三方使用指南，不是 Clash Verge Rev 官方页面。目标是帮助你读取本机日志，不判断任何未核实的品牌服务状态。
- 打开 Clash Verge Rev，进入日志或设置中的日志相关页面，先记下当前时间。
- 如果日志级别可以选择，临时切换到
debug；mihomo 文档说明，debug会输出运行期间尽可能多的信息，info则主要输出一般运行信息以及 warning 和 error。复现结束后建议改回info，避免日志过多。mihomo：全局配置与日志级别说明 - 只进行一次明确操作，例如更新订阅、打开一个网页或启动 TUN，然后复制该操作前后约 20—50 行日志。
- Windows 应用日志可先检查
%APPDATA%\io.github.clash-verge-rev.clash-verge-rev\logs。Clash Verge Rev 项目说明配置和日志保存在本机；其隐私说明还提醒，日志可能包含代理地址、订阅令牌、访问域名和连接元数据。Clash Verge Rev：隐私说明与本地日志位置 - 如果应用日志只显示界面或配置任务信息，再检查日志目录中的
service、sidecar子目录；这些位置可能记录服务模式或 mihomo 内核过程。相关目录结构和日志排查方式可参考项目问题记录，但具体路径可能随版本变化。Clash Verge Rev：应用日志与 service、sidecar 日志排查记录
不要先看最后一行。一次失败通常会产生连续报错，例如 DNS 失败后又出现超时、规则失败或连接重试。优先看首次出现、且紧跟在你刚才操作之后的错误。
Clash 报错日志速查表：复制关键词再处理
| 日志关键词或原文 | 优先判断 | 先做什么 | 处理方向 |
|---|---|---|---|
yaml: line、unmarshal、mapping values | 配置文件格式或字段解析失败 | 查看报错行号，检查缩进、冒号、引号和是否混入 Tab | 重新下载或重新导入配置；不要只删掉报错行，先确认字段结构 |
unsupported proxy type | 当前内核不识别节点协议或字段 | 确认实际使用的内核和配置协议类型 | 换用兼容配置或更新到项目发布页提供的版本；版本号以发布页为准 |
no such host、dns resolve failed | 域名解析失败 | 区分失败对象是目标网站、代理节点域名还是 DNS 服务器域名 | 检查 DNS 配置、节点域名拼写和系统网络；不要把 fake-ip 地址当成真实网站 IP |
i/o timeout、context deadline exceeded、handshake timeout | 连接或握手在规定时间内没有完成 | 同一节点重试一次，再换一个节点对比 | 检查本地网络、节点可达性、协议兼容性和系统时间；若只有一个节点失败，优先怀疑该节点或其协议参数 |
connection refused | 目标端口主动拒绝连接 | 确认目标是本地代理端口、节点端口还是网站端口 | 本地端口检查监听程序；节点端口则检查配置和服务端状态，不能仅凭一行日志断定服务已失效 |
connection reset、unexpected EOF、EOF | 连接被对端或中间网络提前关闭 | 记录节点、目标域名和发生时间，换节点或换目标验证 | 检查协议、TLS、SNI、传输方式和网络稳定性；不要直接把 EOF 等同于订阅失效 |
invalid header | 收到的数据不像当前协议预期格式 | 核对节点类型、端口、TLS 和传输参数 | 重新导入正确配置，确认没有把一个协议的端口填入另一种协议 |
bind: address already in use、address already in use | 本机端口或临时绑定地址冲突 | 关闭重复运行的客户端，检查 7890、9090 或配置中的其他监听端口 | 结束占用进程或修改监听端口；mihomo 官方问题记录也显示该错误可能出现在 UDP 连接的地址绑定过程中，不能只按 HTTP 代理端口处理。mihomo：address already in use 日志示例 |
proxy group not found | 规则引用了不存在的策略组 | 检查规则最后一列的策略组名称是否与 proxy-groups 中完全一致 | 修正名称、补齐策略组或重新生成配置；大小写、空格和符号都可能影响匹配 |
Network Error、401、403、404 或返回 HTML | 订阅更新请求未得到预期配置内容 | 在浏览器或订阅管理器中确认链接是否仍返回配置文本，注意不要公开完整链接 | 检查链接、权限、网络和订阅内容格式；如果返回登录页或错误页，不能直接导入为 YAML |
上表是排查优先级，不是对每一条错误的绝对定性。同一个关键词可能出现在不同阶段，必须结合时间、目标地址、节点名称和前后两行一起判断。
按故障阶段排查：配置、DNS、节点、端口和规则
1. 配置解析失败：先不要启动 TUN
日志出现 yaml、unmarshal、mapping values 或配置验证失败时，优先处理配置本身。打开配置编辑器，检查报错行附近的缩进是否统一、键名后是否有冒号、字符串中是否缺少引号，以及策略组名称是否在引用前已经定义。若配置来自订阅，先重新更新一次；如果只有某一份配置失败，不要通过反复重装客户端来解决。
2. DNS 失败：先分清解析的是谁
no such host 可能表示目标网站域名无法解析，也可能表示代理节点域名无法解析。mihomo 的 DNS 配置中，nameserver 用于常规域名解析，proxy-server-nameserver 专门用于解析代理节点域名；启用 fake-ip 时，文档示例使用 198.18.0.1/16 作为 fake-ip 地址范围。因而在 fake-ip 或 TUN 场景下看到 198.18.x.x，不能单独据此判断 DNS 已经异常。mihomo：DNS 配置、fake-ip 与节点域名解析
可操作检查：先关闭 TUN，仅保留系统代理，测试同一网页；再恢复 TUN，观察是否从“能打开”变成“DNS 失败”。如果只在 TUN 下失败，重点检查 DNS 劫持、fake-ip 过滤、虚拟网卡和规则，而不是立即更换节点。
3. 超时、EOF 和 invalid header：用对照实验缩小范围
- 保持同一个目标网站，换一个节点。
- 保持同一个节点，换一个普通目标网站。
- 关闭 TUN，仅使用系统代理再测试。
- 如果客户端支持，在 Rule 与 Global 模式之间切换一次；Global 模式需要选择具体代理或策略组。
只有某个节点失败，优先检查该节点的地址、端口、协议和 TLS 参数；所有节点都失败，优先检查本地网络、系统代理、DNS 或客户端内核是否正常启动。不要把“能打开控制页面”当成“代理链路一定正常”，控制页面通常只证明本地客户端进程仍在运行。
4. 端口占用：Windows 先查监听者
在 Windows PowerShell 中执行以下命令，查看常见端口是否被其他进程占用：
Get-NetTCPConnection -LocalPort 7890,9090 -ErrorAction SilentlyContinue | Format-Table -AutoSize
如果需要确认进程，可继续执行：
Get-NetTCPConnection -LocalPort 7890,9090 -ErrorAction SilentlyContinue | Select-Object LocalAddress,LocalPort,State,OwningProcess
拿到 OwningProcess 后，再执行：
Get-Process -Id 进程号
确认是重复运行的 Clash Verge Rev、其他代理客户端或开发工具后，再结束重复进程或在客户端设置中修改监听端口。不要在无法确认进程用途时直接结束系统服务。
5. 规则和策略组：看日志里的 MATCH 与出口
一行连接日志通常至少要看目标域名、命中的规则、最终策略组或出口，以及末尾的错误。出现 MATCH 不一定代表规则失效，它可能只是表示请求落到了最后的兜底规则；真正需要确认的是该规则选择了 DIRECT、某个代理组，还是一个不存在的组。若出现 proxy group not found，优先检查策略组名称；若请求总是直连，则检查规则顺序和最后的兜底规则。
Clash Verge Rev 没有可用日志时怎么办
- 日志页为空：确认日志等级不是
silent，并在切换到debug后重新复现。mihomo 文档说明日志等级控制的是内核输出到控制台和控制页面的内容。mihomo：日志等级定义 - 界面打不开或只有托盘图标：这类问题可能发生在应用界面层，不能只查内核日志。Clash Verge Rev 的 Windows FAQ 将 WebView2 列为界面显示依赖，建议先检查 WebView2 是否被卸载、禁用或安装异常。Clash Verge Rev：Windows 常见问题
- 内核无法加载：检查应用日志中是否有配置验证失败、内核文件缺失或服务启动失败；不要只查看客户端窗口里的实时日志。
- 更新订阅后立刻报错：先确认新配置能否通过客户端的配置验证，再测试节点。若订阅返回的是 HTML、登录页或错误提示，保存该页面并不能解决配置解析问题。
如果准备提交日志给客服或项目维护者，至少遮挡订阅链接中的令牌、节点密码、UUID、完整服务器地址和不必要的访问域名。Clash Verge Rev 项目隐私说明明确提醒，配置和日志可能包含这些信息。Clash Verge Rev：日志与配置中的敏感信息提醒
修复后如何确认问题真的解决
- 配置错误：重新加载配置时不再出现验证失败，并能看到配置中的代理组。
- DNS 错误：同一域名连续测试两次，日志不再出现
no such host；fake-ip 模式下不要把198.18.x.x本身当作失败依据。 - 节点超时：至少用同一节点访问两个不同目标，确认不是只打开了客户端控制页面。
- 端口冲突：重启客户端后监听端口仍只有一个有效进程占用。
- 规则错误：查看目标请求的命中规则和最终出口，确认没有落入不存在的策略组或错误的 DIRECT。
如果修复后仍失败，保留一份最小日志：时间、客户端和内核版本、触发动作、第一条错误、目标类型、命中规则、使用的节点名称，以及你已经做过的对照测试。不要上传完整配置和完整订阅链接。
常见问题
Clash 报错日志一般在哪里看？
Windows 上先看 Clash Verge Rev 的日志页面和 %APPDATA%\io.github.clash-verge-rev.clash-verge-rev\logs 目录。如果问题涉及内核、TUN 或服务模式，再检查 logs 下的 service、sidecar 或服务日志目录；不同版本的具体子目录可能变化。
看到 no such host 就一定是节点失效吗？
不一定。no such host 可能是目标网站域名、代理节点域名或 DNS 服务器域名解析失败。应先看错误行中的域名，再分别检查 DNS 配置、节点地址和本地网络。
Clash 日志里的 198.18.x.x 是异常地址吗？
在 mihomo 的 fake-ip 模式中，198.18.0.1/16 是文档示例使用的 fake-ip 地址范围，因此看到 198.18.x.x 不能单独证明连接失败。应继续查看目标域名、命中规则和后续连接结果。
为什么日志里一直出现 bind: address already in use？
通常表示某个本地监听或临时绑定地址已被占用。先关闭重复运行的客户端，再用 PowerShell 查询 7890、9090 或配置中的端口对应进程；如果是 UDP 连接场景，还要结合目标地址和协议继续判断。
应该把完整 Clash 日志发给别人排查吗？
不建议直接发送。先遮挡订阅令牌、节点地址、密码、UUID、访问域名和本地用户名，只保留触发时间、错误关键词、命中规则和必要的前后文。