健康检查为什么会引发故障
后端出现「时好时坏、部分请求 502」时，问题往往出在负载均衡的健康检查而不是后端整体：检查路径或端口配错、阈值过于敏感（一次探测失败就摘除）、检查频率过高把慢启动的服务打挂。另一类高频问题是真实源 IP：四层转发会改写源地址，后端日志里只能看到负载均衡的地址，需要靠 X-Forwarded-For 或代理协议来透传。
基本信息
| 适用组件 | Nginx upstream、HAProxy、云 SLB/CLB、K8s readinessProbe |
|---|---|
| 检查项 | 检查间隔、超时、健康与不健康阈值、检查路径与端口、协议 |
| 源 IP 透传 | 七层用 X-Forwarded-For，四层需代理协议或会话保留（RFC 7239 定义 Forwarded 头） |
| 后端配合 | Nginx 需 real_ip 模块与可信代理配置才能取到真实客户端地址 |
| 观测入口 | 负载均衡侧健康状态 + 后端实例日志分实例统计 |
典型使用场景
- 排查「部分请求 502」：先按后端实例维度拆分日志，确认是否集中在单个节点
- 健康检查频繁摘除节点：核对检查路径是否真的能反映应用可用性
- 后端日志里全是负载均衡地址：确认源 IP 透传配置是否正确
- 服务发布后短暂不可用：确认摘除与恢复阈值是否适合慢启动的应用
- 健康检查把服务打挂：评估探测频率与并发对后端的额外压力
核对与验证
核对与验证
# 从后端视角模拟健康检查（在每台后端上分别执行）
curl -v --connect-timeout 2 http://127.0.0.1:8080/healthz
# 后端日志里确认真实源 IP 是否透传
tail -f /var/log/nginx/access.log | head -20
# 分实例统计错误：确认问题是否集中在某台后端
for f in /var/log/nginx/access.log; do awk '{print $1}' $f | sort | uniq -c | sort -rn | head; done
# 检查配置里的探测参数（以 Nginx 为例）
# upstream backend { server 10.0.0.5:8080 max_fails=3 fail_timeout=30s; }检查项与常见坑
| 检查项 | 正常做法 | 常见坑 |
|---|---|---|
| 检查路径 | 使用能反映依赖状态的专用接口 | 只探测静态页，依赖已挂仍判健康 |
| 检查类型 | 七层检查可发现应用错误 | 仅 TCP 端口检查，应用返回 500 仍算健康 |
| 健康阈值 | 连续失败 N 次再摘除 | 一次失败立即摘除，网络抖动即引发抖动式切换 |
| 检查间隔与频率 | 间隔与超时匹配业务响应时间 | 频率过高把慢启动服务打挂 |
| 源 IP 透传 | 七层用 XFF，四层用代理协议 | 从未配置，后端风控与限流全部失效 |
排查「部分请求正常、部分 502」时，先按后端实例维度拆分日志：问题通常集中在某一台节点上，而不是负载均衡整体故障。