负载偏差主因是算法与业务特征不匹配，需先区分流量分配不均或处理压力不均；推荐least_conn策略应对响应差异与长连接，辅以健康检查和按业务哈希分流。
负载偏差不是“分错了”，而是算法、健康状态或业务特征没对上。先确认是流量分配不均，还是后端实际处理压力不均，再针对性调整。
看清楚到底是哪类不均
加权轮询只管请求数比例，不管响应快慢或连接长短。比如一台 weight=2 的服务器接口平均耗时 2 秒，另一台 weight=1 的只要 200 毫秒，实际并发连接数可能差好几倍。大量长连接（如 WebSocket）持续占着某台机器，轮询还在不断派新请求过去，也会造成表象过载。真有问题的表现是：日志里某台 server 请求量明显偏离 weight 设定比例（例如 3:1 配置下却接近 8:2）。
优先换 least_conn 策略
它把新请求发给当前活跃连接数最少的后端，天然适配响应时间差异大、长连接多的场景：
- 配置只需在 upstream 块中加一行 least_conn;
- 支持和 weight 共存（Nginx 1.15+），既照顾性能差异，又反映实时负载
- 比轮询更贴近真实资源占用，尤其适合文件上传、SSE、WebSocket 类服务
补全健康检查，别让“假活”节点吸流
后端进程僵死、TCP 端口通但 HTTP 返回超时或 500，轮询仍会继续转发：
- 每个 server 加上 max_fails=2 fail_timeout=10s，连续失败 2 次就暂停 10 秒
- 若后端提供 /health 接口，可配合 nginx_upstream_check_module 做主动探测（需编译安装）
- 用 down 或 backup 标记，保留人工干预入口
按业务选更匹配的分流方式
固定 IP 用户反复访问同一台后端，可能因 session 本地化导致某台过热；随机 URI 则易引发缓存击穿：
- 有登录态或依赖本地 session：用 ip_hash 保证会话粘性（注意 NAT 下 IP 集中问题）
- 读多写少、静态资源多：用 hash $request_uri consistent 提升缓存命中率
- 灰度发布场景：按请求头哈希，例如 hash $http_x_version 隔离新老版本流量
