Clash Verge Rev 节点全部显示超时排查清单
代理页面一片红，所有节点后面都挂着 Timeout，但浏览器还能正常打开网页——这种“测速全红、上网正常”的割裂状态，是 Clash Verge Rev 节点全部显示超时最容易被误判的场景。很多人第一反应是订阅挂了或机场跑路，实际上测速超时和实际连通性是两个独立层面的事。Clash Verge Rev 的延迟测试由 Mihomo 内核向一个指定 URL 发起请求来测量响应时间，这个测试链路本身可能因为配置、模式或 DNS 问题而失败，而节点本身完全健康。下面按“先判断真假超时，再查测速链路，最后查节点本身”的顺序拆开。
01. 先分清是测速超时还是节点真不可用
打开浏览器，随便访问一个需要代理的网站。能正常打开，说明节点实际可用，问题出在延迟测试链路本身，不必动订阅。打不开，才是节点或订阅层面的故障。
这个区分很重要，因为两者的排查路径完全不同。测速超时但上网正常，根源通常在测试 URL、代理模式或 DNS 解析上；上网也失败，才需要检查订阅是否过期、机场是否跑路、本机网络是否正常。遇到 Clash Verge Rev 节点全部显示超时，先做这一步判断，能省掉一半无效排查。
在 Clash Verge Rev 的“代理”页面，延迟数值和节点可用性没有必然对应关系。一个显示 Timeout 的节点，可能只是测速请求没收到响应，但实际代理流量走得好好的。反过来，显示 50ms 的节点也可能因为带宽耗尽而体验极差。
| 现象 | 可能原因 | 快速验证 |
|---|---|---|
| 测速全红但网页能开 | 测速链路问题 | 浏览器访问需代理的网站验证 |
| 切 Global 后全部超时 | testUrl 被 Filter 污染 | 清空 Filter 与 DelayCheckUrl 再测 |
| 开机后短时全部超时 | 启动竞态 | 重启客户端后复测 |
| 日志有 dns resolve failed | DNS 解析失败 | 测速 URL 改为 IP 地址验证 |
| 测速与上网同时失败 | 订阅缓存过时或 IP 被封 | 手动更新订阅后复测 |
02. Global 模式下的 testUrl 污染：最隐蔽的误报源
Clash Verge Rev 的延迟测试依赖一个 testUrl 参数，内核向这个 URL 发请求来测量延迟。正常情况下它应该是 https://cp.cloudflare.com/generate_204 或 http://www.gstatic.com/generate_204 这类轻量地址。但在 Global 模式下，有一个已知问题会让 testUrl 被错误替换。
有用户报告：Rule 模式下所有节点测速正常，切到 Global 模式后全部 Timeout，但节点实际可以联网。DevTools 日志显示，Global 模式下请求的 testUrl 变成了用户自己填写的过滤关键词——该用户在 DelayCheckUrl 和 Filter 两个输入框中都填了“香港”，导致 Global 模式的测速请求把“香港”当成了测试 URL。
自查方法：切到 Global 模式前，检查“代理”页面顶部的 Filter 输入框和设置中的 DelayCheckUrl 是否都为空。如果有内容，清空后再测速。如果清空后 Global 模式恢复正常，就是这个原因。该问题已有 PR 修复，但如果你使用的版本尚未包含，避免在 Global 模式下依赖延迟测试结果即可。
03. 启动竞态与进程残留
如果超时集中出现在开机自启或刚从休眠唤醒时，手动重启客户端又能恢复，大概率是启动竞态。Mihomo 内核还在解析配置、创建命名管道的时候，GUI 已经发起了首次延迟测试请求，内核来不及响应，全部节点报 Timeout。
这与代理页面空白是同一类 IPC 时序问题。判断依据：日志中错误时间戳集中在启动后 1-2 秒内，且重启客户端后测速恢复正常。手动绕开的方法同样是先以系统代理模式启动，待界面正常后再切换 TUN。
另一种情况是残留进程导致管道或端口被占。从托盘退出后，任务管理器里如果还有 verge-mihomo.exe 残留，新启动的内核可能无法正常接管测速请求。以管理员身份运行 PowerShell 清理：
Get-Process | Where-Object { $_.ProcessName -like "*mihomo*" } | Stop-Process -Force等待几秒后重启客户端再测速。
04. DNS 解析失败导致测速请求发不出去
延迟测试的本质是内核向 testUrl 发起 HTTP 请求。如果内核无法解析这个 URL 的域名，请求根本发不出去，结果就是全部 Timeout。这种情况在代理节点本身正常、但 DNS 配置有缺陷时尤其常见。DNS 解析失败同样会让 Clash Verge Rev 节点全部显示超时，只是这一层原因不容易被直观看到。
Mihomo 内核在发起测速请求时，需要先解析 testUrl 的域名。如果订阅的 DNS 配置中 nameserver 或 fallback 指向的 DNS 服务器不可达，或者 Fake-IP 模式与某些测速 URL 不兼容，解析就会失败。日志中可能出现 dns resolve failed 或 couldn't find ip 之类的报错。
快速验证：把 testUrl 改成 IP 地址而不是域名，测速看是否恢复。在 Clash Verge Rev 的设置中找到“延迟测试 URL”或类似选项，填入 http://1.1.1.1 测试。如果 IP 能通、域名不通，问题就锁定在 DNS 解析。
修复方向是检查当前订阅的 DNS 配置。如果使用的是机场提供的配置且不便修改，可以在 Clash Verge Rev 的 Merge 或 Script 中覆写 DNS 设置，将 nameserver 指向一个可靠的本地 DNS（如 223.5.5.5），或者启用 enhanced-mode: fake-ip 配合可用的 Fake-IP 过滤规则。
05. 订阅缓存过时与节点信息失效
如果测速超时同时伴随实际上网也失败，需要检查订阅缓存。Clash Verge Rev 默认会缓存上一次成功下载的订阅内容，机场更换服务器 IP 后，本地缓存仍然指向旧地址，连接时就会一直超时。订阅缓存过时是 Clash Verge Rev 节点全部显示超时里最直接的一类原因，验证成本也最低。
在“订阅”页面手动点击更新按钮，强制拉取最新配置。如果更新失败，说明订阅域名本身可能不可达，到机场后台确认套餐状态和订阅地址是否仍然有效。更新成功后重新测速，如果超时消失，就是缓存过时的问题。
还有一种容易被忽略的情况：订阅更新成功但节点列表中的节点 IP 已经被封锁。这种情况下测速和上网都会失败，但订阅本身是正常的。判断方法是查看代理页面的节点数量是否与之前一致，如果数量没变但全部超时，可能是机场的落地 IP 被批量封锁，需要联系服务商确认。如果排查完以上场景仍未解决，可以到 FAQ 页面 搜索日志中的完整错误信息，或参考 TUN 模式完全指南 中关于内核启动顺序的说明。