要比较策略组里各出站的健康检查结果，必须先把探测地址、等待上限、期望状态和是否定时写成同一套条件。官方把这些项放在代理组字段里并列出现：漏写或单位写错，后面看到的延迟就没有共同基准。本节只说明测试前如何把条件固定下来，以及写完后怎样核对。
适用条件：先分清谁会被这组条件测到
健康检查测试地址写在 url。资料注明：它只会检查代理组 proxies 字段里的代理，不会检查通过 use 引入的代理集合中的代理。节点几乎全在 provider 里、组上却只写了 url 时，集合内节点并不共享这套组级检查。固定条件之前，先判断成员来自 proxies 还是 use。
interval 单位为秒，不为 0 才启用定时测试。lazy 默认为 true，未选择到当前策略组时不进行测试，因此组尚未被选中时，不能假定探测已经按你写的条件在跑。timeout 是健康检查超时时间，单位毫秒。expected-status 约束健康检查时期望的 HTTP 响应状态码；配置了该字段后，只有状态码与期望一致才认为节点可用，默认 * 表示对响应状态不做要求。max-failed-times 是最大失败次数，超过则触发一次强制健康检查，默认 5。
判断依据：成员在 proxies 中、并且你准备按同一口径看延迟或可用性时，才需要把上述字段写成明确值。成员只在 use 里时，不要把组级 url 当成已经覆盖集合内节点的测试协议。组级 interface-name 与 routing-mark 已弃用，不能当作探测开关来固定。
把地址、时间与期望状态写成一组的操作
第一步，在该策略组写入固定的 url，全组共用同一测试地址，避免部分检查走未声明地址。第二步，写入 timeout，用毫秒表达上限；资料示例中的 5000 即表示五千毫秒这一量级，目的是让「超时」有统一尺度，而不是暗示必须用该数字。第三步，若只接受特定状态码，写入 expected-status：用斜线匹配多个状态码，用短横匹配状态范围，可混合书写。资料中的写法包括 200/302、400-503、200/302/400-503。不需要约束状态时保持默认 *，不要随意写一个测试地址根本不会返回的码。第四步，把 interval 写成非 0 的秒数以启用定时测试；若只想在选中后检查、不要周期探测，就不要留下「看起来像间隔」却等于 0 的值。第五步，按是否允许未选中也执行同一套定时条件来设置 lazy：停留在默认 true 时，未选中即不测。第六步，若要把失败容忍也固定下来，显式写出 max-failed-times 整数，避免只靠默认 5 却在事后无法对照。
出口网卡与路由标记若需要一并约束，应写到代理节点字段，而不是继续写在组上。资料给出的优先级是代理节点大于代理策略大于全局。
固定后如何核对，失败时下一步
核对看五件事：url 是否仍是你打算用来比较的那一类检查；timeout 与 interval 的单位是否分别是毫秒和秒；expected-status 是否与该测试地址会返回的状态码相容；当前组是否处于会被测试的选中状态；节点是否位于 proxies 而不是仅位于 use。
条件写了却看不到检查：先看 lazy 是否因未选中而跳过，再看 interval 是否为 0，最后看成员是不是只在代理集合里。检查在跑但全部判失败：先核 expected-status 是否过严，再看 timeout 是否短到请求尚未完成即结束。失败次数很快堆高时，对照 max-failed-times 是否已低到频繁触发强制检查。组级弃用字段没有把探测固定到某块网卡上，出口问题应到节点侧按优先级查。仍对不上时，回到代理组健康检查字段定义，不要把界面上的延迟数字理解成另一套未写入配置的协议。