通过分析 $upstream_addr 分布可客观评估负载均衡均匀性：统计各节点实际请求数、结合响应时间与状态码识别倾斜、慢节点及故障集中点，并验证算法真实分发逻辑。
直接看 $upstream_addr 字段的分布，再结合请求量、响应时间与状态码，就能客观评估负载均衡是否真正均匀——它记录的是每次请求实际落到哪台后端，不是配置列表，而是真实转发路径。
统计各节点实际承接请求数
用日志提取 $upstream_addr 并按频次排序，是最基础也最有效的倾斜识别方式：
- 过滤掉空值（如 “-” 或 “*”），只统计成功转发的记录
- 命令示例：
awk '$NF != "-" && $NF != "*" {print $NF}' access.log | sort | uniq -c | sort -nr - 若某地址出现次数是其他节点平均值的 2 倍以上，且持续 5 分钟以上，基本可判定分配不均
关联响应时间定位隐性瓶颈
请求数均衡 ≠ 处理能力均衡。高频出现的节点如果伴随高 $upstream_response_time，说明它可能成为拖慢整体的“慢节点”：
- 单独筛选慢响应：例如
awk '$(NF-1) > 3 {print $NF}' access.log（假设倒数第二字段为 upstream_response_time） - 交叉分析：把“高频地址”和“慢响应地址”取交集，重合度高的就是重点排查对象
- 注意区分：$upstream_response_time 为 “-” 表示连接失败，属于网络或服务不可达问题；数值大但非 “-”，才是后端处理慢
结合状态码识别故障集中点
5xx 错误不是随机发生的，往往集中在特定后端。通过 $upstream_addr 和 $upstream_status 联动分析，能快速归因：
- 提取所有 5xx 上游状态：
awk '$6 ~ /^5[0-9]{2}$/ {print $7}' access.log | sort | uniq -c | sort -nr（假设第6列为 $upstream_status，第7列为 $upstream_addr） - 若某地址在错误日志中占比超 30%，而总请求数占比不足 15%，说明该节点稳定性显著低于集群均值
- 配合 $upstream_response_time 看趋势：504 高发 + 长耗时 → 检查 proxy_read_timeout 与后端处理能力匹配度
排除算法假象，验证真实分发逻辑
某些算法表面均衡，实则受客户端特征影响严重。借助 $upstream_addr 可反向验证是否符合预期：
- 对 ip_hash 场景，检查 $remote_addr 前缀分布：大量相同 C 段 IP 对应同一后端，就是 NAT 环境下的哈希失衡
- 对 least_conn 场景，对比 stub_status 中的 active connections 与 $upstream_addr 统计结果：若某节点连接数低但请求量高，说明 keepalive 连接未及时释放
- 启用 proxy_next_upstream 后，$upstream_addr 出现逗号分隔多个地址（如
10.0.1.10:8080, 10.0.1.11:8080），说明发生重试——重试集中在哪一跳，就暴露哪台机器不稳定
