$proxy_host表示proxy_pass配置的目标主机名（反映意图），$upstream_addr记录实际连接的后端IP:端口（体现执行结果）；前者静态、后者动态，重试时以逗号分隔多地址，需结合X-Request-ID与自定义日志格式实现跨层链路追踪。
在多级负载均衡架构中，$proxy_host 和 $upstream_addr 是 Nginx 日志与调试中两个关键变量，它们分别记录了代理目标主机名和实际转发到的上游地址。要精准审计流量最终落点，必须理解二者差异、采集时机与组合使用逻辑。
明确 $proxy_host 与 $upstream_addr 的本质区别
$proxy_host 是 Nginx 根据 proxy_pass 指令或 resolver 解析后确定的“目标主机名”，不一定是真实 IP；而 $upstream_addr 记录的是实际建立连接的后端地址（含 IP 和端口），支持多个值（如发生重试或使用 upstream 组时会以逗号分隔）。前者反映配置意图，后者体现执行结果。
- 若 proxy_pass 写死为 http://10.1.2.3:8080，则 $proxy_host 为 10.1.2.3，$upstream_addr 也为 10.1.2.3:8080
- 若 proxy_pass 指向 upstream 块且启用了健康检查/动态 DNS，则 $proxy_host 仍为 upstream 名（如 backend），但 $upstream_addr 会显示具体选中的节点（如 10.1.2.10:8080, 10.1.2.11:8080）
- 当发生失败重试时，$upstream_addr 可能包含多个地址，例如 "10.1.2.10:8080, 10.1.2.11:8080"
在 access_log 中结构化记录实际落点
仅靠默认日志无法区分多级跳转路径，需自定义 log_format 显式捕获关键变量，并确保它们在每层 Nginx 实例中都被记录。
aperture: the L402 aware reverse proxy
下载
安装并运行 Aperture（Lightning Labs 的 L402 闪电反向代理），用于创建 L402 付费墙、配置付费 API 端点、为其他代理托管付费内容或测试 L402 认证流程。
- 在最外层入口网关（L7 入口）：记录 $host（原始 Host）、$proxy_host（它转发给哪组 upstream）、$upstream_addr（真正连到哪个后端）
- 在中间层 LB（如区域网关）：同样记录自身 $proxy_host 和 $upstream_addr，同时可添加 $http_x_forwarded_for 或自定义头传递上一级信息
- 推荐日志格式示例：log_format trace '$time_iso8601 | $host | $proxy_host | $upstream_addr | $upstream_http_x_request_id | $status';
结合 X-Request-ID 追踪跨层级完整链路
单靠地址变量无法关联一次请求在多级间的流转。必须配合全局唯一请求 ID（如 X-Request-ID），并在各级 Nginx 中透传与记录。
- 入口层生成 ID：proxy_set_header X-Request-ID $request_id;
- 各级均记录该头：$http_x_request_id 加入 log_format
- 通过 ID 关联各层日志，再比对每层的 $upstream_addr，即可还原从入口 → 区域网关 → 应用集群 → 具体 Pod 的完整路径
识别异常转发行为与定位瓶颈节点
当发现响应延迟高或错误率上升时，可通过分析 $upstream_addr 分布判断是否出现不均衡或故障节点残留。
- 统计某段时间内 $upstream_addr 出现频次，识别长期未被选中或频繁重试的节点
- 对比 $proxy_host（预期目标）与 $upstream_addr（实际连接），发现 DNS 缓存未刷新、upstream 配置遗漏健康检查等配置偏差
- 若 $upstream_addr 出现 unexpected 地址（如本不该出现的测试环境 IP），说明路由规则存在越权或配置污染
