负载均衡出问题的负载时候，最怕的均衡件排就是软硬件两头互相甩锅。应用团队说是软件网络问题，网络团队说是和硬服务器问题，服务器团队又说是查需负载均衡配置问题。转了一圈，负载问题还在那里，均衡件排用户那边已经骂翻了天。软件

我遇到过最典型的和硬一次故障，半夜两点，查需前端Nginx集群的负载流量全部打到一台后端机器上，其他几台机器闲着看热闹。均衡件排监控面板上那台机器的软件CPU曲线直接拉满成一条直线，像心电图里那种要命的和硬平直线。当时第一反应是查需负载均衡算法出了问题，赶紧查配置，轮询没错，权重没错，健康检查也没错。折腾了半个小时，最后才发现是那台机器的网卡固件版本和交换机不兼容，导致TCP连接全被重置。负载均衡软件很无辜，它确实把请求分发过去了，但连接建立不起来，重试机制又把所有流量都导给了那台“看起来还活着”的机器。

所以排查负载均衡，得先分清楚你面对的是软件问题还是硬件问题。软件层面，先别看什么高深的指标，直接看日志。Nginx的error.log、HAProxy的stats页面、LVS的ipvsadm -L -n，这些是最基础的东西。日志里如果出现大量“upstream timed out”或者“connection reset by peer”，那基本能锁定是后端服务的问题。如果日志干干净净，但前端请求就是过不来，那八成是防火墙规则、路由表或者内核参数在捣乱。特别是Linux服务器上，net.ipv4.tcp_tw_reuse、net.core.somaxconn这些参数，改没改过，改了之后有没有生效，都能让负载均衡的表现天差地别。

硬件负载均衡又是另一套逻辑。F5、A10这些设备，你没法像Linux那样直接tail日志，得登录管理界面去看。很多运维人员习惯性地只看虚拟服务器的状态，绿了就以为万事大吉。但硬件设备有个坑——会话保持。如果开了源地址会话保持，而某个用户的出口IP是动态的，那他的请求可能会被固定到某一台后端服务器上。那台服务器挂了，这个用户的所有请求都会失败，但负载均衡的监控面板上看，其他服务器都是健康的，虚拟服务也是绿色的。这时候你查配置、查日志都没用，得去看会话表，看是不是有大量残留的会话条目把流量卡死了。

还有个容易忽略的地方，就是负载均衡设备自身的性能瓶颈。软件负载均衡跑在高配置的x86服务器上，CPU、内存、网卡吞吐量都够，但别忘了看软中断的分布。多队列网卡如果没绑定到不同的CPU核心，所有中断都挤在一个核上，那这个核会被打满，其他核闲着。你从系统层面看CPU总使用率只有30%，但那个负责处理网络中断的核已经100%了。硬件负载均衡也有类似的坑，特别是SSL卸载功能，加解密运算会消耗大量的专用芯片资源，如果并发连接数超过了设备的性能上限，丢包率会直线上升，但设备本身不会报错。

排查的时候，别急着下结论。先做一次端到端的连通性测试，从客户端直接curl后端的真实IP，确认后端服务本身没问题。然后再把请求打到负载均衡的虚拟IP上，看能不能正常转发。这一步能帮你快速缩小范围——如果直连后端没问题，但经过负载均衡就出问题，那问题肯定在负载均衡这一层。接下来才去检查配置、日志、会话表、性能指标，按这个顺序来，别一上来就翻配置文件，那样容易看漏东西。

最后说个实用的技巧。无论是软件还是硬件负载均衡，都建议开启详细的访问日志，记录下客户端IP、后端服务器IP、响应时间、状态码。出了问题，先看日志里失败请求的分布——是集中在某个时间段，还是集中在某个后端IP，还是集中在某种类型的请求上。这个分布能直接告诉你排查方向，比瞎猜配置要高效得多。别嫌日志占磁盘空间，关键时刻，那几GB的日志能救你的命。