最直接表现是后端状态显示“异常”、流量被剔除、用户请求返回502/超时/连接拒绝；需从网络连通性、服务响应、配置匹配、安全策略四方面排查，不可只盯日志或盲目改配置。
负载均衡健康检查失败，最直接的表现是后端服务器状态显示“异常”，流量被自动剔除，用户请求返回502、超时或连接拒绝。排查需从网络连通性、服务响应、配置匹配和安全策略四方面入手，不能只盯日志或只改配置。
看日志确认失败类型和频率
先查Nginx或云负载均衡的错误日志，定位具体错误模式：
- Nginx：执行 tail -f /var/log/nginx/error.log，关注 upstream timed out（超时）、connection refused（端口不通）、no live upstreams（全节点下线）或明确的 health check failed
- 云CLB/ELB：在控制台“后端服务器组”页签查看健康检查状态，结合“监听器详情”里的探测源IP和失败原因描述（如“TCP连接失败”“HTTP状态码不匹配”）
- 注意日志时间戳与健康检查间隔是否吻合——若失败集中在某几秒内，可能是周期性抖动；若持续报错，说明根本性问题未解决
验证后端服务真实可达性
绕过负载均衡，直接测试后端节点是否能被健康检查源IP访问：
- 用 curl -I http://[IP]:[PORT]/[health_uri] 模拟七层检查，重点看HTTP状态码（必须匹配配置的 status）、响应体内容（是否含预期关键词）、响应头中 Connection: keep-alive 是否存在
- 用 telnet [IP] [PORT] 或 nc -zv [IP] [PORT] 测试四层连通性；失败则检查后端进程是否监听在 0.0.0.0（而非127.0.0.1），以及本地防火墙（iptables/firewalld）是否放行
- 若为UDP健康检查，还需确认ICMP响应未被限速：sysctl -q net.ipv4.icmp_ratelimit 应为1000，sysctl -q net.ipv4.icmp_ratemask 需确保包含port unreachable类型
核对健康检查配置与后端响应是否一致
常见不匹配点往往藏在细节里：
- 检查 uri 路径是否与后端实际健康接口完全一致（区分大小写、尾部斜杠）
- 确认 match 规则中的 status 值（如200/503）、body 正则（如 ~"OK|healthy|up"）能否真正捕获后端返回内容——JSON响应
{"status":"up"}不等于纯文本 "up"，需加引号或调整正则 - 参数别设得太激进：fails=1 interval=1 容易因瞬时延迟误判；建议初调为 fails=3 interval=5 passes=2
- 云平台注意协议匹配：TCP后端不能配HTTP健康检查；QUIC/GRPC后端仅支持UDP或TLS健康检查
检查网络路径上的拦截策略
即使服务本身正常，中间网络设备也可能阻断健康探测：
- 安全组：后端服务器安全组入站规则必须放通健康检查源IP网段——Nginx自建场景是Nginx服务器IP；云CLB是控制台显示的“健康检查源IP”（如100.64.0.0/10或ELB后端子网网段）
- 网络ACL：子网级ACL需同步放行该源IP网段的入站流量，协议端口与健康检查配置一致
- IDC场景：若后端在IDC，需确认防火墙或iptables放通CLB分配的SNAT IP，而非负载均衡VIP
- 特别注意：四层TCP健康检查依赖SYN包，若后端启用了TCP SYN Cookie或连接数限制，可能丢弃探测包
