ip_hash在企业内网统一出口场景下失效，因所有请求源IP被掩为出口IP导致流量单点过载；应通过real_ip_module还原真实IP，或改用cookie/token等业务标识哈希，并叠加健康检查、失败重试和backup兜底。
企业内网用户通过统一出口（如防火墙、NAT网关）访问服务时，ip_hash 会把所有请求哈希到同一台后端，造成单点过载、其余节点闲置——这不是配置写错了，而是机制本身在该场景下失效。
根本原因：出口 IP 掩盖了真实用户差异
内网成百上千终端经过同一出口设备转发，Nginx 收到的 $remote_addr 全是那个出口 IP（例如 192.168.10.1 或公网地址），ip_hash 对它哈希的结果永远固定，流量 100% 打向某一台 server。
- 后端 CPU、连接数、数据库连接池迅速打满
- 其他服务器负载长期低于 10%，资源严重浪费
- 一旦该节点故障，大量用户直接 502，无自动兜底
立即可用的缓解方案：还原真实内网 IP
如果出口设备支持透传原始 IP（如通过 X-Forwarded-For 或自定义头），可启用 real_ip_module 做可信还原：
- 在
http块中配置可信代理段：set_real_ip_from 192.168.0.0/16;（覆盖常见内网网段） - 指定提取头字段：
real_ip_header X-Forwarded-For;，并开启递归解析：real_ip_recursive on; - 确保后端日志或调试中能打印出
$realip_remote_addr，验证是否已还原为172.16.5.123这类真实终端地址
✅ 成功后，ip_hash 就能基于真实内网 IP 计算，大幅改善倾斜。
更可靠的长期替代：放弃 IP，改用业务标识哈希
当网络层无法提供稳定区分度时，应转向应用层锚点：
-
hash $cookie_JSESSIONID consistent;：Java 应用常用，session ID 天然唯一且生命周期可控 -
hash $arg_token consistent;：适用于带 JWT 或 API token 的接口，token 变更即重路由，符合无状态设计 -
hash $binary_remote_addr consistent=1000;：升级 Nginx 后启用一致性哈希，增减节点时仅影响少量连接，比原生ip_hash更稳
⚠️ 注意：这些方式都要求后端共享 Session（如 Redis 存 session）、或彻底无状态，否则换节点仍会丢上下文。
必须同步补强的容灾能力
哪怕用了更优哈希策略，单点风险依然存在，需叠加三层防护：
-
被动健康检查：每个
server行加上max_fails=3 fail_timeout=30s -
主动失败转移：在
location中启用proxy_next_upstream error timeout http_502;，让失败请求自动重试其他节点 - 兜底 backup 节点：部署一个降级页或轻量中转服务，仅在全部主节点不可用时生效
