负载均衡故障本质是转发链路中断，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 状态。这种问题不会报错，只会让你盯着监控发呆。
