ip_hash无法通过调参解决流量倾斜，本质是nat或集中出口导致输入ip失真；应查日志确认$upstream_addr分布，检查upstream配置变动、后端数量合理性，并改用consistent哈希、least_conn或cookie粘性等更适配方案。
直接看日志和后端连接分布，别指望调参“修好”ip_hash——它天生不适合解决流量倾斜问题。
查日志确认是不是 NAT 或集中出口导致的假性不均
大量用户共用一个公网 IP（比如企业网关、校园网、运营商 NAT），ip_hash 会把它们全打到同一台后端。这不是算法出错，而是输入数据失真。
- 在 access log 中加 $upstream_addr 字段，确认相同 IP 是否总落在同一台 server 上
- 用命令快速统计高频客户端 IP 和对应后端：
awk '$7 ~ /^\/.*$/ {print $1, $NF}' /var/log/nginx/access.log | sort | uniq -c | sort -nr | head -20 - 重点检查前几位 IP 是否高度重复（如全是 114.240.128.x 或 192.168.1.x）
看 upstream 配置是否触发了哈希重散列
ip_hash 对后端列表变动极其敏感：增删任意一台 server，所有 IP 的映射关系都会刷新。刚下线一台机器没标 down，或临时注释掉某行配置，都可能让原来均匀的流量瞬间涌向剩余节点。
- 检查 nginx.conf 中 upstream 块里有没有被注释但未删除的 server 行
- 确认所有 server 行末尾没多写空格或不可见字符（容易导致解析异常）
- 运行 nginx -t 看配置是否真正生效，避免 reload 失败却误以为已更新
验证后端数量是否加剧了分布偏差
ip_hash 内部是用 CRC32 哈希值对当前存活 server 数取模。如果只有 2 台或 4 台后端，模数小，哈希高位相近的 IP 就容易扎堆；换成 3、5、7 这类质数，分布会略好些，但无法根治。
- 临时扩到 5 台后端（哪怕其中几台是低配或备用），观察流量是否更分散
- 不要用 weight —— ip_hash 不支持权重，写了会导致 nginx 启动失败
- 注意 IPv6 默认只取前 64 位参与哈希，若业务含大量 IPv6 用户，需确认是否因此造成额外倾斜
别硬扛，换更适合的方案
ip_hash 的设计目标是会话保持，不是负载均衡公平性。当发现部分节点持续过载，说明它已经不适合当前场景。
- 改用 hash $remote_addr consistent，启用一致性哈希，节点增减时仅影响局部映射
- 需要更强抗倾斜能力，可组合变量：hash "$remote_addr$http_user_agent" consistent
- 若业务允许短连接无状态，直接切 least_conn，按实时连接数分发最稳
- 登录类接口必须保持会话？那就用 cookie 粘性（sticky cookie 指令），比 ip_hash 更可控
