排查ip_hash流量倾斜需先确认$remote_addr是否为真实客户端IP，再分析upstream分布及ip_hash配置干扰，最后评估改用cookie/token哈希或least_conn方案的合理性。
排查 ip_hash 引起的流量倾斜，核心是验证“是否多个真实用户被识别为同一个 IP”，以及“哈希结果是否真的集中到了少数后端”。这不是配置语法问题，而是网络结构与 Nginx 行为匹配度的问题。
确认 $remote_addr 是否为真实客户端 IP
这是第一步，也是最关键的判断依据。如果 $remote_addr 是 CDN、WAF、NAT 网关或公司代理的地址，那 ip_hash 必然失效：
- 在
log_format中加入$remote_addr和$http_x_forwarded_for（或$http_x_real_ip），对比日志中这两列是否一致 - 检查上游设备是否透传了原始 IP；若使用了 X-Forwarded-For，注意它可能被多层代理追加，需配合
real_ip_recursive on和real_ip_header X-Forwarded-For正确提取最左/最右可信段 - 用
set_real_ip_from明确声明可信代理网段（如10.0.0.0/8、172.16.0.0/12），否则 real_ip_module 不生效
分析 upstream 流量分布是否严重不均
光看请求量不够，要结合 IP 段和后端节点交叉统计：
- 在 access_log 中添加
$upstream_addr和$remote_addr，按小时导出日志，用脚本统计“每个后端接收了多少个不同 $remote_addr”以及“每个 $remote_addr 贡献了多少请求数” - 重点观察：是否存在某个 $remote_addr（如
203.101.5.8）贡献了上万请求，且 95% 都打到同一台后端（如192.168.2.10:8080） - 对比内网 IP 段（如
172.16.5.0/24）是否整体只落在一台机器上——这说明 NAT 出口未还原，或还原后仍用了粗粒度哈希
检查 ip_hash 自身行为是否被意外干扰
ip_hash 对配置变动极其敏感，微小修改就可能导致全量重散列：
- 确认 upstream 块中没有混用
weight、backup或注释位置引发顺序变化——这些都会让 Nginx 重启时重新计算哈希索引 - 检查是否有 server 被临时标记为
down，导致可用节点数减少，哈希模数改变，大量用户路由突变 - IPv4 地址默认只取前 3 段参与哈希（
192.168.1.x → 192.168.1.0），这意味着整个 C 类网段都映射到同一后端；可通过日志验证是否出现大量192.168.1.*全部命中同一台
验证替代方案是否更合理
如果确认存在大规模 IP 冲突（如企业内网、运营商 NAT、CDN 回源），说明 ip_hash 已不适合当前场景：
- 尝试临时切换为
hash $cookie_session_id consistent;，前提是应用已写入稳定 cookie - 或启用
hash $arg_token consistent;，适用于 JWT/Bearer Token 鉴权接口 - 用
least_conn+ Redis 共享 Session，彻底解耦路由与状态，适合中长期演进
