健康检查失败怎么查
排查顺序是：先在后端本机验证端口与探活路径是否正常，再核对安全组与主机防火墙是否放通检查来源，然后确认应用监听地址不是 127.0.0.1，最后检查应用侧的 IP 白名单与限流是否拒绝了探测请求。按这个顺序推进，绝大多数「业务能访问但成员异常」的问题都能定位到具体一层。
基本信息
| 首要判断 | 是全部成员异常，还是个别成员异常 |
|---|---|
| 本机自检 | 端口监听状态、探活路径返回值、进程是否存活 |
| 网络层 | 安全组、firewalld 或 iptables 是否放通检查来源 |
| 监听地址 | 应用必须监听 0.0.0.0 或内网网卡，不能只监听 127.0.0.1 |
| 应用层 | IP 白名单、限流、鉴权是否拦截了探测请求 |
| 独立检查端口 | 单独配置检查端口时，要确认该端口与业务端口都正常 |
典型使用场景
- 发布新版本后成员持续异常：先在实例上验证探活接口
- 只有部分后端异常：优先怀疑该实例自身的配置与资源
- 全部后端同时异常：优先怀疑健康检查参数、入口配置或检查来源放行
- 换了探活路径后成员全被摘除：核对路径返回值与状态码要求
- 排查疑似网络问题时，用两端抓包确认探测流量是否到达
后端快速自检
后端快速自检
curl -sS -m 3 -o /dev/null -w '%{http_code}\n' http://127.0.0.1:8080/healthz
systemctl is-active myapp # 进程是否存活
ss -lntp | grep 8080 # 监听地址是否为 0.0.0.0
sudo iptables -S | head -20 # 是否有拦截规则
curl -sS -m 3 -o /dev/null -w '%{http_code}\n' http://<内网IP>:8080/healthz # 用内网地址再验证一次现象与排查重点
| 现象 | 重点检查 |
|---|---|
| 全部成员异常 | 健康检查参数、检查来源是否放行、入口规则是否误伤探活 |
| 个别成员异常 | 该实例的进程、端口、监听地址与资源占用 |
| 本机 curl 正常但检查失败 | 安全组或主机防火墙未放通检查来源 |
| 返回码非预期 | 探活路径被重定向或鉴权拦截 |
「应用能正常提供服务但成员被摘除」几乎总是这三类原因之一：监听地址只绑定了回环、探活路径被拦截、检查来源未放通，按顺序核对即可。
健康检查频繁失败时应修复根因，不要通过停用健康检查掩盖问题，否则故障转移能力一并消失，后续故障会直接以 5xx 暴露给用户。