直接看日志里的 $upstream_addr，再结合状态码和响应时间，就能快速锁定哪台后端在报错——它记录的是 Nginx 实际连上的真实地址（IP:Port），不是配置里写的“可能”，而是已经发生的连接。
直接看日志里的 $upstream_addr，再结合状态码和响应时间，就能快速锁定哪台后端在报错——它记录的是 Nginx 实际连上的真实地址（IP:Port），不是配置里写的“可能”，而是已经发生的连接。
从 5xx 错误中揪出高频故障节点
线上随机出现 502、504 或其他 5xx 报错时，别只 grep 状态码。用以下命令快速聚焦问题机器：
- 提取所有 5xx 请求对应的后端地址：
grep ' 5[0-9][0-9] ' /var/log/nginx/access.log | awk '{print $NF}' | grep -v '[-*]' | sort | uniq -c | sort -nr - 若某地址如
10.0.1.12:8080高频出现在结果顶部，说明它贡献了大量失败请求 - 特别关注首次转发就失败的地址：重试路径中逗号前第一个值（如
10.0.1.12:8080, 10.0.1.11:8080中的前者）若频繁报 502，说明该节点本身不可靠
区分“真故障”和“假异常”
请求数多不等于有问题，得联动其他字段交叉判断：
- 查该节点是否同时伴随慢响应：
awk '$NF ~ /10\.0\.1\.12:8080/ && $5 > 2 {print}' access.log | wc -l—— 若慢响应占比高，大概率是业务处理卡顿或资源耗尽 - 对比 $upstream_status 序列：若日志显示
502,200，说明第一次失败、第二次成功；若全是502,502，说明重试也无效，节点已完全不可用 - 检查 $upstream_response_time 是否为 “-”：如果是，代表连接阶段就失败（如端口未监听、网络不通），不是业务层问题
用响应头透传做闭环验证
仅靠 Nginx 日志可能被代理链路干扰。让后端主动返回唯一标识，与 $upstream_addr 对齐验证：
- 在 upstream 块中为每台机器设 ID：
server 10.0.1.12:8080 id=be-c; - 用 map 将地址映射为可读名：
map $upstream_addr $backend_id { ~10\.0\.1\.12:8080 "be-c"; } - 透传到响应头：
proxy_set_header X-Backend-ID $backend_id; - 收到响应后比对
X-Backend-ID和日志中 $upstream_addr：二者一致才确认请求真落到了目标节点，排除中间代理篡改或路由错位
排查常见干扰项
当 $upstream_addr 显示的地址与预期不符，优先检查这几项：
- upstream 配置是否用了域名？DNS 解析结果可能变化，$upstream_addr 显示的是实际解析 IP，不是你记忆中的“固定地址”
- 是否启用了
least_conn或random？这类策略本身就会导致分布波动，不能单凭一次统计就断定异常 - 日志中该字段是否为空或为 “-”？说明请求根本没走到 proxy_pass（比如被 rewrite 截断、匹配了 return、或静态规则提前返回）
- 是否开了
proxy_next_upstream但没配proxy_next_upstream_tries？可能导致重试未生效，$upstream_addr 只显示一个地址，掩盖真实流转路径
