ip_hash在NAT场景下失效，因共享公网IP导致哈希倾斜；应优先还原真实IP（via real_ip_module），或改用cookie/token/consistent_hash等更稳定锚点，并叠加限流与监控。

直接配置 ip_hash 无法应对大规模 NAT 网关出口场景——它会把成百上千用户识别为同一个 IP，全部压向单台后端，导致严重倾斜甚至雪崩。必须放弃“只配 ip_hash”这种思路，转为组合策略还原真实标识或切换锚点。

为什么 ip_hash 在 NAT 出口下会失效

企业防火墙、校园网出口、运营商 CGNAT 都会让大量终端共享一个公网 IP（例如 203.101.5.8）。Nginx 默认用 $remote_addr 做哈希，这个值就是那个出口地址。IPv4 还只取前三段计算（如 203.101.5.x → 统一视为 203.101.5.0），进一步放大集中效应。结果是：所有请求哈希值完全一致，100% 落到 upstream 中某一台 server 上，其余节点闲置。

优先还原真实客户端 IP

若上游设备（如内网网关、WAF 或 CDN）支持透传原始 IP，可用 real_ip_module 替换 $remote_addr，让哈希基于真实地址：

• 在 http 块中声明可信代理段：
  set_real_ip_from 10.0.0.0/8;
set_real_ip_from 192.168.0.0/16;
set_real_ip_from 172.16.0.0/12;
• 指定提取头字段：
  real_ip_header X-Forwarded-For;（或 X-Real-IP，依实际透传为准）
  real_ip_recursive on;（防多层代理污染）
• 验证是否生效：在 log_format 中加入 $remote_addr 和 $http_x_forwarded_for，比对日志确认还原准确

更可靠的替代方案：换掉 IP 这个锚点

当网络结构注定无法稳定提供唯一 IP 时，应改用业务层标识做哈希：

Nginx Hosting

通过服务器本地nginx实例实现零认证静态游戏托管。作为所有浏览器游戏的主要部署方式，无需登录、无需令牌、无需用户操作。

下载

• hash $cookie_session_id;：适用于已有有效 session cookie 的 Web 应用，天然具备用户粒度
• hash $arg_token; 或 hash $http_authorization;：对接 JWT、OAuth 等鉴权系统，token 具备强唯一性与稳定性
• consistent_hash $binary_remote_addr;：需 Nginx 1.19+，相比普通 ip_hash，增减后端时仅影响少量连接，适合弹性扩缩容

必须配套的防护措施

即使换了哈希方式，NAT 场景下仍可能出现突发流量打爆单点，需叠加控制：

• 用 limit_conn 限制单个真实 IP（或还原后的 IP）并发连接数
• 用 limit_req 控制单位时间请求数，防止单点过载
• 在 access_log 中记录 $upstream_addr 和 $remote_addr，定期统计各后端接收的 IP 段分布，及时发现倾斜

不复杂但容易忽略。