ip_hash失灵主因是$remote_addr被代理覆盖为内网IP而非真实IP，须通过set_real_ip_from+real_ip_header还原真实IP，并确保X-Forwarded-For全链路透传。
排查 ip_hash 配置下 Proxy 头信息丢失问题，核心是确认客户端真实 IP 是否被正确传递并用于哈希计算。Nginx 的 ip_hash 默认基于 $remote_addr，而该变量在反向代理场景中常为上游负载均衡器（如 HAProxy、CDN 或前置 Nginx）的 IP，而非用户真实 IP —— 这会导致哈希失效、会话漂移。
确认 ip_hash 实际依据的 IP 来源
Nginx 的 ip_hash 严格依赖 $remote_addr 变量，它取自 TCP 连接发起方地址。若你前面有代理层，$remote_addr 就是那个代理的出口 IP，不是用户真实 IP。此时即使配置了 X-Forwarded-For，ip_hash 也不会自动读取它。
- 在 server 或 upstream 块中临时加日志，验证实际参与哈希的 IP：
log_format debug_hash '$remote_addr - $http_x_forwarded_for - $upstream_addr';
再配合access_log /var/log/nginx/debug.log debug_hash; - 检查
upstream块是否启用了ip_hash，且未与其他负载策略（如least_conn）混用
确保真实客户端 IP 被可信地传递和识别
仅靠 X-Forwarded-For 不安全，Nginx 必须明确知道哪些上游 IP 是可信代理，才能从中提取真实 IP 并用于逻辑判断（虽然 ip_hash 本身不支持直接改用 $realip_remote_addr，但可间接影响）。
- 启用
ngx_http_realip_module（通常已编译进常用发行版） - 在 http 或 server 块中配置：
set_real_ip_from 10.0.0.0/8;set_real_ip_from 172.16.0.0/12;set_real_ip_from 192.168.0.0/16;real_ip_header X-Forwarded-For;real_ip_recursive on; - 配置后，
$remote_addr在匹配可信段时会自动替换为X-Forwarded-For最左非私有 IP，从而让ip_hash实际基于真实 IP 计算
检查代理链中是否覆盖或清空了关键头字段
某些中间代理（如旧版 HAProxy、WAF 或云厂商 LB）可能默认清洗 X-Forwarded-For，或错误地重复追加、截断、使用 X-Real-IP 而非标准头，导致 Nginx 提取失败。
- 用
curl -v http://your-domain/或抓包（tcpdump / Wireshark）确认请求到达 Nginx 时，X-Forwarded-For是否存在且格式合理（如203.0.113.45, 198.51.100.12） - 检查前置代理是否配置了
option forwardfor（HAProxy）、proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;（Nginx）等标准转发逻辑 - 避免在多个代理层中重复添加同一头，引发头字段污染
替代方案：用 hash 指令实现更灵活的会话保持
如果无法完全控制上游代理行为，或需要基于其他字段（如 Cookie、URL 参数）做一致性哈希，ip_hash 就不够用。Nginx 1.7.2+ 支持更通用的 hash 指令：
- 示例（按真实客户端 IP 哈希，需配合 realip）：
upstream backend {<br> hash $remote_addr consistent;<br> server 10.0.1.10:8080;<br> server 10.0.1.11:8080;<br>} - 也可哈希
$http_x_forwarded_for（慎用，需确保其不可伪造且格式稳定），或结合map提取首 IP：map $http_x_forwarded_for $client_real_ip {<br> ~^([0-9]+\.[0-9]+\.[0-9]+\.[0-9]+) $1;<br> default $remote_addr;<br>}
再hash $client_real_ip;
