排查nginx代理后端负载不均，应先验证请求分配与真实负载是否一致：统计access日志中upstream_addr请求数，同步采集各节点ss -s连接数、top cpu及应用响应时间；若请求数均衡但连接/耗时失衡，说明轮询策略失效，需改用least_conn并禁用ip_hash等固化路由策略，配合健康检查与keepalive调优。

排查 Nginx 代理后端集群时的负载不均，关键不是看“谁接的请求少”，而是搞清“为什么真实压力分布不匀”。很多情况下，日志里各节点请求数差不多，但 CPU、连接数、响应时间却严重失衡——这说明问题出在调度逻辑与业务特征错配，而非配置写错了。

查清是请求分配不均，还是真实负载不均

先别急着改配置，分两步验证：

• 统计各后端节点收到的请求数：在 access 日志中按 upstream_addr 或自定义变量（如 $upstream_http_x_backend）分组计数，确认轮询是否真的“没轮匀”
• 同步采集真实负载指标：登录每个后端服务器，运行 ss -s | grep estab 查活跃连接数，用 top -b -n1 | head -20 看 CPU 和内存占用，再查应用层响应时间（如 Tomcat 的 access log 中 $time_taken）
• 若请求数接近但连接数/耗时差异大，说明轮询策略失效——它只管“派几次”，不管“连多久、跑多慢”

优先换 least_conn 策略，尤其存在长连接或性能差异

轮询对短平快请求有效，但遇到 WebSocket、文件上传、HTTP/2 流或后端机器配置不一时，极易堆积连接。least_conn 直接基于当前活跃连接数选节点，更贴近实际压力：

linux-performance-analyzer

Linux 性能分析与调优专家，覆盖 CPU、内存、磁盘 I/O、网络、内核参数、编译优化、容器/K8s。适用场景：系统卡顿/高负载、内存不足/OOM/Swap 高、CPU 异常/iowait 高。

下载

• 在 upstream 块开头加 least_conn;（Nginx 1.15+ 支持加权，可保留 weight 参数）
• 禁用 ip_hash 或 hash $request_uri——这些会固化路由，让某些节点长期“被绑定”，反而加剧不均
• 配合 keepalive 设置（如 keepalive 32），避免连接复用导致的单点扎堆

补全健康检查，防止“假存活”吸走流量

一台后端进程僵死、TCP 端口仍通，但 HTTP 返回超时或 500，Nginx 默认轮询还会持续转发——等于把本就吃紧的请求全塞给它。

• 为每个 server 显式配置：max_fails=2 fail_timeout=10s，让 Nginx 主动踢出异常节点
• 若后端提供 /health 接口，建议编译安装 nginx_upstream_check_module，启用主动探测（interval=3s, fails=2, passes=2）
• 预留人工干预通道：用 down 标记临时下线，或 backup 设备用节点

收紧 keepalive 和超时参数，匹配后端真实行为

后端开启 keepalive 后，一个 TCP 连接可能复用上百次请求，而轮询只统计“发了多少次”，不反映“连在谁身上”。这时连接分布比请求数更有说服力：

• upstream 块中设 keepalive 32;（并发高可调至 64，低则 16）
• location 中关闭客户端连接复用：proxy_http_version 1.1; proxy_set_header Connection '';
• 后端同步调小 keepalive_timeout（如 Tomcat 的 keepAliveTimeout 设为 15–30s），避免空闲连接长期占位
• 调优超时：proxy_connect_timeout 15s; proxy_send_timeout 60s; proxy_read_timeout 60s，既防误判，也不掩盖真瓶颈