故障排查

Clash/Mihomo 节点延迟一直不更新？两层 lazy 可能都在休眠

Mihomo 的策略组和 proxy-provider 各有一层 lazy。未被使用的组或节点集合默认可以暂停健康检查，旧延迟不等于节点已经失效。

发布于 2026/9/12 · 更新于 2026/9/12 · 3 项可核验来源

先看重点先看节点是直接写在策略组的 proxies 中，还是由 use 引入 proxy-provider。前者受策略组的 interval 和 lazy 控制；后者还要看 provider 自己的 health-check。两层 lazy 默认都是 true，未被使用时可以不测速，所以旧延迟本身不能证明节点失效。

上午测过一次节点，下午打开客户端，列表里还是同一串毫秒数；备用策略组甚至一直没有延迟。网页能正常打开，你却开始怀疑内核已经不再检查节点。

旧延迟只说明界面没有拿到一轮更近的测试结果，不等于节点已经失效。 Mihomo 默认会让未使用的策略组和节点集合进入 lazy 状态。订阅更新、延迟测试与真实代理流量也是三条不同路径，不能用其中一个数字替另外两条下结论。

interval 到了，为什么仍没测速

策略组的 interval 不为 0 时，才会开启周期测试；但同一层的 lazy 默认是 true。Mihomo 官方文档说明：当前策略组没有被选中时，不执行这层测试。

这很容易出现在备用组。你日常流量走“手动选择”，另一个 url-test 或 fallback 从未成为当前出口，它的延迟历史就可能停在较早时间。等待几个 interval 也未必变化，因为 lazy 决定了这个未使用的组可以继续休眠。

provider 还有自己的规则。proxy-providers 下的 health-check.lazy 同样默认是 true；当这批节点没有被使用时，provider 可以不做健康检查。因此，一份配置可能同时存在策略组 lazy 和 provider lazy，它们不是重复字段。

节点从哪里进入组，决定该看哪一层

最容易混淆的是 proxies 与 use。两者都能让节点出现在策略组里，健康检查的归属却不同。

节点来源	相关检查配置	lazy 的含义
策略组直接列出的 `proxies`	该策略组的 `url`、`interval`、`lazy`	当前组未被选中时，可以不测这批直接成员
通过 `use` 引入的 proxy-provider	provider 的 `health-check`	provider 节点未被使用时，可以不测

官方策略组文档还特别注明，组内 url 只检查该组 proxies 字段中的代理，不会代替 provider 检查由 use 引入的节点。也就是说，节点来自 use，却只在策略组旁边反复改 url 和 interval，可能一直没有改到真正负责 provider 健康检查的那一层。

反过来也一样：provider 的健康检查可以更新这批节点的可用状态，但它不会把一个从未被选中的策略组变成“正在使用”。面板如何合并、显示两层结果取决于具体客户端，判断配置时应以 Mihomo 实际加载的最终配置为准，不要只看订阅转换前的模板。

几种现象分别能说明什么

现象	更合理的解释	仍不能证明
备用组延迟很旧，当前组可正常访问	备用组可能因 lazy 暂停测试	备用节点一定失效
手动测试后数字立即更新	手动测试路径能够返回结果	周期测试配置一定正确
当前组能访问，只有某个测试地址超时	测试目标或健康检查条件可能有问题	实际代理流量一定中断
网页与测速都失败	需要继续排节点、网络、DNS 或账户	只靠关闭 lazy 就能恢复

Mihomo 的官方 API 把“测试一个策略组”“触发一个 provider 健康检查”和“读取节点历史”列为不同接口，也印证了这些状态不是同一个动作。客户端里的按钮名称可能不同，不能仅凭一次手动测速成功，就认定后台周期检查一直在运行。

如果只是延迟数字旧，而当前访问正常，没有必要重置订阅、删除配置或重装客户端。想判断节点是否真的可用，应打开一个实际需要代理的目标；若真实访问也失败，再按节点全部超时的分层排查缩小范围。

不要把所有 lazy 都改成 false

把 lazy 设为 false，含义是未使用时也不再跳过相应检查。节点很多、策略组很多时，每个非零 interval 都可能带来额外探测请求；把间隔压得很短，并不会修复离线服务器、错误订阅或不可达的测试地址。

确实依赖自动切换的组，可以让它保持合理的周期检查；只作为偶尔手动选择的备用组，保留默认 lazy 往往更符合用途。url-test 与 fallback 的切换目标并不相同，可对照自动选择、自动回退和容差的区别判断自己是否真的需要持续探测。

延迟更新后也别把数值当作带宽成绩。测试 URL、响应状态、超时和计算口径都会影响结果；unified-delay 改变了什么说明了为何两种测速口径不能直接比较。

本文于 2026 年 9 月 12 日核对 Mihomo 官方策略组、proxy-provider 与 API 文档。本站没有在你的客户端、订阅或网络上复现该现象，也没有把某个界面的显示行为当作所有客户端的共同实现。

资料来源

以下来源于 2026/9/12 复核。版本、支持平台和发布状态以后续官方页面为准。

持续更新

收到新教程，也欢迎纠错

想收到新文章，可以关注 TG 频道；发现下载失效、套餐变化或步骤不一致，请附上页面链接和可公开的截图。不要发送订阅链接、密码或完整账户信息。

关注 TG 频道 Telegram 纠错邮件纠错

读者互动

这篇内容对你有帮助吗？

— 次访问— 累计日独立访问— 条评论

直接说出你的问题