ip_hash失灵的根本原因是$remote_addr被多层代理覆盖为最后一跳内网IP（如10.0.0.5），而非用户真实IP，导致所有请求哈希到同一后端；需通过set_real_ip_from+real_ip_header还原真实IP，并确保X-Forwarded-For全链路透传。
IP Hash 策略在多层反向代理中容易失效，核心原因是客户端真实 IP 会被中间代理覆盖，导致 Nginx 计算哈希时用的不是原始 IP。
为什么多层代理下 ip_hash 常常“失灵”
默认情况下，Nginx 的 ip_hash 只读取 $remote_addr 变量，这个值是直接连接 Nginx 的上一跳地址。如果前面还有 CDN、云负载均衡（如阿里云 SLB、AWS ALB）或另一台 Nginx，$remote_addr 就变成了那个代理的内网 IP（比如 10.0.0.5），而非用户真实 IP。所有来自同一代理的请求都会被哈希到同一台后端服务器，造成严重倾斜甚至单点过载。
必须配合 X-Forwarded-For 正确提取源 IP
要让 ip_hash 在多层代理中生效，关键在于把最外层传来的用户真实 IP 提取出来，并显式用于哈希计算。Nginx 本身不支持直接对 $http_x_forwarded_for 做 ip_hash，但可通过以下方式间接实现：
- 确保上游代理（如 CDN 或前置 Nginx）正确设置
X-Forwarded-For头，格式为X-Forwarded-For: 客户端IP, 代理1IP, 代理2IP - 在当前 Nginx 配置中启用
set_real_ip_from指令，声明可信代理段（例如set_real_ip_from 10.0.0.0/8;），再设置real_ip_header X-Forwarded-For; - 启用后，
$remote_addr将自动替换为真实客户端 IP，此时ip_hash才真正基于用户源地址工作
注意 upstream 中 server 的稳定性
IP Hash 对后端列表变动非常敏感。添加或删除 server 行会改变模运算分母 n，导致大部分哈希结果重分配。在多层架构中，这一问题更隐蔽——比如运维在前置 LB 上扩缩容，后端 Nginx 却不知情，upstream 配置未同步，就会引发会话漂移。
- 故障节点务必用
down标记，而不是直接删掉配置行 - 若需动态扩缩容，建议改用一致性哈希（如
hash $remote_addr consistent;），它能大幅降低 rehash 影响范围 - 避免在多层代理中混合使用 ip_hash 和 least_conn 等动态策略，逻辑冲突易引发不可预期分发
实际配置片段参考
以下是一个适配两级代理（CDN → Nginx → Tomcat）的典型配置：
upstream app_backend {
ip_hash;
server 192.168.2.10:8080;
server 192.168.2.11:8080;
}
<p>server {
listen 80;
set_real_ip_from 10.0.0.0/8; # 信任内网代理段
set_real_ip_from 172.16.0.0/12;
real_ip_header X-Forwarded-For;
real_ip_recursive on;</p><pre class="brush:php;toolbar:false;">location / {
proxy_pass http://app_backend;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}}
这样配置后，ip_hash 才真正作用于终端用户 IP，会话保持才可靠。
