1 三种「多久动一次」：订阅、探活、自动选路
在一份典型的 Mihomo 配置里，与读者体感最相关的周期往往有三层，但共享同一个词 interval，很容易抄完 YAML 却改错位置。第一层是 proxy-providers 顶层字段 interval：它控制从机场 HTTPS 链接拉取整条 subscription 正文的最小间隔，单位是秒，这才是「自动刷新订阅内容」的主旋钮。第二层是同一个区块里的 health-check.interval：它控制对该 provider 内节点做探活（延迟测试）的周期，与「下载订阅文件」不是同一类请求。第三层在 proxy-groups：例如 url-test、fallback、部分负载均衡组也会有自己的 interval，那是在已经存在的节点列表上做组级测速或状态维持，依然不等于顶层的订阅拉取。
因此排查「我是不是把机场刷太狠了」要先看是下载 YAML 太频，还是健康检查 / 策略组测速太频。只有第一层会直接与「机场链接请求次数」强相关；后两者影响的是探活流量、CPU 小脉冲和仪表盘上数字跳动。把心智模型对齐后，再去翻官方文档里 proxy-providers 与健康检查小节，你就不容易被同名键名带着跑。
proxy-providers.*.interval 管「整条订阅多久抓一次」；health-check.interval 管「这批节点多久探一次活」；proxy-groups.*.interval 管「这个策略组多久重算一次测速结果」（类型需为支持测的组）。
2 proxy-providers：把 interval 写对、把路径写稳
下面是一段贴近实战的骨架：请将 url 换成服务商给你的 Clash 兼容链接，把 path 指到内核 -d 目录下可写、且不会与别的 provider 冲突的相对路径。顶层 interval 建议从 3600 秒一类「一小时量级」起步：对个人用户来说，多数机场的节点表不会每分钟剧变，过于激进除了徒增 无效请求，也容易在供应商启用量子化频率限制时撞到 429 或空响应。若你明确知道运营商只在固定窗口维护节点，也可以把周期拉到数小时，换取更安静的背景网络。
health-check 段落可以关也可以开：关掉时界面可能缺少「绿点延迟」参考，但也不会周期性向外打探测；开启时请把 url 设成轻量、稳定的探针地址，并把 interval 放在合理档位（常见实践会从数百秒起步），否则你会看到日志里探活行比订阅下载行还密集。与订阅拉取失败、403、跳转链相关的排障，可参考站内《Mihomo 订阅 403：User-Agent、重定向与排查清单》，本文专注频率与 lazy，不重复账户侧问题。
proxy-providers:
airport:
type: http
url: "https://example.com/sub?token=YOUR_TOKEN"
interval: 3600
path: ./providers/airport.yaml
health-check:
enable: true
url: https://www.gstatic.com/generate_204
interval: 600
lazy: true
proxy-groups:
- name: PROXY
type: select
use:
- airport
proxies:
- DIRECT
rules:
- MATCH,PROXY
如果你的配置文件是图形客户端合并出来的，记得确认最终落到磁盘的那份仍包含上述结构：有些 UI 会把「更新间隔」映射到等价字段，也可能另行维护缓存文件名。最可靠的方式依然是在「查看当前运行配置」或导出 YAML 后检索关键字 proxy-providers，避免眼睛盯着旧文件改了半天、进程读的却是另一路径。
3 health-check.lazy：官方语义下的「静默」
Mihomo 文档对 health-check.lazy 的说明可以概括成：当取值为 true（默认值）时，如果该 provider 的节点尚未处于被使用状态，就不进行健康检查。这正是许多用户口头说的「静默拉取」在探活层面的含义——不是把订阅下载彻底静音，而是让「尚未参与业务的节点」不要在后台持续测速刷存在感。相反，把它改成 false 会更接近「启动后尽快把所有延迟表填满」的体验，代价自然是更多的探测连接与更热闹的日志。
这也解释了一个常见困惑：为什么配置里明明写着健康检查 interval: 600，却在很长一段空闲时间里几乎看不到探活日志？在 lazy: true 且节点尚未被规则与策略组实际选用时，这种行为是符合文档语义的；一旦你通过浏览器或命令行产生穿越该组的流量，相关节点的测量又会在需要时出现。若你更在意「打开客户端后延迟数字立刻铺满」，可以先把 lazy 关掉做 A/B，再观察耗电、日志噪音与机场侧反馈之间的折中。
interval 仍按自己的周期尝试抓取远程 subscription；lazy 约束的是健康检查探针，并不替你取消定时拉取。若只想减少下载次数，应调大 provider 顶层 interval，而不是指望 lazy。
4 策略组上的 lazy：另一类「用到再测」
当你使用 url-test、fallback 或部分负载相关组型时，组级也可能出现 lazy 字段，其直觉含义与 provider 健康检查相近：在组尚未被实际引用、或未承载流量前，减少主动探测，从而降低无意义往返。这与《Clash URL-Test 与 Fallback：测速选节点与故障转移》一节中讨论的 interval、tolerance 搭配是一脉相承的——只不过本文把视线先放回 proxy-providers，避免初学者误以为所有 lazy 都等价。
实战中常见组合是：订阅拉取维持中等周期；provider 健康检查启用中等周期并 lazy: true；在节点极多、且存在大量几乎不用的策略组时，再给 url-test 组加上 lazy: true，把「静止时的抖动」压下去。相反，如果你是竞技游戏或低延迟场景，可能更愿意在关键组上关闭 lazy、缩短 interval，用更高的背景成本换更确定的首包路径。没有放之四海皆准的数字，只有对你线路、终端形态（台式机 / 笔记本 / 手机）与「能接受多吵的日志」的折中。
5 rule-providers：别忘它们也有更新节律
若你的规则来自远程列表，rule-providers 往往也有自己的 interval 与行为配置。它不会直接决定节点订阅内容，却会影响规则树刷新频率；有时用户感觉「配置总在动」，其实是规则集与节点订阅两层周期叠加，而不是单一 subscription 作怪。维护复杂栈时，把各层的周期记一张小表（订阅、规则、探活、url-test）贴在笔记里，后续调参会轻松很多。
6 改完如何验证：日志、落地文件与可选 API
第一步永远是语法与合并结果：在桌面客户端里使用「重载 / 重新加载配置」一类功能，或在命令行自行启动的内核上执行等价操作（具体命令因发行渠道而异，此处不绑定单一品牌）。第二步把 log-level 提到 info 或更高，观察是否出现与 provider 下载、解析相关的行；如果把顶层 interval 刻意改成很大的值，你应该能在时间轴上看到拉取显著稀疏化，而不是每分钟都握手一次订阅域名。
第三步查看 path 指向的落地 YAML 或清单文件的修改时间：一次成功的远程刷新通常会更新 mtime；若时间卡死不动，而日志却显示成功，就要怀疑是否写到了别的相对路径、或进程工作目录与你预期不一致。对于启用 external-controller 的场景，还可以按官方 REST 文档拉取 providers 相关接口（路径以当前版本文档为准）对照 UI，确认名称一致、延迟与健康状态被正确挂载。
在 Android Termux、路由器或 NAS 一类无 GUI 环境，同样的思路依然成立：把「日志行 + 文件 mtime + 一次性手动 curl 订阅 URL」 triangulation，比在脑内猜更要快。可参考《Termux 无 Root 跑 Mihomo：订阅导入与重启自启》里关于骨架配置与工作目录的写法，把你的 interval 与 lazy 实验放在可重复的目录结构上。
7 常见问题（速查）
问：interval 调得越小越快吗？ 它只保证内核尝试以该周期更新；真正能不能变快还受 DNS、出口 congestion、机场限速与缓存头影响。更小的数字不会魔法般让上游提早发布新节点，却更容易制造无效重试。
问：GUI 里的更新按钮和 YAML 冲突怎么办？ 手动更新通常是一次性旁路；长期节律仍以你写入的 interval 为准，除非客户端另有覆盖层。若你发现保存后被改写，说明合并链路里还有更高优先级片段，可结合《Clash 订阅覆写入门：mixin 与规则追加》检查是否有 mixin、脚本或覆写把字段改回默认值。
问：lazy 能省电到什么程度？ 在省电维度上它主要削减的是空闲期的探测连接与策略组轮询，对整机续航的影响因设备、节点数量与规则复杂度而异；真正的大户往往仍是 TUN、全量接管与常驻无线电，请结合系统级观测判断。
8 总结、竞品对照与下载引导
把 Mihomo 的 subscription 配明白，其实一半在「格式与分流」，一半在「节律」：proxy-providers 顶层 interval 决定机场链接多久抓一次；health-check.lazy 决定在节点闲置时是否静默跳过探活；策略组上的 lazy 又进一步影响自动选路层的背景测速。三层各司其职，读者若要减少无效 HTTP、压低仪表盘与日志骚扰，应分别下刀，而不是只盯一个数字来回试错。
相比之下，一些老旧图形客户端要么把 YAML 细节藏在二进制配置后，要么在「更新间隔」与「测速间隔」之间缺少清晰可视化，用户往往只能凭感觉点选，出了问题也难以对照官方文档核验。纯 YAML 维护虽然门槛略高，却让你可以直接对齐 Meta 内核 文档的字段语义，并在任何平台复制同一套节奏策略。
如果你希望少手写合并、又想在界面上管理多份订阅与覆写，可以试试 Clash Verge Rev 一类围绕 Mihomo 打造的开源桌面客户端：在保持内核能力的同时，把订阅、策略组与日志视图放在一起，更适合长期调校。若你认可这种「看得见的配置链」体验，可以通过本站下载页获取适合你系统的安装包，把今天文中的 interval 与 lazy 实验落在稳定的客户端版本上收尾。
