$upstream_addr字段直观反映请求真实落地的后端地址，而非理论分配逻辑；它以逗号分隔多次尝试地址，内部重定向用冒号分隔，全失败时显示upstream名称。
直接看 $upstream_addr 字段的实际分布，比检查 upstream 配置或算法参数更直观有效——它记录的是每次请求真实落地的后端地址，不是理论分配逻辑，而是真实流量去向。
用日志统计各节点请求数，识别明显倾斜
在 access.log 中提取 $upstream_addr 并按时间窗口聚合，能快速暴露不均现象：
- 执行命令统计最近5分钟各后端请求数： awk '$4 > "['$(date -d '5 minutes ago' +[%d/%b/%Y:%H:%M)']" {print $NF}' /var/log/nginx/access.log | cut -d',' -f1 | grep -v '\-\|*' | sort | uniq -c | sort -nr
- 若某台 server 出现次数是其他节点的2倍以上，且持续超过3分钟，基本可判定分配失衡
- 注意过滤掉“-”（未转发）和“*”（重试失败标记），避免干扰统计结果
结合状态码与响应时间，区分“假均衡”和真故障
单纯请求数多不等于问题，需联动 $status 和 $upstream_response_time 判断性质：
- 高频出现但错误率低、响应快 → 可能是算法本意（如 least_conn 在短连接下表现异常）
- 高频出现且 5xx 占比高或 $upstream_response_time 普遍 >2s → 很可能是该节点处理能力不足或存在隐性故障
- 某节点请求数偏低但 $upstream_response_time 极长 → 可能因 keepalive 连接未释放，导致 least_conn 误判为“空闲”
排查 ip_hash 类算法的隐性失衡
ip_hash 表面稳定，实际极易因客户端 IP 分布集中而失效：
- 检查 $remote_addr 前缀是否大量重复： awk '{print substr($1,1,index($1,".")-1)}' /var/log/nginx/access.log | sort | uniq -c | sort -nr | head -5
- 若出现大量 10.128、192.168、172.16 等私有网段前缀，且对应 $upstream_addr 高频出现 → 典型 NAT 网关导致的哈希坍塌
- 改用 hash $remote_addr consistent 或组合字段如 hash $remote_addr$http_user_agent 可显著改善
验证转发路径是否与预期一致
$upstream_addr 是真实路径，但需排除代理链路错位或配置漂移：
- 在 log_format 中同时记录 $upstream_http_x_server_id（后端返回的唯一标识头），比对是否与 $upstream_addr 匹配
- 若某次请求日志中 $upstream_addr 显示为 A，但 $upstream_http_x_server_id 返回 B → 说明存在中间代理或 header 被篡改
- 启用 stub_status 后访问 /nginx_status，观察 active connections 分布，再与 $upstream_addr 统计交叉比对，确认连接数与请求数趋势是否同步
