代理集合页给出了三档可以对照的时间尺度：interval（秒，下次更新集合）、health-check.interval（秒，下次延迟测试）、health-check.timeout（毫秒，单次延迟测试等待上限）。该页没有下载耗时日志格式，也没有「立即失败」这个字段名。区分立刻报错和长时间等待时，自己记下开始时刻和出现结果的时刻，用经过时间去对这三档，而不是去对并不存在的连接超时项。
适用条件
适用于 http 类型在更新或健康检查时看起来卡住，需要判断是配置当场被拒绝，还是等到了文档里的某个时间点。file / inline 不经远程 url 更新，不要把本地读取的快慢当成远程等待。
记下经过时间再对照
- 记下开始时刻和失败（或仍在等待）的时刻，得到经过时间。
- 几乎立刻返回：优先当配置或路径约束，而不是网络在等。本页会让操作当场无法按预期进行的情况包括：http 未配置
url；path重复；path不在 HomeDir 且未设置SAFE_PATHS；name重复。这些不经过interval等待。 - 经过时间落在
health-check.timeout的量级（示例 5000 毫秒），并且正在测节点延迟：对应健康检查单次等待上限。判断：health-check.enable为 true，访问的是检测用url，不是订阅url。 - 经过时间接近
health-check.interval（示例 300 秒）才出现下一次延迟结果：这是检查节奏，不是订阅下载在读正文。 - 经过时间接近
interval（示例 3600 秒）才再次访问订阅url：这是更新节奏。到期之前没有新的下载，属于还没到更新点。 health-check.lazy默认为 true 时，不使用该集合节点则不测试。表现可能是一直没有延迟数据；测试未开始时，timeout不会去截断一段不存在的等待。
判断依据
立刻失败：对照 name、type、url、path、SAFE_PATHS，不要调大任何 timeout。数秒量级且在测延迟：对照 health-check.timeout。数分钟到一小时：先分清你在等的是健康检查间隔还是 provider 更新间隔。size-limit 超限和 age 解密失败发生在已经拿到内容之后，不能单用 interval 解释。
对不上这三档时下一步
重新确认等待的是「经 proxy 拉 url」还是「对节点做健康检查」。前者查下载路径；后者查 enable、检测地址、timeout 和 lazy。不要因为等得久就加大 interval，那只会更晚才更新。本页未给出订阅下载自己的超时字段，记录时间是为了分类现象，不能据此在配置里编造连接超时或读取超时项。