$upstream_addr在proxy_set_header中常为空，因其值在upstream决策完成后才填充，而proxy_set_header求值发生在该阶段之前；可靠方案是结合hash $request_id、upstream server id与map匹配，或改用geo/split_clients预分配并set变量透传。
为什么 $upstream_addr 在 proxy_set_header 里经常为空或不准确
直接在 location 块里写 proxy_set_header X-Backend-Addr $upstream_addr;，大部分情况下收不到真实后端地址——因为 $upstream_addr 是 upstream 模块在完成负载均衡、连接建立后才填充的变量，而 proxy_set_header 的求值发生在 upstream 决策前（即 rewrite 阶段末尾），此时它还是空字符串或默认占位符（如 "-" ）。
真正能稳定取到已选后端地址的时机，是 log_format 或 proxy_pass_request_headers 后的响应阶段，但 header 必须在请求发出前就设置好。所以必须换路径：
- 用
map提前声明一个“动态映射”，把 upstream 名称和具体 server 地址绑定（需配合upstream定义中的显式server条目） - 或改用
$upstream_http_*系列变量（不适用，这是响应头） - 最可靠的是：启用
upstream的ip_hash或hash $request_id，再配合map+upstream中每个server的id参数（Nginx 1.19.5+）
用 map + upstream 的 id 实现可预测的节点标识
Nginx 1.19.5 起支持给 upstream server 加 id，这个 id 可被 $upstream_addr 引用（实际是 $upstream_addr 会包含 id=xxx 字段），但更稳妥的是用 map 把 upstream 名称映射为固定标签，再结合负载策略确保一致性。
示例配置片段：
upstream backend {
hash $request_id consistent;
server 10.0.1.10:8080 id=be-a;
server 10.0.1.11:8080 id=be-b;
server 10.0.1.12:8080 id=be-c;
}
<p>map $upstream_addr $backend_id {
~id=be-a "be-a";
~id=be-b "be-b";
~id=be-c "be-c";
default "unknown";
}</p><p>server {
location / {
proxy_set_header X-Backend-ID $backend_id;
proxy_set_header X-Request-ID $request_id;
proxy_pass <a href="https://www.php.cn/link/65b5b8d1f89bf53a5713bc3afdd83e9e">https://www.php.cn/link/65b5b8d1f89bf53a5713bc3afdd83e9e</a>;
}
}注意点：
-
hash $request_id是关键——保证相同$request_id总打到同一台后端，这样$upstream_addr才稳定可解析 -
map必须放在http块顶层，不能嵌套在server里 - 正则匹配用
~id=...而非完整地址，避免因端口、IPv6 格式差异导致匹配失败 - 若用
least_conn或round_robin，$upstream_addr在每次请求中可能不同，map结果就不可靠
绕过 $upstream_addr：用 $host + 自定义 upstream server 名称做染色
如果无法升级 Nginx 或不想依赖 id，可以反向操作：让每个 upstream server 使用唯一 host 名（DNS 或 /etc/hosts 解析），再通过 $host 或自定义变量传递。
安装并运行 Aperture（Lightning Labs 的 L402 闪电反向代理），用于创建 L402 付费墙、配置付费 API 端点、为其他代理托管付费内容或测试 L402 认证流程。
例如：
upstream backend {
server be-a.internal:8080;
server be-b.internal:8080;
server be-c.internal:8080;
}
<p>map $host $backend_hint {
~^be-a.internal$ "be-a";
~^be-b.internal$ "be-b";
~^be-c.internal$ "be-c";
}</p><h1>但注意：$host 是请求 Host 头，不是 upstream server 名</h1><h1>所以要改用 $proxy_host（proxy_pass 后的 host）或更直接的——加一层 resolver + 变量预设更可行的做法是：用 split_clients 或 geo 预先分配请求到逻辑分组，再用 set 注入变量：
- 用
geo $remote_addr $be_group做 IP 段映射，或split_clients "$request_id" $be_group - 再用
set $backend_id $be_group;（注意set不支持直接引用map输出，需中间变量） - 最终
proxy_set_header X-Backend-ID $backend_id;
这种方式完全脱离 $upstream_addr，可控性高，但失去了“真实转发目标”的语义，适合灰度路由而非精确追踪。
染色后如何验证 header 是否生效且不被后端丢弃
常见错误是后端（尤其是 Java Spring、Node.js Express）默认不透传带下划线的 header，或者 Nginx 自身因安全策略丢弃了非法 header 名。
- 确认 Nginx 允许自定义 header：
underscores_in_headers on;必须开启，否则X-Backend-ID这类带连字符的会被静默过滤 - 检查后端是否接收：
curl -v http://your-domain/api/test查看请求头是否出现在> X-Backend-ID: be-a行 - 若后端是 Kubernetes Ingress，注意某些 controller（如 nginx-ingress）会重写
proxy_set_header，需在 annotation 中显式覆盖 - 日志里查
$upstream_addr和$backend_id是否一致：log_format main '$remote_addr - $upstream_addr [$time_local] "$request" $status $backend_id';
最易忽略的一点：当使用 proxy_redirect 或 sub_filter 时，Nginx 可能会延迟解析 $upstream_addr，导致 log 中正确但 header 中为空——此时必须把 proxy_set_header 放在 proxy_pass 之前，且确保没有其他指令干扰变量生命周期。
