只凭一次健康检查耗时或一次超时，就改掉正在用的节点，等于把“这一次探测没完成”写成“节点必须更换”。代理组文档给出的是检查地址、间隔、超时、失败次数和期望状态，并没有把单次延迟定义成更换常用节点的充分条件。下面只围绕这些字段，说明适用条件、可执行的核对步骤，以及失败时下一步应改哪一类判断，而不是扩写成其他配置页的内容。
适用条件：单次延迟不能当作更换依据的场景
当策略组配置了 url，并且 interval 不为 0 时，才会启用定时健康检查，间隔单位为秒。文档写明：健康检查测试地址只会检查该组 proxies 字段里的代理，不会检查通过 use 引入的代理集合中的代理。因此，常用节点若只存在于代理集合中，当前组上的一次延迟、一次超时或一次失败，都不能作为更换那些节点的依据。
lazy 默认为 true，未选择到当前策略组时不进行测试。常用节点所在组若此刻未被选中，所谓“这一次延迟”在文档意义上并不存在，不能用来改选。timeout 单位为毫秒，只约束这一次检查过多久算超时；超时是本次探测的结果，不是业务可用性结论，更不是必须换节点的指令。
适用条件是：该组已经配置健康检查，并且你打算用检查是否成功来辅助判断可用性。不适用的情况包括：节点不在 proxies 中、组处于懒惰未测试状态、以及只完成了一次探测就准备改选。default-selected 为空或节点名不存在时，默认选择组中第一个节点，更换前应先确认当前实际选中的名字，避免把“落到第一个节点”误当成延迟切换。
用间隔、超时、失败次数和期望状态约束判断
先核对 interval。该值不为 0 才有定时测试。间隔过短时，相邻两次检查容易落在同一段网络抖动里，表面上像连续失败，实质上仍接近一次事件。判断依据：至少要在不同时间窗口看到可重复的结果，才能讨论节点是否可用；仅有一次返回，无论快慢，都不够作为更换常用节点的依据。
再核对 timeout。它只说明探测在设定毫秒内有没有结束。判断依据：在相同 url 与相同 timeout 下多次出现超时，才能进入失败统计，而不是第一次超时就替换节点。
然后使用 max-failed-times。超过最大失败次数会触发一次强制健康检查，默认值为 5。判断依据：未达到该次数前，单次延迟差或单次失败不是更换常用节点的充分条件；达到阈值后，文档写的是触发一次强制检查，仍要看这次检查是否满足你设定的成功标准，而不能把“触发强制检查”理解成自动换节点。
接着配置并解读 expected-status。配置了该字段时，只有 HTTP 响应状态码与期望一致才认为节点可用；默认为 *，对响应状态不做要求。可用 / 匹配多个状态码，用 - 匹配范围，可混合书写，例如 200/302、400-503 或 200/302/400-503。文档示例里的检查地址为 https://www.gstatic.com/generate_204。若使用同类地址，应把期望状态与地址行为对齐来理解“可用”，避免把“有响应但状态不符”和“单次耗时偏长”混成同一条更换理由。判断依据：一次状态不符应记入失败计数，并与间隔、最大失败次数一起看，而不是单独决定更换。
empty-fallback 只在组为空时回退，默认值为 COMPATIBLE，且不支持填写代理组、只支持 proxy 名称。它与“因一次延迟差而换常用节点”不是同一条路径，不能拿来解释延迟误判。
检查范围失败时的下一步
若常用节点只出现在 use 引入的代理集合中：下一步是把需要被检查的节点写入 proxies，或停止使用该组健康检查结果评价这些节点。在此之前，任何单次延迟都不能作为更换依据。
若 lazy 仍为默认 true、且该组未被选中：下一步是先确认该组已被选择，再等待至少一次完整的间隔周期，而不是用历史一次结果改节点。
若 filter、exclude-filter 或 exclude-type 把常用节点排除出组，则检查对象已经不是你以为的那一批。exclude-type 不支持正则表达式，通过 | 分割、按节点类型排除，仅排除引入的出站代理。下一步应先核对组成员，再谈延迟。include-all、include-all-proxies、include-all-providers 会改变引入范围且按名称排序，引入不包含策略组；组成员变化后，更不能拿一次旧检查对照旧的常用节点。
完成上述核对仍无法解释时，下一步应同时记录 url、interval、timeout、max-failed-times、expected-status 以及该节点是否位于 proxies，用同一组条件重复检查。文档没有给出可承诺的时延或更换效果，判断只应落在这些字段是否被满足。