ip_hash漂移核心是哈希依据不一致：需确认nginx是否真用真实客户端ip（而非代理ip）哈希，后端是否可靠记录该ip，中间代理是否透传或篡改x-forwarded-for。
排查 ip_hash 模式下后端日志中客户端 IP 漂移，核心是确认：Nginx 是否真按客户端真实 IP 做哈希、后端服务是否正确记录了这个 IP、中间是否有代理或网络层干扰。重点不在“漂移”本身，而在“哈希依据是否一致”。
确认 Nginx 实际哈希依据的 IP
Nginx 的 ip_hash 默认对 $remote_addr 哈希，而该变量值取决于连接来源——若前端有 CDN、LB 或反向代理（如另一层 Nginx），$remote_addr 就是那个代理的 IP，不是用户真实 IP，必然导致哈希失效和 IP 漂移。
- 检查 Nginx 配置中是否启用
real_ip模块相关指令（set_real_ip_from+real_ip_header），确保$remote_addr被正确替换为真实客户端 IP - 在 server 或 upstream 块中临时加日志，验证哈希输入：
log_format debug '$remote_addr - $http_x_forwarded_for - $server_addr:$server_port';
然后用access_log /var/log/nginx/debug.log debug;查看实际参与哈希的是哪个地址 - 注意：
ip_hash不支持 IPv6 地址段哈希（旧版本会跳过），IPv6 客户端可能被当作不同 IP 处理
检查后端日志记录的 IP 来源是否可靠
后端（如 PHP、Java、Node.js）记录的“客户端 IP”往往来自请求头（如 X-Forwarded-For），而非 TCP 连接远端地址。如果 Nginx 没有透传或伪造了该头，后端就会记错。
- 确认 Nginx 中是否设置了
proxy_set_header X-Forwarded-For $remote_addr;（或更安全的$proxy_add_x_forwarded_for） - 检查后端代码是否直接信任
X-Forwarded-For；应只从可信代理链中取第一个非内网 IP，避免被恶意头欺骗 - 对比后端日志中的 IP 和 Nginx access log 中的
$remote_addr（开启 real_ip 后）是否一致；不一致说明透传或解析环节出问题
验证 ip_hash 是否真正生效且稳定
即使配置看似正确，也可能因 upstream 动态变更（如健康检查剔除节点）、Nginx reload 或哈希算法细节导致行为异常。
- 用固定客户端 IP（如 curl -H "X-Forwarded-For: 1.2.3.4" http://your.domain/）多次请求，观察 upstream 日志中目标后端是否始终相同
- 检查 upstream 中是否有服务器被标记为
down或频繁unavailable（可通过upstream_conf或 error log 确认）；ip_hash 在节点不可用时会尝试下一个，造成“漂移假象” - 注意：ip_hash 对 IPv4 地址哈希时只取前 3 段（即 a.b.c.x → a.b.c），但若客户端 NAT 网关出口 IP 不固定（如家庭宽带换拨），仍会落到不同后端
替代方案与快速验证建议
若排查耗时或场景复杂（如混合 IPv4/IPv6、多层代理），可临时改用更可控的负载策略辅助定位：
- 切换为
hash $remote_addr consistent;（需 nginx ≥ 1.7.2），它比 ip_hash 更透明，且支持一致性哈希，便于观察分布 - 在 upstream 中给每台 server 加
weight=1和唯一id，再配合 access_log 记录$upstream_addr，直观看到每次请求打到哪台 - 抓包验证：在 Nginx 机器上
tcpdump -i any port 80 -w nginx.pcap，过滤 SYN 包源 IP，确认入站真实地址是否与日志一致
