负载均衡看起来不起作用，为什么负载均衡没效果？

当运维人员发现负载均衡器配置完成后，所有流量依然集中在一台服务器上，或者请求频繁报错时，第一反应往往是“负载均衡不起作用”，基于多年的架构运维经验，核心上文归纳是：负载均衡软件或硬件本身极少出现功能性失效，所谓的“不起作用”通常源于健康检查机制配置不当、会话保持策略误用、客户端连接复用特性或权重分配错误。 解决这一问题需要从协议栈、应用层配置以及客户端行为三个维度进行深度排查,而非盲目重启服务。

健康检查机制失效导致节点被剔除

这是导致负载均衡看起来失效的最常见原因之一，负载均衡器的核心任务是分发流量，但它必须依赖健康检查来判断后端节点是否存活，否则，流量会被分发到一台实际上已经“假死”的服务器上，导致用户访问失败，从而给人一种“负载均衡没起作用”的错觉。

问题根源： 许多默认的健康检查配置过于简单，Nginx或F5默认可能只检查TCP端口是否连通，如果后端服务Web容器（如Tomcat或Nginx）进程存在，但应用线程池已满或出现死锁，TCP端口依然是通的，健康检查会判定为“健康”，负载均衡器继续将大量请求转发给这台“假死”的服务器,所有请求随即超时或报错。

专业解决方案： 必须实施应用层健康检查，不要仅依赖TCP握手，而应该配置负载均衡器定期请求后端的一个特定的轻量级URL（如/health_check.html或/api/status），该接口应当直接连接数据库或缓存进行简单的查询，确保全链路通畅，只有当该接口返回HTTP 200状态码时，才判定节点存活，合理设置fall（失败次数）和rise（成功次数）参数,避免因网络抖动导致节点频繁上下线。

会话保持导致的流量倾斜

在无状态的服务架构设计中，会话保持有时是必须的,但它也是导致流量分布不均的罪魁祸首。

问题根源： 如果负载均衡器配置了基于源IP哈希的算法，或者开启了基于Cookie的会话粘滞，那么来自同一个客户端（或同一个公网IP出口，如NAT环境下的整个公司）的所有请求都会被强制分发到同一台后端服务器，在进行压力测试时，如果测试机器数量较少，就会观察到流量全部打在一台机器上，其他机器闲置，这并非负载均衡失效,而是配置策略与当前流量模型不匹配。

专业解决方案： 确认业务是否真的需要会话保持，现代微服务架构提倡无状态设计，应将会话数据存储在Redis等共享存储中，从而关闭负载均衡器的会话保持功能，启用加权轮询或最小连接数算法，如果必须开启会话保持，建议使用基于Cookie的插入模式而非基于源IP，因为基于源IP在NAT环境下极易造成负载极度不均，在压测场景下，必须模拟大量不同的源IP进行测试,才能验证负载均衡的真实效果。

HTTP Keep-Alive与连接复用的误区

这是一个非常隐蔽且容易被忽视的因素,特别是在开发人员使用浏览器或简单的测试工具进行验证时。

问题根源： 现代浏览器和HTTP客户端默认都开启了Keep-Alive，这意味着，浏览器会与负载均衡器建立一个TCP连接，并在该连接上发送多个请求，如果负载均衡器工作在七层模型，且后端连接复用策略配置得当，那么这一个TCP连接对应的后端连接也可能被复用，当你打开浏览器刷新页面时，你看到的始终是同一台后端服务器的日志，因为浏览器根本没有断开连接,负载均衡器也就没有机会重新进行哈希计算或轮询选择新的后端节点。

专业解决方案： 理解长连接与负载分发的关系，要验证负载均衡是否工作，不能仅靠浏览器刷新，应使用命令行工具如curl，显式添加Connection: close头，或者使用Apache Bench（ab）、JMeter等压测工具，并设置较高的并发数，检查负载均衡器的keepalive配置，确保上游连接池的大小设置合理,避免单个连接占用过多资源导致无法分发到其他节点。

权重配置与算法选择错误

负载均衡确实在工作，但工作得“不均匀”,这通常被误认为是不起作用。

问题根源： 在加权轮询算法中，如果后端服务器性能差异较大，管理员通常会手动设置权重，如果误将高性能服务器的权重设置得极低（例如1），而低性能服务器权重设置得极高（例如100），流量自然会大量倾斜，如果使用了“源地址哈希”算法但客户端IP数量极少（如只有几个代理服务器）,哈希环的分桶会导致严重的分配不均。

专业解决方案： 审查配置文件中的weight参数，确保其与服务器硬件性能成正比，对于通用的Web服务，建议优先使用最小连接数算法，该算法会动态地将新请求分发给当前并发连接数最少的服务器，这比单纯的轮询更能应对突发流量，也能在服务器处理变慢时自动减少分配给它的任务，实现真正的“智能”均衡。

网络层与防火墙的隐形阻断

在复杂的云原生或混合云环境中,网络层面的限制往往让负载均衡看起来失效。

问题根源： 负载均衡器本身运行正常，但在转发数据包到后端节点时被安全组、内部防火墙或iptables规则拦截，四层负载均衡（如LVS的NAT模式）修改了数据包的IP地址，如果后端服务器的网关没有正确指向负载均衡器，或者回包路径不一致，就会导致连接超时，日志中可能看不到任何请求记录,或者只看到SYN包丢弃。

专业解决方案： 使用tcpdump在负载均衡器和后端服务器两侧同时抓包，如果负载均衡器发出了请求但后端未收到，检查中间链路；如果后端收到了但未回包，检查应用响应；如果后端回了包但负载均衡器未收到，检查路由回包路径，确保安全组放行了负载均衡器与后端节点之间的通信端口，特别是对于健康检查端口，必须放行且不可被应用层防火墙（如WAF）误杀。

相关问答

Q1：为什么后端服务日志显示请求来自负载均衡器的IP，而不是真实用户的IP？这是负载均衡配置错误吗？

A： 这不是配置错误，而是四层负载均衡（或未配置X-Forwarded-For的七层负载均衡）的标准行为，在NAT模式下，后端节点看到的源IP自然是负载均衡器的VIP或内网IP，要获取真实IP，需要在七层负载均衡器（如Nginx、HAProxy）上配置X-Forwarded-For头字段传递，或者配置Proxy Protocol协议将原始连接信息透传给后端,后端应用也需要相应配置以读取该头部。

Q2：在Kubernetes环境中，Service的负载均衡不生效怎么办？

A： Kubernetes Service默认使用kube-proxy实现负载均衡，如果发现不生效，首先检查Service的类型是否正确，如果是ClusterIP，确保Pod的readinessProbe配置正确，未就绪的Pod会被自动从Endpoints列表中剔除，导致流量无法到达，检查externalTrafficPolicy设置，如果设置为Local，流量将保留源IP，但可能会跳过跨节点的Pod，导致负载不均，建议在排查时查看kubectl get endpoints，确认后端Pod IP是否正确注册。

您在配置负载均衡时还遇到过哪些令人困惑的现象？欢迎在评论区分享您的排查思路,我们一起探讨更优的解决方案。