健康检查与 502 是什么
负载均衡通过健康检查判断后端是否可用：检查通过才转发流量，连续失败就把后端摘除；当后端组里没有健康实例时，用户就会看到 502。所以 502 大多不是负载均衡本身故障，而是后端被摘光了。排查顺序固定：先看后端组状态，再从负载均衡所在网络直连后端，最后看应用日志。
基本信息
| 检查方式 | TCP 端口探测或 HTTP 状态码探测，按监听配置决定 |
|---|---|
| 判定规则 | 连续失败若干次标记异常，连续成功若干次恢复 |
| 常见误配 | 健康检查路径返回 404 或 302，非 2xx 通常视为失败 |
| 排查顺序 | 负载均衡后端组状态 → 直连后端 IP 与端口 → 后端应用日志 |
| 安全组 | 健康检查流量来自负载均衡内网地址段，检查端口必须放行 |
典型使用场景
- 新上线服务：先确认健康检查路径返回 200，再接入真实流量
- 发布后报 502：检查后端是否因启动慢被判定异常并摘除
- 扩容后流量不均：新实例未通过检查，流量仍集中在旧实例
- 排查间歇性 502：结合后端日志看是否有请求处理超时或进程重启
- 调整检查参数：启动慢的服务适当放宽超时与不健康阈值
后端直连验证
后端直连验证
curl -sv http://10.10.1.5:8080/health --max-time 5 # 看状态码与响应体
nc -zv 10.10.1.5 8080 # 端口是否可达
ss -lntp | grep 8080 # 后端进程是否真的在监听
# 从负载均衡所在网络的跳板机执行，结果才与健康检查一致
tail -f /var/log/app/error.log # 结合应用日志看是否有异常502 常见原因对照
| 现象 | 可能原因 | 下一步 |
|---|---|---|
| 所有后端异常 | 后端进程挂了或端口改了 | 直连后端确认服务是否监听 |
| 部分后端异常 | 个别实例配置或版本不一致 | 对比健康与异常实例的差异 |
| 检查一直超时 | 安全组未放行健康检查端口 | 放行负载均衡内网网段 |
| 检查返回 302/404 | 健康检查路径指向需登录的接口 | 换成无鉴权的专用健康接口 |
| 刚发布就 502 | 启动慢，未过检查就接流量 | 放宽阈值或加启动预热 |
后端被摘除后用户看到的是 502：先让后端恢复健康检查通过，把流量续上，再排查应用根因，避免在无流量的状态下盲调。
健康检查路径要用专用的无鉴权接口，返回内容尽量简单：既要知道进程活着，也不该触发数据库查询等重逻辑，否则检查本身会放大后端压力。