开启健康检查是保障nat后端服务稳定运行的必要机制，它持续执行并决定流量是否转发，支持tcp/http探测，状态分为探测中、健康、异常、已关闭四类，且存在全死全活兜底策略。
开启健康检查是 nat 后端服务稳定运行的关键前提。它不是可选项，而是保障流量只打到可用节点的必要机制——即使后端权重为 0 或刚加入集群，健康检查仍会持续执行，并决定是否转发请求。
健康检查状态与流量行为
后端服务器在 NAT 负载均衡中呈现四种典型状态，每种状态直接对应是否接收新请求：
- 探测中：新绑定服务器在“检查间隔 × 健康阈值”时间内（如 2s × 3 次 = 6s），不参与流量分发；CLB 暂缓转发，等待确认可用性。
- 健康：正常接收并处理请求；这是理想运行态，CLB 将按调度策略（如轮询、加权轮询）向其分发流量。
- 异常：连续失败达阈值（默认 3 次 TCP 连接超时或 HTTP 返回非 2xx）后被隔离 10 秒；期间不转发任何新请求。
- 已关闭：所有后端无差别接收流量，包括已宕机或不可达的实例——这会直接导致业务错误率上升，不建议关闭。
TCP 与 HTTP 健康检查配置要点
四层（TCP/SSL）和七层（HTTP/HTTPS）监听器支持不同探测方式，需按协议特性合理设置：
- TCP 检查：仅建立三次握手连接，不发送应用层数据；适合数据库、Redis 等无 HTTP 接口的服务；超时时间建议设为 2–5 秒，避免过短误判、过长拖慢恢复。
-
HTTP 检查：发送 HEAD 或 GET 请求至指定路径（如
/health），校验返回状态码（默认 2xx 或 3xx）；需确保后端服务该路径稳定响应且不依赖复杂逻辑。 - 无论哪种类型，检查间隔建议 ≥ 2 秒，健康/不健康阈值建议设为 3，兼顾灵敏性与抗抖动能力。
全死全活逻辑的触发与应对
当一个监听器下所有后端都被判为“异常”，系统将启用兜底策略——即“全死全活”：
- CLB 不再拒绝请求，而是把流量尝试转发给全部后端，不再做健康筛选。
- 该机制防止服务完全不可用，但可能放大故障影响；应配合告警（如“全部后端异常”监控）快速定位根因，而非依赖此逻辑长期运行。
- 常见诱因包括：后端统一断网、安全组拦截健康检查端口、健康检查路径配置错误或后端进程崩溃未退出监听端口。
NAT 架构下的健康检查特殊性
在 LVS-NAT 或 Nginx stream 模式等典型 NAT 架构中，健康检查不仅作用于服务可用性，还影响地址转换链路的完整性：
- Director 或代理节点必须能从自身网络环境访问后端真实 IP 和端口；若使用私有地址段（如 192.168.x.x），需确保路由可达且无防火墙阻断。
- 被动健康检查（默认开启）依赖实际转发结果：某次请求失败即计 1 次失败，连续 3 次失败则屏蔽；因此后端日志中的连接拒绝、超时、RST 包都会被计入健康状态。
- 主动检查（如 LVS 的
ipvsadm --add-service配合--scheduler和--monitor）需额外部署探测脚本或集成 keepalived，适用于对恢复时效要求极高的场景。
