在调整 Clash（MetaCubeX/mihomo）策略组测速间隔之前，要把「额外请求量」落在官方健康检查字段上，而不是按配置里出现过的全部节点名去乘。文档写明：interval 是健康检查间隔，如不为 0 则启用定时测试，单位为秒。真正会多出来的请求，来自这类定时测试，再加上失败次数触发的强制健康检查。
适用条件：哪些间隔改动才会增加请求
同时满足下面条件时，改 interval 才会改变该组自己发出的探测：策略组配置了健康检查测试地址 url；interval 不为 0。更关键的是检查范围：健康检查只会检查代理组 proxies 字段的代理，不会检查通过 use 引入的代理集合（proxy-providers）里的代理。节点若主要写在 use 下，不能把集合内个数算进该组间隔。
lazy 默认为 true，未选择到当前策略组时不进行测试。未被选中且保持懒惰的组，缩短间隔也不应按满负荷计入。判断依据是能同时指出该组的 url、interval、lazy、proxies 与 use：缺测试地址或间隔为 0，该组谈不上定时测速带来的额外请求。
具体操作：按字段拆开再决定是否改间隔
第一步，只统计会被该组健康检查覆盖的对象，即 proxies 中的出站或其所指向的对象，不要把 use 引入的集合按同一规则计入。
第二步，读取 interval（秒）。在组被选中、且不会因懒惰跳过测试的前提下，每个被测代理按该间隔发起定时请求。文档通用示例把 interval 写成 300，只说明字段单位与写法，不表示必须采用该秒数。
第三步，确认 lazy。为 true 时，把该组从「持续测速」改记为「仅当被选中才测速」。若未选中仍去缩短间隔，核算会偏大。
第四步，单独列出突发量：max-failed-times 是最大失败次数，超过则触发一次强制健康检查，默认 5。抖动场景下，强制检查会叠在定时间隔之上。timeout 单位为毫秒，超时过紧会推高失败计数，从而增加强制检查次数。
第五步，若配置了 expected-status，只有响应状态码与期望一致才认为节点可用，默认为 * 表示对状态不做要求。可用 / 匹配多个状态码、用 - 匹配范围。期望过严时，失败次数上升，额外强制检查也会上升。
判断依据：缩短间隔前应能回答三件事——被测对象是否只在 proxies、间隔秒数是多少、近期是否会因失败次数触发强制检查。答不出范围，就不应改 interval。
失败时下一步
改完间隔后若请求规模与核算对不上，停止继续加减秒数，按字段回退：先核对是否把 use 的代理集合当成了该组间隔的被测对象；再核对 lazy 与当前是否选中该组，未选中时定时测试按文档不进行；接着确认 interval 是否为 0，为 0 则未启用定时测试；最后查看 timeout、expected-status 是否造成连续失败，从而频繁触发强制健康检查。仍无法对应时，只对照代理组通用字段中与健康检查直接相关的项，避免改动 filter、hidden 等无关字段。