Clash Verge Rev 故障排查手册：25 类常见问题按症状分类的完整解决方案

遇到问题时，最高效的排查方式不是逐个试各种网上流传的「偏方」，而是按链路顺序一层层排除。这篇手册把常见问题按症状分成七大类，每类都给出从最常见到最少见的排查顺序。

先说一个通用的方法论：先确定问题出在哪一层，再针对性地解决。

应用层（浏览器/软件本身）
   ↓
系统层（系统代理/网卡）
   ↓
客户端层（配置是否正确加载）
   ↓
规则层（是否按预期匹配）
   ↓
节点层（出站服务器是否可用）
   ↓
订阅层（配置来源是否正常）

从下往上查，通常比从上往下猜要快得多。

七类症状速查表

第一类：启动与安装问题

症状 1.1：双击后完全没反应

按顺序检查：

1. 进程是否残留 — 打开任务管理器，查找有无同名进程，有则结束后重试
2. 安装路径权限 — 装在系统受保护目录时可能无法写入配置
3. 防火墙/杀软拦截 — 临时关闭后测试能否启动

症状 1.2：提示缺少运行库

Windows 11 一般自带 WebView2，此问题集中在 Windows 10。

症状 1.3：macOS 提示「应用已损坏」

极有可能是下错了芯片版本。确认处理器类型后重新下载对应安装包。

若版本正确却仍提示，可能是 Gatekeeper 拦截，可在「系统设置」→「隐私与安全性」中手动放行。

症状 1.4：启动后立即闪退

排查顺序：

1. 检查上述运行库是否齐全
2. 备份后删除配置目录，重新启动测试（配置文件损坏是常见原因）
3. 检查是否有安全软件在后台阻止

第 2 步能解决相当比例的闪退问题，因此在删之前请务必先备份。

第二类：订阅与配置问题

症状 2.1：订阅导入失败

这是最高频的问题。按可能性从高到低：

① 链接本身失效

把链接粘到浏览器地址栏，看能否返回内容。返回错误信息或无法打开，说明链接已过期或被限制。

② 请求频率过高被暂时限制

若你设置了很短的自动更新间隔（如每小时），部分服务会临时封禁。解决：延长更新间隔到 24 小时，等待一段时间后重试。

③ 本地网络无法连通订阅地址

值得注意的循环依赖情况：订阅地址本身需要代理才能访问，但代理又依赖该订阅的配置。处理方式是在更新订阅时先临时关闭代理。

④ 链接含未转义的特殊字符

特别是包含 &、? 的长链接，某些场景下会被截断。

⑤ 系统时间偏差过大

时间错误会导致 TLS 证书校验失败。同步系统时间后重试。

症状 2.2：配置加载后节点数为 0

可能原因：

• 配置文件本身不含有效节点
• Merge 去重导致大面积过滤
• 代理组未包含任何节点

检查方法：查看日志中实际加载的 proxy 数量，再与源文件内容比对。

症状 2.3：Merge 修改后不生效

Merge 的合成结果在加载配置时生成。修改文件后必须手动重新加载或重启应用。

第三类：连接完全失败

症状 3.1：开启代理后所有网站都打不开

先做一个关键判断：关闭代理，网络是否恢复正常？

• 恢复正常 → 问题在客户端，继续往下排查
• 仍然不通 → 问题在网络本身，与客户端无关

若确认是客户端问题：

1. 检查系统代理开关 — 底部状态栏左侧的开关是否为开启状态
2. 确认模式 — 若在「直连」模式下，流量本就不会走代理
3. 查看日志 — 看请求是否有任何输出记录
4. 测试节点可用性 — 在「代理」页对节点做延迟测试

症状 3.2：浏览器能走代理，其他软件不行

这是正常现象。系统代理模式下，只有遵循系统代理设置的程序才会走代理。

需要全部接管流量请开启 TUN 模式，详见第六类。

症状 3.3：局域网内其他设备无法通过本机使用

检查三点：

1. 软件设置中的「允许局域网连接（Allow LAN）」是否开启
2. 本机防火墙是否放行了该端口
3. 其他设备配置的代理地址与端口是否正确

第四类：部分网站无法访问

症状 4.1：特定网站始终打不开

这是规则问题的最典型表现。 定位方法：

1. 打开「日志」页，切换到 debug 级别
2. 访问该网站
3. 查看日志中该请求命中了哪条规则

日志里会有类似这样的输出：

match(DOMAIN-SUFFIX,example.com) using DIRECT

如果显示的是 DIRECT 而你期望的是代理，说明有直连规则提前命中了。

临时验证方法：切换到「全局模式」测试。全局模式下能访问 = 确认是规则问题。

修复方式：在规则文件中为该域名添加一条优先级更高的规则。注意规则是从上往下、命中即停的，因此新规则要放在冲突规则之前。

