$upstream_addr能精准定位随机502故障节点，因其记录真实后端IP:port及重试路径，结合$upstream_status可区分首次失败或重试失败，并需配合proxy_next_upstream配置与日志分析验证。
在生产环境中，Nginx 返回 502（Bad Gateway）通常意味着上游服务不可达或响应异常。但若问题“随机出现”，说明不是全量失败，而是部分请求偶发失败——这时仅靠 status 和 request_time 很难定位具体是哪个 upstream server 出了问题。引入 $upstream_addr 到 log_format 是最直接、低侵入的排查手段，它能明确记录每次请求实际转发到的后端地址（含 IP:port 和连接状态），帮你快速聚焦故障节点。
为什么 $upstream_addr 能解决“随机 502”定位难题
$upstream_addr 记录的是 Nginx 实际与 upstream 建立连接的后端地址，格式如：
10.1.2.3:8080, 10.1.2.4:8080, 10.1.2.5:8080（负载均衡多选）
10.1.2.3:8080, 10.1.2.3:8080（重试两次同一台）
10.1.2.3:8080, 10.1.2.4:8080, 10.1.2.5:8080, 10.1.2.6:8080（重试三次不同节点）
关键点：
- 它不依赖 upstream 名称，而是真实 IP+端口，避免 DNS 缓存或配置别名带来的歧义
- 包含重试路径，502 日志中若看到 10.1.2.3:8080, 10.1.2.4:8080 且最终失败，说明第一次失败后重试另一台也失败；若只有单个地址，则大概率是该节点独有问题
- 结合 $upstream_status（如 502, 502 或 502, 200）可判断是首次失败还是重试才成功
正确配置 log_format 并启用 upstream 相关变量
确保你的 log_format 中包含以下变量，并在 access_log 中引用：
-
必须启用
proxy_next_upstream和相关超时设置，否则 Nginx 不会触发重试，$upstream_addr可能只显示一个地址，无法反映真实流转逻辑。例如：
proxy_next_upstream error timeout http_502;
proxy_next_upstream_tries 3;
proxy_next_upstream_timeout 3s;
- 定义带 upstream 信息的日志格式（推荐）：
log_format upstream_log
'$remote_addr - $remote_user [$time_local] "$request" '
'$status $body_bytes_sent "$http_referer" "$http_user_agent" '
'$request_time $upstream_response_time $upstream_addr $upstream_status $upstream_http_x_request_id';
- 在 server 或 location 块中启用该日志：
access_log /var/log/nginx/upstream.log upstream_log;
⚠️ 注意：$upstream_addr 和 $upstream_status 在请求未进入 upstream 阶段时为空（如 SSL 握手失败、rewrite 拦截），所以务必确认 502 确实来自 proxy_pass 流程。
从日志中快速识别问题节点（实操建议）
收集一段时间（如 1 小时）的 upstream.log，用如下命令分析：
-
统计所有 502 请求中出现频次最高的 upstream 地址：
awk '$9 == "502" {print $12}' upstream.log | sort | uniq -c | sort -nr | head -20
（假设$upstream_addr是第 12 列，按实际列数调整） -
查看某台疑似故障节点的完整行为：
grep "10.1.2.3:8080" upstream.log | grep " 502 "
观察是否集中出现在某段时间、是否伴随高$upstream_response_time、是否总是重试后仍失败 -
比对健康节点 vs 故障节点的响应时间分布：
提取$upstream_response_time（逗号分隔，取第一个值即可）和对应地址，画出直方图或简单统计均值/95 分位，故障节点往往响应时间长尾明显
配合其他手段交叉验证
$upstream_addr 是线索，不是结论。需进一步验证：
- 登录对应 IP 的后端机器，检查其本地日志（尤其是 502 对应时间点是否有 OOM、线程阻塞、DB 连接池耗尽）
- 用
curl -v http://10.1.2.3:8080/health快速探测该节点连通性与基础响应 - 检查该节点系统指标：CPU 使用率突增、网络丢包（
ss -i查 retransmit）、TIME_WAIT 过多、磁盘 I/O 延迟飙升 - 若使用 Kubernetes，确认该 Pod 的 events（
kubectl describe pod）是否有 OOMKilled、CrashLoopBackOff 或 volume mount 失败
