关键不是看配置写了什么，而是验证流量实际打到了哪里、打得多不多、节点扛不扛得住：查真实请求分发比例，核对权重是否匹配CPU/内存等实际服务能力，并检查健康检查是否“假活着”及是否配置max_conns等硬限防止单点过载。
排查因负载均衡权重分配不均导致的后端过载，关键不是看“配置写了什么”，而是验证“流量实际打到了哪里、打得多不多、节点扛不扛得住”。重点抓三点：真实流量分布、节点健康状态、权重与能力是否匹配。
查真实请求分发比例，别信理论权重
权重只是调度器的“意愿”，实际分发受连接复用、长连接、健康状态影响很大。必须从日志或监控中确认真实流向：
- 在 upstream 配置中开启日志变量，例如：
log_format upstream_log '... $upstream_addr $upstream_response_time';，通过分析 access 日志统计各后端 IP 的请求占比 - 用 nginx stub_status 模块（需编译启用）查看实时活跃连接数：
Active connections: 1243+Reading: 2 Writing: 1221 Waiting: 0，再结合upstream_addr字段聚合，能看出哪台 server 当前连接最多 - 如果用了 keepalive 连接池，注意轮询可能长期复用旧连接——此时
least_conn或max_conns比 weight 更能反映真实压力
核对权重设置是否匹配真实服务能力
weight 不是拍脑袋定的，它应反映 CPU、内存、磁盘 I/O 等综合吞吐能力比值：
- 比如两台机器：A 是 8C16G，B 是 4C8G，理论算力比约 2:1，但若 B 还跑着定时任务或日志采集，实际可用资源可能只剩 60%，这时 weight 设为 2:1 就会压垮 B
- 检查 后端服务自身指标：CPU 使用率持续 >85%、GC 频繁、线程池满、数据库连接池耗尽——这些才是过载信号，而非 Nginx 日志里的 502/504
- 临时把疑似过载节点的 weight 调低（如从 10 改为 3），观察其 CPU 和响应时间是否明显回落；若无改善，问题可能不在权重，而在该节点本身或上游限流不足
看健康检查有没有“假活着”
一台服务器 HTTP 健康探针返回 200，但业务接口已卡在慢查询上，Nginx 仍会持续转发请求——这就是典型的“假活着”：
- 检查 proxy_next_upstream 是否包含
timeout http_500 http_502 http_503 http_504，确保错误响应能触发重试 - 确认 max_fails / fail_timeout 设置足够激进，例如
max_fails=2 fail_timeout=15s，避免默认的“1 次失败就踢出”太保守，或“10 秒才恢复”太迟钝 - 若条件允许，接入 nginx_upstream_check_module，配置独立的
/health探针（检查 DB 连通性+线程池水位），比被动靠业务响应更早发现隐患
加一层连接与请求硬限，防单点被冲垮
即使权重合理、健康检查正常，突发流量或慢接口也可能让某台节点瞬间堆积连接：
- 在 upstream 中为每个 server 加 max_conns，例如：
server 192.168.1.10:8080 weight=5 max_conns=300;，超过即跳过 - 在 location 块里配 limit_conn 和 limit_req，按
$upstream_addr限流，防止某台后端被同一类请求集中攻击 - 调小 proxy_read_timeout（建议 5–8 秒）和 proxy_connect_timeout（建议 2–3 秒），避免 worker 进程被慢响应长期占用
