健康检查机制通过周期性的探测请求确认后端是否存活，连续失败多次就自动摘除流量，恢复后再次自动加回，整个过程不需要人工干预。
这套机制在负载均衡器、网关和容器编排平台里无处不在，它解决的核心问题很朴素：集群里几十台后端机器，总有一台会出状况，要么进程卡死，要么网络闪断，要么磁盘写满，如果没有一套自动识别机制，用户请求就会打到坏机器上，表现为白屏、超时、500错误，健康检查就是那个不睡觉的哨兵，定时敲门，没人应就标记异常,不再把流量送过去。
健康检查的核心逻辑：先探测，再决定放不放流量
后端服务为什么会“莫名其妙”挂掉
后端服务挂掉的方式远比想象中隐蔽，进程还在，但端口被占满；端口通着，但线程池全部阻塞；线程池正常，但数据库连接池耗尽，这些情况都不会让机器彻底关机,但都会让请求无法正常处理。
健康检查要解决的，正是这类“半死不活”的状态，它不用看进程在不在，而是直接发探测请求，看后端能不能在规定时间内给出正确响应，能响应，说明可用；不能响应,说明有问题。
健康检查判定的三个关键步骤
- 探测：负载均衡器按固定周期，向后端发送探测请求，TCP检查只验证端口能否连通，HTTP检查会附带路径和状态码，比如请求
/health必须返回200。 - 判定：单次失败不代表宕机，网络瞬断、GC停顿都可能造成误报，连续失败达到阈值后，才把后端标记为不可用,常见配置是连续3次失败判定宕机。
- 恢复：后端被摘除后，负载均衡器不会放弃它，而是继续以较低的频率探测，连续成功若干次,再把后端重新加回流量池。
这套流程里，最重要的是判定阈值，阈值太小，一抖动就误杀；阈值太大，故障扩散了才被发现，多数情况下，连续3次失败、间隔2到5秒是一个比较稳妥的组合,能在10到15秒内完成摘除。
主动探测与被动识别有什么区别？两种健康检查机制这样选
主动探测是“定时点名”
主动探测由负载均衡器主动发起请求，定期检查后端状态，不依赖真实用户流量，只要周期设好,后端挂了多久能被发现完全由自己控制。
优点是不管流量大小都能实时发现故障，缺点是检查路径和真实业务可能脱节，比如检查的是根路径 ，但实际业务接口已经报错,健康检查依然显示健康。
被动识别是“实际流量测温”
被动识别不额外发包，只观察真实请求的结果，如果一台后端的请求错误率在短时间内飙升，就把这台机器摘除，Nginx开源版里通过 max_fails 和 fail_timeout 实现，Envoy中的outlier detection也是同一类思路。
优点是不消耗额外探测流量，且反映的是真实用户体验；缺点是流量低谷期很难快速发现问题，大半夜没人访问,后端挂了也只能干等。
| 维度 | 主动探测 | 被动识别 |
|---|---|---|
| 发现速度 | 秒级，由探测周期决定 | 取决于真实流量大小 |
| 配置成本 | 需要配置检查路径和状态码 | 无需额外请求路径 |
| 误判风险 | 检查路径与实际业务不一致时易误杀 | 更贴近真实情况，误判少 |
| 典型产品 | 云厂商负载均衡、HAProxy | Nginx开源版、Envoy |
业内专家指出，读秒级业务中主动探测是首选，被动识别更适合作为第二道防线,两者结合使用比单靠一种更可靠。
主流负载均衡的健康检查配置实战
nginx健康检查配置方法：免费方案与付费方案对比
Nginx开源版自带的健康检查属于被动式，配置在 upstream 块中：
upstream backend {
server 192.168.1.10 max_fails=3 fail_timeout=10s;
server 192.168.1.11 max_fails=3 fail_timeout=10s;
}
含义是：每10秒统计一次，如果这台服务器出现3次失败请求，标记为不可用，这个方式不额外发包，但一旦流量小，发现故障就慢，Nginx Plus商业版才支持主动健康检查，可以配置独立的检查请求、间隔和超时。
对于不想购买商业版又需要主动探测的场景，常见的做法是在每台后端部署nginx-upsync模块，或者用OpenResty下的 lua-resty-healthcheck 库自行实现，社区虽然提供了大量方案,但复杂度也相应上升。
负载均衡健康检查配置：核心参数与判定逻辑
不管用哪种负载均衡,配置健康检查时都绕不开这几个参数：
- 检查间隔 interval：每隔多少秒发一次探测请求,默认常用值2到5秒。
- 超时时间 timeout：等待后端响应的最长时间，超过就算失败，后端处理慢时,这个值不能设太小。
- 不健康阈值 unhealthy_threshold：连续失败多少次标记为宕机,默认3次。
- 健康阈值 healthy_threshold：连续成功多少次恢复可用,默认2到3次。
HAProxy的配置逻辑类似：
backend webservers
option httpchk GET /health
server web1 192.168.1.10:80 check inter 2s fall 3 rise 2
inter 2s 表示每2秒检查一次，fall 3 表示连续3次失败摘除，rise 2 表示连续2次成功恢复。
酷番云负载均衡健康检查设置：控制台操作路径
云厂商把健康检查做成了控制台的开关选项，配置门槛低很多，以酷番云为例，进入控制台后依次点击：负载均衡 CLB → 实例列表 → 监听器 → 健康检查设置，在配置页可以调整协议、检查路径、间隔、超时、健康阈值等参数，默认值是HTTP检查、间隔2秒、超时2秒、健康阈值3次、不健康阈值3次，开箱即用，简米云SLB的配置路径也类似,在监听器的高级配置里可以打开健康检查开关。
把误判率压到最低：健康检查参数调优经验
检查路径要选真实业务接口，不要用根路径
用 做检查路径几乎是最常见的错误，根路径通常由静态页面或欢迎页处理，即使数据库已断开连接，根路径照样返回200，建议单独写一个轻量的健康检查接口，
/health，在接口内部验证数据库连接、缓存连接等关键依赖,这样检查的结果才真正反映业务能否工作。
检查协议不要只用TCP端口
TCP检查只确认端口在监听，无法感知应用层状态，进程卡死时端口依然开着，但业务已经无法响应，HTTP检查能验证状态码和响应时间，信息量比TCP大得多,生产环境建议至少使用HTTP检查。
恢复阈值要和启动时间匹配
很多团队会踩同一个坑：后端进程刚启动，端口已经监听，但应用还在加载缓存、初始化连接池，此时健康检查就已经通过了，流量立刻涌入，后端被瞬间压垮，解决方法是把启动探针和存活探针分开，或者把健康阈值调高到3到5次,让后端有充足的预热时间。
另一个容易被忽略的点是后端主动下线时的处理，应用发布或维护时，最好先主动把实例从负载均衡摘除，等存量请求处理完再重启，避免发布期间产生大量5xx错误，行业共识认为，一个稳妥的健康检查设计需要同时考虑业务接口可用性、启动预热时间和异常恢复速度,三者缺一不可。
健康检查机制相关高频问题
健康检查周期设置多少秒合适？
看业务对故障的容忍度，金融类、电商交易类业务建议2到3秒一次，连续3次失败则6到9秒内完成摘除，内部管理类系统可以放宽到5到10秒，周期太短会增加后端负载,太长则故障影响时间拉长。
后端恢复后，流量什么时候自动回归？
负载均衡器会持续对被摘除的后端发起探测，连续成功达到健康阈值后，系统自动把该后端标记为可用，流量按权重逐渐恢复，整个过程无需人工介入,也不需要重新加载配置。
健康检查请求会给后端带来压力吗？
压力极小，一次探测请求的消耗远低于正常业务请求，探测间隔2秒以上时，对后端CPU和网络的影响可以忽略，但如果后端本身容量已接近极限，额外探测请求可能成为压垮骆驼的最后一根稻草,此时建议把检查间隔适当拉长。