健康检查最常见的失败方式不是没做，而是做了很多却判断不出问题。检查项一堆，全绿，业务却失败；或者一报警，全在报，不知道哪个是真。健康检查的设计目标是让人能按结论行动，而不是尽可能多测一些东西。代理IP线路的检查项彼此有依赖关系，代理IP线路的健康状态要分层来看才能形成可执行的结论。本文按三层结构、两个设计原则讲健康检查怎么分。
三层结构，从连通到行为
第一层是可达层：线路的接入地址能否连上、凭据能否通过。这一层回答的问题是能不能建立连接，判据简单明确，失败就是失败。这一层的检查频率可以高，因为它成本低且结论清晰。
第二层是性能层：延迟、丢包、吞吐是否落在预期范围。这一层的判据要按业务时段的实测基线设，而不是按通用阈值。凌晨测得的优秀值不能用来判断下午的表现，这一类错误在批量环境里造成的误报最多。
第三层是行为层：实际出口归属是否与登记一致、会话是否保持、返回结果是否符合预期。这一层最难做，因为它需要构造接近真实业务的请求，而不是简单探测。但恰恰是这一层覆盖了前两层看不到的问题——可达且性能达标，归属却不对，业务照样失败。代理IP线路的很多异常在行为层才暴露，只做到第二层等于把最常见的一类问题留在检查范围之外。
三层之间是递进关系：第一层失败时不必看第二层，第二层异常时第三层的结论也不可靠。检查项要按这个顺序短路，而不是三层各报各的。各报各的结果会让人同时收到三条警告，实际只有一个根因。
两个设计原则
原则一是检查要有基线，不能只有阈值。”延迟超过五百毫秒告警”是阈值；”延迟超过本线路过去四周同时段中位数的两倍”是基线。基线式判据能适应线路自身的特性差异，阈值式判据会在一批慢速但正常的线路上反复误报。批量环境里健康检查被关掉，多数不是因为检查不准，而是因为误报太多让人失去信任。检查一旦失去信任，真出问题也没人看，这比不检查更坏。
原则二是每项检查要给出下一步动作。健康检查的输出如果是”某项异常”，读的人仍然要自己想怎么办，这一层思考在半夜接到提醒时最容易出错。合理的输出是”某项异常，先看第二层的同期数据，若同期也异常则说明是线路问题”。把判断路径写进检查结论，检查才真正减轻负担而不是增加负担。
第三条虽然不成原则但值得提：检查本身的执行要留痕。检查有没有跑、跑的结果是什么，这些记录是事后追溯时唯一的依据。批量环境里出现过这样的情况——某段时间业务大量失败，事后需要确认这段时间检查是否执行过、结果如何，如果检查记录只有最新一次的状态，这段历史就完全无法还原。代理IP线路的检查记录保留周期要比检查结果本身长，这一点常被忽略。
分层的另一层好处是便于按环境调整覆盖范围。核心线路三层都做，普通线路做前两层，临时线路只做第一层。这种差异化的覆盖在固定周期检查里做不到，因为周期检查默认对所有对象一视同仁。分层之后覆盖策略能按重要性分配，把有限的探测资源用在真正需要行为层验证的线路上，整体检查质量反而会上升。健康检查做得好坏的标志不是覆盖了多少项，而是每一项被看到时能否立刻知道该做什么。
问：三层检查要分开做还是合并成一次？
分开做。合并成一次时短路关系无法体现，第一层都不通还要去测归属，既浪费时间又给出误导性的第二层结论。分开做还便于对不同线路只跑前两层。
问：检查频率高到低还是低到高？
按层给不同频率。可达层可以密，性能层按业务时段，行为层按周期抽样。三层同频率会让行为层的成本过高，最后哪一层都做不细。