直接看后端各节点的实际请求量和响应延迟更可靠：$upstream_addr记录转发地址，$request_time和$upstream_response_time反映耗时，聚合统计可发现请求倾斜；需排除“-”“*”等异常值，并结合stub_status与upstream状态交叉验证。
直接看后端各节点的实际请求量和响应延迟，比只盯配置更可靠。
用访问日志快速定位倾斜
Nginx 默认日志中 $upstream_addr 字段记录了每次请求实际转发到的后端地址，$request_time 和 $upstream_response_time 可反映处理耗时。按分钟或5分钟聚合统计，就能发现是否某台机器请求数远超其他节点。
- 例如用 awk 统计最近10分钟各后端请求数：
awk '$4 > "['$(date -d '10 minutes ago' +[%d/%b/%Y:%H:%M)']" {print $NF}' access.log | cut -d',' -f1 | sort | uniq -c | sort -nr - 若某台 server 出现次数是其他节点的2倍以上，且该现象持续数分钟，基本可判定分配不均
- 注意排除日志中 “-”（未转发）或 “*”（失败重试）等异常值
结合 stub_status 和 upstream 模块状态
启用 ngx_http_stub_status_module 后，访问 /nginx_status 可看到当前活跃连接、已接受请求数等全局指标；但真正关键的是配合 upstream 模块的内置变量，比如在日志中加入：
log_format main '$remote_addr - $remote_user [$time_local] "$request" $status $body_bytes_sent "$http_referer" "$http_user_agent" "$upstream_addr" $request_time $upstream_response_time';- 再通过
$upstream_http_x_server_id或自定义响应头让后端返回标识，可交叉验证转发路径是否与预期一致 - 如果用了
least_conn却长期看到某节点连接数偏低但请求量高，说明连接未及时释放或 keepalive 配置不合理
识别 IP 哈希类算法的隐性失衡
ip_hash 表面稳定，实则容易因客户端分布导致严重倾斜——尤其当大量用户来自同一 NAT 网关（如企业出口、校园网、云厂商 LB），它们的 前三段 IP 相同，全被哈希到同一台后端。
- 检查日志中 $remote_addr 的前缀分布：
awk '{print substr($1,1,index($1,".")-1)}' access.log | sort | uniq -c | sort -nr | head -5 - 若出现大量相同前缀（如 10.128、192.168、172.16），而对应后端请求数明显偏高，就是典型 ip_hash 失效场景
- 此时改用
hash $remote_addr consistent;或组合字段（如hash $remote_addr$http_user_agent;）能显著改善
长连接场景下四层负载的“假均衡”
四层（stream 模块）代理 TCP 连接时，least_conn 只在新建连接时生效；已有长连接不会迁移。一旦某节点刚恢复服务，新连接涌入，旧连接又迟迟不关闭，就会形成“新连接全打过去、老连接还挂在别处”的瞬时不均。
- 监控
netstat -ant | grep :PORT | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -nr查看各后端 IP 的活跃连接来源分布 - 对比
ss -s中的 ESTAB 数量与 upstream 中各 server 的 active connections（需开启 status 页面或用 lua 暴露） - 若某节点 ESTAB 连接数突增且长时间不降，而其他节点连接数偏低，说明算法在长连接生命周期内失效
