ip hash 有明确适用边界，仅适用于本地内存缓存、websocket 绑定或 ip 粒度灰度等场景；需确保真实客户端 ip（配合 real_ip 模块），避开 nat/动态 ip，并慎用于弹性扩缩容环境。
IP Hash 在复杂网络环境中容易失效甚至引发严重倾斜，它不是通用会话保持方案，而是有明确适用边界的策略。用对了能简化架构，用错了反而放大故障面。
先确认你是否真需要 ip_hash
如果后端已用 Redis 共享 Session、或采用 JWT 无状态认证，ip_hash 完全没必要——关掉它，改用轮询或 least_conn 更健壮。只有当应用强依赖本地内存缓存、WebSocket 必须绑定固定节点、或灰度发布需 IP 粒度路由时，才考虑启用。
真实客户端 IP 是前提，否则全盘失效
前端若经过 CDN、WAF、SLB 或多层 Nginx 代理，$remote_addr 默认是上一跳内网地址。必须配合 real_ip 模块还原：
- 在 http 或 server 块中配置 set_real_ip_from 指定可信代理网段（如 10.0.0.0/8、172.16.0.0/12）
- 设置 real_ip_header X-Forwarded-For 或 X-Real-IP（依上游透传头而定）
- 用 log_format 记录 $remote_addr 和 $http_x_forwarded_for，验证还原是否准确
避开 NAT 和动态 IP 高发场景
运营商级 NAT、校园网、4G/5G 切换会导致大量用户共用同一出口 IP，ip_hash 会把流量集中打到单台后端，造成雪崩：
- 公网服务慎用 ip_hash；如必须用，优先改用 hash $remote_addr consistent
- 私有云或办公网环境更合适——IP 稳定、可追溯、NAT 层级少
- 移动端或家庭宽带用户频繁换 IP，应改用 cookie-based sticky（如 Nginx Plus 的 sticky cookie）或请求头路由（如 map + X-User-ID）
节点变更会引发批量会话漂移
upstream 中增减服务器会改变哈希环结构，导致约 70% 用户被重新分配，登录态、内存缓存全部丢失：
- 禁止在弹性扩缩容频繁的云环境直接用 ip_hash
- 扩容时改用一致性哈希：hash $remote_addr consistent，节点变动影响范围大幅缩小
- 临时维护可用 down 标记节点，ip_hash 自动跳过，无需 reload 配置
