关键在于确保$upstream_http_location变量存在且被赋值，它仅在upstream返回含Location头的3xx响应时有效，需后端显式设置、启用proxy_pass、未禁用proxy_redirect，并在log_format中正确引用。
要通过 log_format 记录 $upstream_http_location 来追踪负载均衡后发生的重定向源（比如 302/301 跳转的原始目标地址），关键在于确保该变量在日志阶段**实际存在且已被赋值**。这个变量只在 upstream 返回响应头中包含 Location 时才有效，且仅适用于被代理请求（即使用 proxy_pass 的场景）。
确认 upstream 响应中确实返回了 Location 头
$upstream_http_location 是 Nginx 自动提取 upstream 服务器响应头中 Location 字段的变量。它不会凭空出现，必须满足：
- 后端服务（如应用服务器）在返回 3xx 状态码时，显式设置了
Location: https://example.com/path响应头； - Nginx 使用了
proxy_pass（而非fastcgi_pass等其他协议）； - 未启用
proxy_redirect off—— 否则 Nginx 可能会改写或丢弃原始Location头，导致该变量为空。
在 log_format 中正确引用该变量
定义日志格式时，直接将 $upstream_http_location 加入即可。注意：它可能为空（例如非重定向响应），建议用短横线 - 占位：
然后在 access_log 中启用该格式：
验证是否生效（常见陷阱）
即使配置正确，也可能记录为空，需排查：
-
后端没发 Location 头：用
curl -v http://your-domain/api确认响应头含Location:； -
响应被 Nginx 重写：检查是否有
proxy_redirect指令（如proxy_redirect http://backend/ /;），它会覆盖原始Location，并使$upstream_http_location不再可用； -
日志发生在 upstream 响应前：确保
access_log在location或 server 块中，且不是在 rewrite 阶段就记录（此时 upstream 尚未响应）； -
变量大小写敏感：必须是
$upstream_http_location（全小写，下划线分隔），不能写成$upstream_http_Location或$upstream_http_location拼错。
增强追踪效果的小技巧
单靠 $upstream_http_location 可能不够，建议组合使用：
- 加上
$upstream_status：确认是否真是 302/301 响应； - 加上
$upstream_addr：知道具体哪个 upstream 节点返回了重定向； - 加上
$request_id（需map或 1.11.0+）：关联前后请求，便于链路追踪； - 对
$upstream_http_location做简单过滤（如用map提取 host 或 path），但注意日志格式中不支持复杂逻辑，需在日志采集后处理。
