精准审计多级上游路由流量最终落点需分场景使用$proxy_host和$upstream_addr：前者适用于动态proxy_pass，记录目标主机名或ip；后者在upstream模块中生效，记录实际通信地址+端口；二者必须同时记录并明确标注上下文，配合x-*-hop头透传与$request_id实现全链路追踪，敏感路径还需条件日志专项审计。
要精准审计多级上游路由中流量的最终落点，关键不是“选一个变量”，而是分场景用对变量：$proxy_host 适用于动态 proxy_pass 场景，$upstream_addr 是 upstream 模块下的事实标准——两者不互斥，但生效前提完全不同。直接混用或误判前提，会导致日志为空、值固定、甚至误导排查。
先分清两个变量的本质区别
• $proxy_host：仅在 proxy_pass 后接变量（如 proxy_pass http://$backend;）时有效，记录的是该变量求值后的主机名或 IP（不含端口），本质是“你让 Nginx 去连谁”；
• $upstream_addr：只要用了 proxy_pass http://my_upstream; 这类 upstream 名称，无论是否启用健康检查、一致性哈希或 keepalive，它都会被自动填充为 实际通信的后端地址+端口（如 10.0.1.5:8080 或 10.0.1.5:8080, 10.0.1.6:8080），是真实连接层面的“它最后连到了哪”。
审计日志必须同时记录二者，并标注上下文
在 log_format 中显式区分用途，避免后续分析混淆：
log_format audit_route '$time_iso8601 | $request_id | $uri | ' '$proxy_host (via dynamic) | $upstream_addr (via upstream) | ' '$upstream_status | $upstream_response_time | $status';
• 若某请求走的是 upstream 分组，则 $proxy_host 通常为空或为 upstream 名（不可信），此时以 $upstream_addr 为准；
• 若某请求走的是 Lua 动态代理或 map + 变量 proxy_pass，则 $upstream_addr 可能为空或为“-”，此时必须依赖 $proxy_host；
• 同时记录可快速识别配置混用问题：比如本该走 upstream 却发现 $upstream_addr 为空而 $proxy_host 有值，说明 proxy_pass 写成了变量形式，绕过了 upstream 的健康检查与负载策略。
针对多级代理链路，补全中间跳转信息
在多级网关（如接入层 → 路由层 → 业务层）中，单靠一跳的 $proxy_host 或 $upstream_addr 不足以还原全路径。需逐层注入并透传标识：
- 在第一级 Nginx 的 proxy_set_header 中添加：
X-First-Hop: $upstream_addr； - 第二级收到后，再加一层：
X-Second-Hop: $upstream_addr； - 最终审计日志里统一记录所有 X-*-Hop 头，或用 map 提取合并为一个字段：
map $http_x_first_hop:$http_x_second_hop:$http_x_third_hop $full_route { ... }； - 配合 $request_id 全链路对齐，就能在日志中按 ID 拉出完整转发轨迹。
用条件日志分离高风险路径的实际落点
对管理接口、支付回调等敏感路径，不应只看是否命中，更要确认是否打到了预期节点。可用 map + if 实现细粒度审计采样：
map $uri $audit_sensitive {
~^/admin/|~^/pay/callback/ 1;
default 0;
}
再定义带条件的日志：
access_log /var/log/nginx/sensitive-route.log audit_route if=$audit_sensitive;
这样，只有敏感路径才会写入专用日志，且每条都含真实 $upstream_addr，便于安全团队定向审查、比对白名单或检测异常漂移。
