Clash Verge Rev 延迟测试失败怎么排查？
简答：Clash Verge Rev 延迟测试失败时，先测试一个节点能否打开实际网页，再判断是单节点、部分节点还是全部节点失败。网页能打开，优先检查测速 URL、响应状态和超时设置；网页也打不开，再检查订阅是否加载、mihomo 内核、端口、DNS、系统代理和 TUN。Timeout、Error、0ms 或 -1 通常表示这次测试没有得到可用延迟结果，但具体含义仍要结合当前版本、日志和实际访问判断。
定义：Clash Verge Rev 延迟测试是通过选定代理向测速 URL 发起请求并记录响应时间的检查，不等同于下载测速、网页完整加载或节点长期可用性。
先做 1 分钟自查：四项结果决定下一步
本站是第三方使用指南站，下面只整理项目资料、mihomo 文档和公开问题记录能够支持的排查方法。先不要批量更新订阅或删除配置，完成下面四项记录：
- 范围：是一个节点失败、同一组部分节点失败，还是所有节点都失败？
- 实际访问：选中一个节点后，网页或目标应用能否正常访问？
- 内核状态：代理页面是否能刷新，日志是否持续产生，配置是否处于运行状态？
- 接管方式：当前使用系统代理还是 TUN？关闭 TUN 后是否有变化？
最快判断：网页能打开而延迟测试失败，先查测速 URL、超时和响应状态；网页也打不开，先查内核、订阅、端口、DNS 和系统接管。每次只改一个变量，并记录改动前后的结果。
| 现象 | 优先检查 | 判断标准 | 处理方向 |
|---|---|---|---|
| 只有一个节点失败 | 节点协议、远端状态、测速超时 | 其他节点能返回延迟或实际访问正常 | 换同组节点对照，保留失败节点名称和日志 |
| 部分节点失败 | 共同地区、协议、代理组和测速地址 | 失败节点存在共同配置特征 | 查看组配置，换测速 URL 后只测一个节点 |
| 全部节点 Timeout 或 Error | 订阅、内核、本机网络、DNS、端口 | 测速和实际网页访问都失败 | 先确认内核运行，再检查本地监听和系统接管 |
| 测速失败但网页能打开 | 测速 URL、expected 状态、timeout | 同一节点能访问实际目标 | 更换测速地址并做前后对照，不急着换订阅 |
| 0ms 或 -1 | 当前版本界面、API 返回和日志 | 没有可用延迟结果或结果未被界面正常呈现 | 结合实际访问和日志判断，不能仅凭数字下结论 |
六步排查：从单节点测试到本机接管
- 只测试一个节点。在当前客户端界面展开代理组，选择一个节点执行延迟测试，不要一开始连续批量点击整组测速。记录节点名称、显示结果、测速时间和当前网络。如果一个节点成功、其他节点失败，问题范围更接近部分节点或共同配置；如果所有节点都失败，再进入本机和内核检查。
- 确认配置已启用且节点列表正常。在配置或订阅页面确认目标配置处于当前使用状态，节点列表不是空白，最近一次更新没有报错。订阅地址能下载、配置能解析、内核能加载是三个不同环节，不能只凭浏览器打开订阅地址就认定客户端已正常使用。更新前先保留旧配置和订阅地址，失败时优先回滚。
- 确认 mihomo 内核和本地控制接口正在工作。项目隐私说明指出，实际代理和 DNS 解析由随应用提供的 mihomo 内核完成；代理端口和内部控制端口默认只绑定到
127.0.0.1。如果代理列表不刷新、日志没有新记录或本地接口无响应，应先停止并重新启动当前配置，观察日志是否恢复。Clash Verge Rev 项目隐私说明 - 更换测速 URL做对照。项目资料说明，手动测试代理或代理组时会通过代理请求
http://cp.cloudflare.com/generate_204，也可以使用用户配置的测试 URL。mihomo 的 URL-Test 代理组也通过配置中的url发起健康检查。若网页能打开但测速失败，可在当前版本界面找到测速或代理组相关设置，替换为你能访问且会快速返回的测试地址，然后只复测一个节点。mihomo URL-Test 配置文档 - 检查 timeout 和 expected。mihomo 延迟测试 API 使用
url与timeout参数，还可以用expected指定可接受的 HTTP 状态码范围。超时过短，可能使响应较慢的节点显示失败；超时过长，又会让真正不可用的节点等待更久。只建议做一次适度调整，并记录调整前后结果，不要把一次成功当作长期稳定证明。mihomo API 文档 - 最后检查本机网络接管。确认系统时间没有明显错误，测速域名能够解析，系统代理指向当前客户端显示的本地端口，并排除其他代理软件、VPN 或虚拟网卡冲突。如果启用了 TUN，先记录原状态，暂时关闭后复测一次；若普通系统代理恢复而 TUN 下失败，应继续检查 TUN 权限、路由和虚拟网卡，而不是立即删除配置。
排查纪律：一次只改变测速 URL、timeout、系统代理或 TUN 中的一项；恢复原设置后再进行下一项。这样才能知道结果变化来自哪里。
可直接复制的最小验证清单
下面的命令只验证对应层级，不会替代完整的网页访问测试。示例中的域名、端口和代理名称需要换成你当前环境的值。
Windows：解析、端口和 API
- 检查域名解析：
nslookup example.com - 检查客户端界面显示的本地端口：
Test-NetConnection 127.0.0.1 -Port 端口号 - 如果你已确认控制端口和鉴权方式，可读取代理列表：
curl.exe -H "Authorization: Bearer 你的密钥" "http://127.0.0.1:控制端口/proxies" - 对单个代理发起延迟测试：
curl.exe -H "Authorization: Bearer 你的密钥" "http://127.0.0.1:控制端口/proxies/代理名称/delay?url=http%3A%2F%2Fcp.cloudflare.com%2Fgenerate_204&timeout=5000"
mihomo 文档说明，单个代理延迟测试接口是 /proxies/{proxies_name}/delay，需要提供 url 和 timeout，也可以提供 expected。代理名称包含空格或特殊字符时，应先进行 URL 编码。mihomo API 延迟测试接口
macOS 和 Linux：解析、端口和接口
- 检查解析：
nslookup example.com或dig example.com - 检查本地端口：
nc -vz 127.0.0.1 端口号 - 在确认控制端口和密钥后，使用与 Windows 相同的 API 路径；macOS 和 Linux 可使用：
curl -H 'Authorization: Bearer 你的密钥' 'http://127.0.0.1:控制端口/proxies' - 若启用 TUN，检查虚拟网卡和路由是否出现异常；先关闭 TUN 做一次普通系统代理对照，不要在没有备份和回滚方案时修改系统路由。
如果不知道控制端口或鉴权密钥，不要猜固定值。应在当前版本的客户端设置、运行配置或日志中查看；无法确认时，使用界面中的单节点测速和日志检查即可。
日志关键词：把 Error、Timeout 分成不同方向
日志结果只能说明某一层发生了什么，不能单独证明节点一定失效。项目说明显示，核心日志可能包含请求域名、IP 地址和连接元数据，分享前应脱敏。项目隐私说明中的日志与数据说明
| 关键词 | 可能涉及的层级 | 下一步验证 |
|---|---|---|
timeout、context deadline exceeded | 测速地址、节点响应、网络路径或超时阈值 | 换测速 URL，只测一个节点，并对比实际网页访问 |
connection refused、dial failed | 本地端口、内核监听或远端连接 | 先检查内核状态和本地端口是否监听 |
DNS、resolve、no such host | 域名解析 | 使用 nslookup 或 dig 对比直连解析和客户端日志 |
TLS、handshake、certificate | 系统时间、目标地址、协议兼容性或证书握手 | 核对系统时间和目标地址，不要通过关闭安全校验来验证成功 |
invalid、parse、yaml | 订阅内容或配置解析 | 保留旧配置，重新获取配置并查看解析错误位置 |
如果日志中没有对应请求记录，可能是测试请求未发出、日志级别不足，或界面没有记录该动作，不能直接等同于“没有经过当前节点”。公开 Issue 只能证明特定版本、系统或环境中的现象；其中的复现和处理方式不能直接推广到所有版本。Clash Verge Rev 公开 Issue：部分节点延迟测试超时
Windows、macOS、Linux 分别怎么收尾
Windows
- 先确认系统代理开关指向当前客户端，并用界面显示的端口检查本地监听。
- 如果 TUN 已启用，记录开关状态后暂时关闭复测，用于区分系统代理与虚拟网卡接管。
- 需要管理员权限或系统服务时，优先使用当前客户端提供的服务入口；操作前备份配置，完成后按原状态恢复。
macOS
- 检查系统代理是否仍指向当前客户端，确认应用没有被系统权限或后台服务阻止。
- 如果服务模式或 TUN 异常，先用普通系统代理做对照测试。
- 重新安装前保存配置文件、订阅地址和原有接管状态；不要先删除应用数据。
Linux
- 确认桌面环境的系统代理和客户端本地端口一致。
- 使用 TUN 时检查虚拟网卡、路由和权限；关闭 TUN 后恢复，只能说明问题范围缩小到接管层，不能直接证明节点正常。
- DNS 命令、端口命令和网页请求分别验证不同层级，不要用其中一项替代全部结论。
项目发布页当前列出多个历史版本，使用哪个版本应以你打开发布页时显示的版本和对应系统安装包为准。升级前备份配置，升级后若内核、服务或系统代理异常，先回到原配置和原接管模式复测。Clash Verge Rev 项目发布页
什么时候更新订阅、换节点或重装
- 更新订阅：节点列表为空、配置解析失败、订阅更新明确报错，或服务提供方确认配置已经变更时再做。更新前保留旧配置。
- 换节点：仅一个或少数节点失败，而其他节点和实际访问正常时，先换同组节点做对照。
- 切换网络：当前网络下所有节点和测速地址都失败，另一条网络能够恢复时，问题可能与当前网络、DNS 或路径有关。
- 重装客户端：完成配置备份、版本核对、内核重启、测速 URL 和权限排查后仍无法启动，才考虑重装。
- 反馈问题：整理发生时间、系统、客户端版本、节点名称、错误关键词和脱敏日志，不要公开订阅链接、密码、完整配置或控制接口密钥。
推荐入口
如果你已经完成单节点、测速 URL、端口和实际访问对照，仍需要进一步记录跨网络延迟、丢包与线路差异，可以了解边界云加速的连接诊断服务。
常见问题
Clash Verge Rev 显示 Timeout，是不是订阅失效了？
不一定。Timeout 通常表示这次延迟测试没有在设定时间内得到可用结果，可能与测速 URL、节点响应、DNS、网络路径或超时设置有关。先测试一个节点的实际网页访问，再看其他节点是否也失败；只有节点列表、配置解析和实际访问同时异常时，才应重点检查订阅。
延迟测试失败但网页可以打开，应该怎么处理？
优先检查测速 URL、代理组配置、expected 状态和 timeout。项目资料显示，延迟测试会请求默认或自定义测试地址；因此测速地址本身不可达或响应状态不符合预期时，可能出现测速失败但网页正常。更换测试地址后只复测一个节点，并记录前后结果。
0ms、-1 和 Error 分别代表什么？
不同版本、内核和界面对这些状态的呈现可能不同。它们通常表示客户端没有获得可用的延迟结果、请求失败或结果未正常呈现，不能仅凭数字认定节点已经失效。应结合当前版本、日志和实际网页访问判断。
所有节点都是 Timeout，先检查哪里？
先确认配置已启用、节点列表正常、mihomo 内核正在运行，再检查客户端显示的本地端口、系统代理和 DNS。若启用了 TUN，记录原状态后暂时关闭并复测，用来区分 TUN 接管问题和节点问题。
可以直接把 timeout 调得很大吗？
不建议直接调到极大值。timeout 过短可能误判响应较慢的节点，过长又会让不可用节点等待更久。先更换测速 URL，再做一次适度调整和前后对照；一次成功不能证明节点长期稳定。
怎么确认延迟测试请求是否真的发出？
可以观察客户端日志是否出现对应的请求、连接或错误记录，也可以在确认控制端口和鉴权方式后调用 mihomo 的代理延迟测试 API。没有日志记录不一定表示请求没有发出，也可能是日志级别不足或界面没有记录该动作。