nginx的ip_hash不直接透传哈希结果，但可通过proxy_set_header将$upstream_addr或映射后的语义化标识（如node-a）注入请求头，实现节点信息透传，用于日志追踪、灰度路由等场景。
Nginx 的 ip_hash 本身不直接“透传哈希结果”，它只在内部做路由决策，把同一客户端 IP 固定分发到某台后端 server。但业务网关层有时需要知道“这个请求被 hash 到了哪台节点”，比如用于日志追踪、灰度路由、会话诊断或链路埋点。要实现这种 哈希节点信息的透传，核心思路是：让 Nginx 把选中的 upstream server 地址（或标识）作为 HTTP 头，注入到转发请求中。
以下为实用、可落地的配置方式：
确保 ip_hash 生效是前提
必须确认 ip_hash; 明确写在 upstream 块内，且未混用 weight、backup 或其他 hash 类指令；同时客户端真实 IP 已正确还原（如通过 set_real_ip_from + real_ip_header X-Forwarded-For），否则哈希对象错误，透传结果也无意义。
用 $upstream_addr 记录实际转发目标
Nginx 在完成 upstream 选择后，会自动填充变量 $upstream_addr（格式如 192.168.1.101:8080 或 192.168.1.101:8080, 192.168.1.102:8080，含重试时的多个地址）。这是最直接、无需额外模块的透传方式：
upstream backend_pool {
ip_hash;
server 192.168.1.101:8080;
server 192.168.1.102:8080;
server 192.168.1.103:8080;
}
server {
listen 80;
location / {
proxy_pass http://backend_pool;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
# 关键：将选中的后端地址透传给业务网关
proxy_set_header X-Upstream-Addr $upstream_addr;
# 可选：仅取第一个（主选中节点），避免含重试地址干扰
proxy_set_header X-Upstream-Primary $upstream_addr;
# 注：$upstream_addr 在首次成功转发后才稳定，若需严格单值，建议配合 log_format 验证后再用于业务逻辑
}
}
用自定义变量 + map 实现节点标识化透传
如果业务网关更希望接收语义化标识（如 node-a、node-b）而非原始 IP:Port，可用 map 指令建立映射关系：
# 在 http 块顶层定义
map $upstream_addr $upstream_node_id {
default "unknown";
"192.168.1.101:8080" "node-a";
"192.168.1.102:8080" "node-b";
"192.168.1.103:8080" "node-c";
}
upstream backend_pool {
ip_hash;
server 192.168.1.101:8080;
server 192.168.1.102:8080;
server 192.168.1.103:8080;
}
server {
location / {
proxy_pass http://backend_pool;
proxy_set_header X-Upstream-Node-ID $upstream_node_id;
# 其他 proxy_set_header ...
}
}
验证与调试建议
- 在日志中记录
$upstream_addr，确认每次请求是否稳定（尤其对比同一 IP 多次请求）：log_format main '$remote_addr → $upstream_addr - $request'; - 若业务网关收到的
X-Upstream-Addr为空或为"-"，说明 upstream 未成功选中（如所有后端不可用、健康检查全失败）； - 注意：
$upstream_addr是响应阶段变量，在proxy_set_header中使用是安全的，Nginx 会延迟求值至转发时刻。
不复杂但容易忽略。
