负载均衡需深入网络、健康检查、会话、权重与安全五大陷阱。常见问题包括网络平面错位、健康检查未反映真实业务状态、会话丢失、静态权重失效及安全策略误伤，须结合真实场景验证与动态治理。
负载均衡不是加个Nginx或配个SLB就完事了。真正出问题，往往发生在流量真正进来之后——连接超时、会话丢失、健康检查一直绿但用户打不开页面、半夜告警说某台机器CPU 100%却没人被分到它上面。这些都不是配置没生效，而是配置“看起来对”，实际逻辑断层。
网络连通性陷阱：容器和云主机都连得上，但负载均衡器就是不通
常见于Docker Swarm、K8s Ingress或自建Nginx反代场景。根本原因不是端口没开，而是网络平面错位：
- 容器默认bridge网络不支持服务名解析，Nginx用
upstream backend { server web1; }会直接报invalid hostname - 云上LB后端节点未加入同一VPC子网，或安全组只放行了80/443，却忘了健康检查探测端口（如TCP 22或HTTP /healthz）
- 混合部署时，物理机上的Nginx想代理K8s Service ClusterIP，结果ClusterIP仅在Pod网络内有效，外部不可达
验证方法：从负载均衡器所在节点执行curl -v http://后端服务IP:端口/healthz，而非只测telnet端口通不通。
健康检查失效：绿灯亮着，服务早已挂掉
健康检查配置错误是“最安静的灾难”。表面一切正常，实则请求持续打到宕机实例：
- HTTP健康检查路径返回200，但业务已卡死（比如DB连接池耗尽，接口返回空JSON+200）
- 检查间隔设为30秒，超时设为5秒，失败阈值为3次——意味着故障最长可能135秒才被摘除
- K8s中livenessProbe与readinessProbe混淆：把应判断“是否可服务”的readiness写成“是否进程存活”的liveness
建议：健康检查端点必须真实反映业务就绪状态（如校验DB连接、缓存连通性），且响应时间应远小于检查间隔。
会话与路由不一致：用户反复登录、购物车清空、支付跳转失败
本质是负载均衡策略与应用状态模型不匹配：
- 使用纯轮询或随机算法，但应用依赖本地session（如Tomcat内存Session），导致第二次请求落到无上下文的节点
- HTTPS卸载在LB层，但后端应用又自己重定向HTTP→HTTPS，形成302跳转死循环
- 客户端IP丢失：Nginx未配置
proxy_set_header X-Real-IP $remote_addr;，日志和风控系统拿到的全是LB内网IP
解法优先级：改用ip_hash临时保会话 → 迁移至Redis集中式Session → 前端Token化 + 后端无状态设计。
权重与扩缩容脱节：手动调权重，自动扩缩容后全作废
在K8s或Serverless场景下，静态权重配置极易失效：
- Dubbo中通过
- Nginx upstream里写死
server 10.0.1.10 weight=3，而实际节点由Autoscaler动态增减，IP列表已变更 - 云厂商SLB控制台设置的权重，无法随实例标签或命名空间变化自动更新
可靠做法：放弃IP/实例粒度的静态权重，改用基于指标的服务发现（如Prometheus + Consul，按延迟/错误率动态调整）或K8s EndpointSlice + service-mesh（如Istio）的流量切分能力。
安全隐性风险：看似加固，实则埋雷
不少团队在负载均衡层做了大量“安全配置”，反而引入新漏洞：
- 为防CC攻击，在Nginx加了
limit_req，但没配burst和nodelay，导致合法突发流量（如秒杀开场）全部503 - 启用WAF规则拦截SQL注入，却把
union select等关键词写进正则，误杀正常业务字段（如用户昵称含“select”） - 将证书私钥直接挂载进Nginx容器，且未限制文件权限（644），一旦容器逃逸即可被读取
关键原则：所有防护策略必须先在灰度流量上验证误杀率；证书类敏感数据统一由Secret管理，禁止硬编码或明文挂载。
