负载均衡权重不均并非单纯配置问题，而是受健康状态、会话保持、连接复用、请求时长及算法选择等多重因素干扰；权重仅为初始参考，实际流量需结合运行态行为动态调优。
负载均衡转发权重不均，通常不是配置了权重就自动“按比例分配”的结果，而是受后端健康状态、会话保持（sticky session）、连接复用、请求处理时长、算法选择等多重因素干扰。核心在于：权重只是调度器的“初始参考”，实际流量分布需结合运行态行为综合调优。
检查健康检查是否导致节点被临时剔除
即使设置了 3:2:1 的权重，若某台服务器因健康检查失败（如响应超时、HTTP 5xx、TCP 端口不可达）被标记为 unhealthy，它将被完全摘除流量，剩余节点被迫承担全部压力，造成“权重失效”。
- 确认健康检查路径、间隔、超时、失败阈值是否合理（例如：/health 接口返回慢于检查超时，会被误判下线）
- 在控制台或 CLI 查看各后端实例当前状态（如 AWS ALB 显示 “OutOfService”，Nginx 显示 “unhealthy”）
- 临时关闭健康检查做对比测试（仅限非生产环境），观察权重是否回归预期
确认负载均衡算法与权重是否真正生效
不同 LB 类型对权重的支持方式不同，部分算法（如 least_conn、ip_hash、uri_hash）会忽略权重设置。
- Nginx 中：只有 round_robin 和 least_conn（开启
weight参数时）支持权重；ip_hash或hash $request_uri下权重无效 - 云厂商 LB（如阿里云 SLB、腾讯云 CLB）：需在监听规则中明确选择“加权轮询（WRR）”，而非“加权最小连接数”或“源IP一致性哈希”
- 验证方法：发起一批无状态、短连接请求（如 curl -s http://lb-ip/test | grep server-id），统计各后端命中次数，排除缓存或客户端重试干扰
排查连接复用与长连接影响
HTTP/1.1 默认 keepalive、gRPC 长连接、数据库连接池等场景下，单个客户端可能长期绑定到同一后端，使权重在连接粒度上失真。
- 查看后端连接数分布（如 netstat -anp | grep :port | wc -l），若某节点连接数远高于其他，说明连接未充分打散
- 在 LB 侧缩短 idle timeout（如从 3600s 改为 60s），促使连接更早释放并重新调度
- 对 gRPC 等长连接服务，启用客户端负载均衡（如使用 gRPC 的 round_robin 插件）或配合 DNS-RR + 客户端重试机制
监控与持续校准建议
权重不是一次配置永久有效的参数，需建立可观测闭环：
- 采集各后端的实时请求量、响应延迟、错误率、活跃连接数（Prometheus + Grafana 是常用组合）
- 当某节点延迟突增或错误率升高时，自动降低其权重（需 LB 支持动态 API，如 Nginx Plus、Traefik 或云厂商 SDK）
- 避免人为拍定权重，可基于 CPU 使用率 × 平均响应时间反推相对服务能力，再映射为初始权重
