$upstream_addr 记录请求实际连接的后端真实地址（IP:Port），而非配置中的 upstream 名称；用于精准定位故障节点、揭示流量分布异常、支撑链路追踪，但需 proxy_pass 启用且 Nginx ≥1.7.5 才生效。
$upstream_addr 是 Nginx 日志中一个关键的内置变量，它的核心意义在于：**记录每次请求实际连接并通信的后端服务器真实地址（IP:Port），而非配置中静态定义的 upstream 名称或列表。** 它不反映“应该发给谁”，而是明确告诉你“最终发给了谁”——包括重试路径、真实端口、甚至同一节点被反复尝试的情况。
精准定位故障节点，尤其适用于随机 502/504 场景
当出现偶发性网关错误时，仅看 $status=502 无法判断是哪台后端出问题。而 $upstream_addr 能直接暴露失败请求对应的真实后端：
- 若日志中某条 502 记录为
"10.0.3.15:8080"，且该地址高频出现在失败行首，说明这台机器很可能存在响应超时、进程僵死或网络抖动； - 若显示
"10.0.3.15:8080, 10.0.3.16:8080"，结合 $upstream_status="502,200"，可确认第一次转发失败、第二次成功——问题在第一台，而非负载均衡策略本身； - 若只出现单个地址且 $upstream_response_time 为空（“-”）或极短，大概率是连接被拒绝或上游未监听，而非业务处理慢。
揭示真实流量分布与异常倾斜
它能穿透轮询、加权、IP hash 等调度逻辑，呈现实际请求落点：
- 统计 $upstream_addr 出现频次，可发现某台机器接收请求远超均值——可能是健康检查漏判、长连接未释放，或权重配置被意外覆盖；
- 对比 $upstream_addr 与 $upstream_response_time，能识别“高响应延迟但低错误率”的隐性故障节点（如磁盘 I/O 饱和）；
- 若某地址长期未出现在日志中，说明它已被自动摘除（如被动健康检查触发），即使 upstream 配置里还保留着。
支撑端到端链路追踪与协同排障
单独使用价值有限，但与其他变量组合后形成强分析能力：
- 配合 $request_id（需 Nginx 生成或透传），可在后端日志中反向查到同一请求的完整处理过程；
- 搭配 $upstream_http_x_backend_name（由后端响应头返回），能把 IP:Port 映射到服务名、版本、机房等语义信息，避免靠人工维护 IP 表；
- 与 $upstream_status 和 $upstream_response_time 严格对齐（顺序一致、逗号分隔），可还原每一次重试的耗时与状态，判断是网络层失败还是应用层异常。
必须满足的生效前提
这个变量不是总可用，依赖明确的运行上下文：
- 仅在启用 proxy_pass（或 fastcgi_pass 等代理指令）的 location 中有效；
- 要求 Nginx 版本 ≥ 1.7.5（推荐 1.16+），旧版本可能缺失端口或重试地址；
- 如果请求被缓存命中、被 rewrite 拦截、或因 503/404 等提前终止，$upstream_addr 值为空或为 “-”；
- 若未配置 proxy_next_upstream，一次请求通常只走一个后端，$upstream_addr 就不会体现多地址，重试路径也就无从分析。
