nginx ip_hash故障主因是哈希对象错误或后端不稳，需重点验证真实ip是否还原（查$remote_addr是否为内网地址）、ip_hash是否真生效（用固定ip测$upstream_addr一致性）、后端负载是否倾斜（监控$upstream_response_time分位值）。
Linux 下 Nginx 的 ip_hash 故障，多数不是算法本身出问题，而是“哈希对象错了”或“后端扛不住了”。排查重点不在语法对错，而在真实 IP 是否还原、后端是否稳定、日志是否能说话。
确认真实客户端 IP 是否被正确识别
这是最常被忽略的根源。如果 Nginx 收到的 $remote_addr 是 CDN、WAF 或 SLB 的内网地址（比如 10.0.1.5），那成百上千用户会被哈希到同一台后端，造成单点压垮和延时飙升。
- 在
log_format中加入$remote_addr和$http_x_forwarded_for，例如：log_format main '$remote_addr - $http_x_forwarded_for - $upstream_addr - $upstream_response_time'; - 检查日志中
$remote_addr是否为公网 IPv4/IPv6；若大量出现10.x、172.16–31.x、192.168.x，说明未还原真实 IP - 必须配置
set_real_ip_from+real_ip_header X-Forwarded-For，且上游代理需严格按X-Forwarded-For: 客户端IP, 代理1IP, 代理2IP格式追加，不能覆盖
验证 ip_hash 是否真正生效
不能只看配置写了 ip_hash，要从日志里看到它实际在工作。
- 用固定客户端 IP（如手机开热点、某台测试机）连续发 10+ 次请求，观察日志中
$upstream_addr是否始终指向同一后端地址 - 若返回多个不同后端，可能原因包括：
server被标记为down、max_fails触发临时剔除、配置未nginx -s reload生效 - 注意：
ip_hash不兼容backup节点；一旦启用，backup不参与哈希计算，也不会被自动激活
检查后端节点稳定性与负载倾斜
即使 IP 还原正确、哈希稳定，若某台后端性能弱、磁盘慢、连接池耗尽或存在慢查询，ip_hash 会持续把同类用户导过去，放大局部瓶颈。
- 监控各后端的
$upstream_response_time分位值（P95/P99），看是否存在明显离群节点 - 检查后端连接状态：
netstat -ant | grep :端口 | wc -l，确认是否出现TIME_WAIT爆满或Connection refused - 开启失败重试机制：
proxy_next_upstream error timeout http_502 http_503 http_504，但避免在跨机房场景滥用
排查配置逻辑冲突与隐性干扰
ip_hash 本身语法简单，但容易被其他配置悄悄绕过或干扰。
- 检查
upstream块是否混用了互斥指令，例如同时写ip_hash和least_conn，Nginx 会启动失败或静默忽略后者 - 确认
proxy_pass引用的 upstream 名称拼写正确，且该块确实被加载（可用nginx -T | grep -A5 "upstream 名称"查看最终生效配置） - 若启用了
real_ip_module，ip_hash实际基于还原后的 IP 计算——这本是正确行为，但容易误判为“失效”，需结合日志比对确认