症状 4.2：国内网站反而变慢

说明这些网站走了代理而非直连。检查：

1. GEOIP,CN,DIRECT 规则是否存在且位置靠前
2. 是否有宽泛的代理规则排在前面

症状 4.3：某些应用报证书错误

通常与 DNS 或 HTTPS 解密相关。检查：

1. DNS 配置是否合理
2. 是否启用了不必要的中间人-like 处理

第五类：网速慢与延迟高

症状 5.1：整体网速明显慢

排查顺序：

① 先测直连速度

关闭代理测速。若直连本身就慢，问题与客户端无关，应排查本地网络。

② 换节点对比

在「代理」页做延迟测试，选延迟最低的节点手动指定，再测速对比。若换节点后明显改善，说明是原节点质量问题。

③ 检查是否开了 TUN

TUN 多一层虚拟网卡，会带来额外开销。若非必需，关闭后对比测速。

④ DNS 配置

DNS 解析慢会显著影响首次访问速度。可尝试调整 DNS 设置后对比。

症状 5.2：首次打开慢，之后正常

典型的 DNS 解析慢表现。检查 DNS 配置，确认是否使用了响应较快的解析器。

症状 5.3：某些节点延迟测试很快但实际很慢

延迟测试只反映 ICMP/TCP 握手时间，不代表实际吞吐量。两者不一致是常态，尤其是高倍率节点。

建议以实际下载速度为准，而非单纯的延迟数值。

第六类：TUN 模式相关问题

症状 6.1：TUN 开关打不开

创建虚拟网卡需要管理员/root 权限：

• Windows — 需要允许 UAC 提权
• macOS / Linux — 需要输入管理员密码

另外请检查是否有安全软件阻止创建网卡。

症状 6.2：开启 TUN 后网络断开

排查顺序：

1. DNS 配置冲突 — TUN 改变了 DNS 处理方式，尝试调整 DNS 设置
2. 虚拟网卡冲突 — 同时运行多个创建虚拟网卡的软件容易冲突，关闭其他同类软件测试
3. 路由规则过宽 — 若全部流量都走代理，本地服务访问会异常
4. 网卡驱动异常 — Windows 可在设备管理器卸载虚拟网卡后重新开启，让其重建

症状 6.3：TUN 开了但依然是系统代理效果

确认 TUN 确实处于开启状态。另外注意，某些基于进程名的规则必须依赖 TUN 才能工作——这不是故障，而是两种模式的机制差异。

第七类：间歇性断流与稳定性

症状 7.1：用一段时间后就断

可能原因：

1. 节点不稳定 — 换节点测试
2. 自动切换策略 — 若使用了 failover 或 url-test 类型的代理组，节点波动时会频繁切换
3. 订阅更新打断 — 自动更新会导致短暂重载

症状 7.2：白天正常，晚上变差

通常是节点在高峰时段拥塞，与客户端本身无关。这是共享型节点的固有特性。

症状 7.3：软件运行几天后变卡

可能起因：

• 日志级别过高（debug 持续写磁盘）
• 内存碎片累积
• 日志堆积

处理：降低日志级别、重启应用、清理旧日志。

通用诊断流程

当你遇到上述未涵盖的问题时，建议按这个顺序自查：

第 0 步：确认基础网络
        ↓ 关闭代理后能否正常上网？
第 1 步：确认代理开关
        ↓ 状态栏总开关是否为开？当前模式是否正确？
第 2 步：确认配置有效性
        ↓ 节点数量是否正常？是否有节点可用？
第 3 步：查看日志
        ↓ 请求是否命中了预期规则？
第 4 步：简化变量
        ↓ 切全局模式 / 换单一节点，逐一排除
第 5 步：重置配置
        ↓ 备份后恢复默认配置重新导入

第 3 步往往是最关键的 —— 日志会明确告诉你每个请求命中了哪条规则、走了哪个出站。绝大多数「莫名其妙」的问题，在日志面前都很清晰。

寻求帮助前的准备

若需向社区求助，提前准备这些信息能大幅提高获得有效帮助的概率：

1. 软件版本 — 「设置」页可查看
2. 操作系统版本
3. 相关日志片段 — 隐去敏感信息后提供
4. 已尝试过的操作 — 避免他人重复建议
5. 问题的可复现性 — 是否必现

小结

排查问题的核心心法其实就两句话：

第一句：先确定问题在哪一层。 大部分时间其实花错了地方——很可能是网络本身或节点质量问题，而非软件配置。

第二句：用日志替代猜测。 一个明确说明命中了哪条规则的日志记录，胜过十种「试试改这个」的建议。

养成这两个习惯之后，你会发现大部分问题几分钟就能定位。