负载均衡故障怎么排查_常见问题诊断手册【排查】

负载均衡故障本质是转发链路中断，90%可通过分层验证定位：先查健康检查是否误判，再直连后端隔离层级，接着验配置语法与资源状态，最后排查主备切换及协议兼容性问题。

负载均衡故障不是“坏了”，而是“转发链路某处断了”——先别急着重启，90% 的问题能靠分层验证快速定位。

看日志前先确认健康检查是否在“误杀”后端

现象：后端服务明明 curl -I http://localhost:8080 正常，但负载均衡器持续标记为 DOWN。这往往不是服务器问题，而是健康检查配置过激。

• 检查健康检查路径是否真实存在（比如配了 /healthz，但后端只暴露 /actuator/health）
• 确认超时时间（timeout）和失败阈值（fall）是否合理：nginx 的 fail_timeout=10s max_fails=3 在高延迟网络下极易误判
• HAProxy 中若启用了 httpchk GET /health，但后端返回了 302 跳转或非 2xx 响应码，也会被判定失败
• 云上 ALB/CLB 默认用 TCP 检查，若后端服务监听了 udp 端口或仅支持 HTTP/2，可能直接不通

绕过负载均衡直连后端，快速隔离故障层级

这是最高效的“二分法”：如果直连后端正常，说明问题一定出在负载均衡器本身或它与后端之间的链路。

• 用 telnet <backend-ip><port></port></backend-ip> 测试四层连通性；若失败，检查防火墙、安全组、路由表、VPC 对等连接
• 用 curl -H "Host: example.com" http://<backend-ip>:<port>/api/test</port></backend-ip> 模拟七层请求，验证应用层是否可达
• 若直连成功但走 VIP 失败，重点查负载均衡器的 proxy_pass（Nginx）、server 行（HAProxy）或目标组注册状态（AWS）
• 注意：kubernetes Service 的 ClusterIP 不可直连外部，此时应进 Pod 所在节点执行 curl http://<pod-ip>:<port></port></pod-ip>

检查配置语法 & 运行时资源，别让低级错误拖垮整条链路

配置文件写错一个字符、内存耗尽、CPU 占满，都会让负载均衡静默失效——它不报错，只是不转发。

• Nginx 必须用 nginx -t 验证语法，尤其注意 upstream 块中 IP 写成 10.0.0.1:（多了一个冒号）这类低级错误
• HAProxy 启动前运行 haproxy -c -f /etc/haproxy/haproxy.cfg，避免配置加载失败却无提示
• 用 top 或 htop 查 CPU，free -h 查内存，ss -s 看 socket 连接数是否接近系统上限（如 65535）
• 云上负载均衡（如 AWS ALB）要查 CloudWatch 中的 HTTPCode_ELB_5XX 和 TargetResponseTime，而非只盯后端指标

主备切换失败？先验证 VIP 和心跳是否真正生效

Keepalived、F5 或云厂商的双活架构，故障时切不走流量，八成是虚拟 IP（VIP）没绑定或 VRRP 心跳中断。

• 在主节点执行 ip addr show，确认 VIP 是否出现在网卡（如 eth0）上；若没有，systemctl status keepalived 很可能显示 “exited”
• 用 tcpdump -i any vrrp 抓包，看是否有 VRRP 广播发出；若无，检查交换机是否禁用了组播或接口 ACL
• F5 上检查 tmsh list cm sync-status 和 tmsh list sys management-ip，确认同步状态和管理 IP 可达
• 云环境别依赖“自动切换”——Route 53 的 DNS 故障转移 TTL 至少 60 秒，ALB 本身无主备，所谓“备用”需提前部署独立 Target Group + Lambda 自动注册

真正棘手的不是单点故障，而是健康检查、会话保持、ssl 卸载、协议升级这几项交叉作用时的隐性冲突——比如 HTTP/2 客户端连 Nginx，但后端是 HTTP/1.1 spring Boot，又开了 proxy_http_version 1.1 却漏配 Connection 头，结果所有请求卡在 CONNECTING 状态。这种问题不会报错，只会让你盯着监控发呆。