加权轮询不感知延迟，高权重节点网络变慢时仍强塞流量，反而放大整体延迟；排查重点是实际运行稳定性而非配置正确性，需通过access_log统计真实流量占比、检测建连耗时与RTT、分析各节点P95响应时间及错误日志，并可临时降权或隔离验证。
加权轮询本身不感知延迟，高权重节点一旦网络变慢，流量仍会按比例强塞过去，反而放大整体延迟。排查重点不是“它配得对不对”，而是“它现在跑得稳不稳”。
看实际流量是否真按权重分配
权重只是调度概率，不代表真实流量比例。先确认是不是权重配置生效了：
- 在 access_log 中加入 $upstream_addr 和 $request_time，采样 1000 次请求，用 awk 统计各后端出现次数占比，对比配置权重比（如 weight=5:2:1 → 理论应≈62.5% : 25% : 12.5%）
- 若实际比例严重偏离，检查是否漏写 weight=（Nginx 默认 weight=1，未显式声明会覆盖继承）、或 upstream 块被多处 include 导致重复定义
- 注意：keepalive 连接复用会让单个 worker 长期绑定某后端，导致局部流量倾斜，这不是权重问题，而是连接池行为
查高权重节点的 RTT 和建连耗时
高权重 ≠ 高性能。它可能正经历网络抖动或 TCP 层异常：
- 从 Nginx 所在机器执行：tcpping -x 5 192.168.1.10 8080，测真实服务端口建连延迟；单纯 ping ICMP 可能绕过防火墙或被限速，不反映真实情况
- 用 mtr --report-cycles 20 192.168.1.10 查中间跳点丢包/抖动，尤其关注第 3–5 跳（常为网关或负载设备）
- 对比该节点的 $upstream_connect_time（Nginx 建连耗时）和 $upstream_header_time（收到响应头时间）：若 connect_time > 50ms，说明网络或后端监听队列已成瓶颈
比对延迟毛刺是否集中在高权重点
用日志定位是“均匀慢”还是“个别拖后腿”：
- 提取 P95 $upstream_response_time，分 server 统计：如果 weight=5 的节点 P95 达 1200ms，而 weight=1 的才 180ms，说明高权重正在把用户拖进泥潭
- 检查该节点 error.log 是否有大量 "upstream timed out" 或 "no live upstreams"，结合 max_fails=2 fail_timeout=15s 是否及时剔除它
- 注意：若 $request_time 明显大于 $upstream_response_time，问题不在后端，而在 Nginx 本体（如 gzip 压缩、SSL 握手、Lua 脚本阻塞）
临时验证：降权或隔离观察
不重启、不改全局策略，快速验证是否为该节点所致：
- 编辑 upstream 块，对该高权重节点临时加 weight=1 max_fails=1 fail_timeout=10s，reload 配置
- 观察整体 P95 延迟是否明显回落、错误率是否下降；若改善显著，基本锁定问题源
- 进一步可配合 backup 标记该节点，只在其他全挂时启用，彻底隔离影响
