ip_hash不支持weight、backup等参数，必须规避nat导致的ip集中、确保真实ip还原、合理设置节点数（3–5台非2的幂次）、配合健康检查与一致性哈希应对扩缩容漂移。
ip_hash 本身不支持后端服务器规格差异化配置，比如加 weight、backup 或 max_fails —— 这些参数和 ip_hash 是互斥的。所谓“优化规格配置”，本质不是给 server 行加权重，而是通过架构设计让 ip_hash 在真实环境中更稳、更均衡、更可控。
后端节点数量与分布要合理
ip_hash 哈希结果取决于客户端 IP 和后端列表顺序，节点太少或分布不均会放大负载倾斜：
- 至少配置 2 台后端（单节点会导致 Nginx 启动失败或静默失效）
- 推荐 3–5 台，避免节点数为 2 的幂次（如 2、4、8），因 Nginx 内部哈希取模运算易导致部分 IP 段集中映射
- 各节点应部署在相同网络环境（如同一可用区、同网段），减少跨机房延迟干扰
规避 NAT 和 IPv4 地址截断带来的过载
IPv4 默认只取前 3 段做哈希（192.168.1.x 全视为同一 IP），内网或运营商 NAT 下极易把几十上百用户压到一台机器：
- 若大量用户来自同一出口（如企业宽带、校园网、4G/5G 共享 IP），不建议单独依赖 ip_hash
- 可改用 hash $cookie_session consistent，用 Set-Cookie 绑定会话，绕过 IP 局限
- 或前端配合 CDN 设置
Cookie+ 后端统一存 Session 到 Redis，彻底解耦粘滞逻辑
健康与扩缩容必须配套机制
ip_hash 不感知后端健康状态，也不支持平滑扩缩容：
- 某台 server 宕机时，对应 IP 段请求仍持续打过去，直到超时才失败；需搭配 health_check（Nginx Plus）或自建探活 + 配置热重载
- 增减节点会引发全量哈希偏移，用户连接“漂移”；上线前建议灰度切流，或使用一致性哈希替代（如
hash $remote_addr consistent） - 生产环境建议启用
max_fails=1 fail_timeout=10s等基础被动健康检查（虽不能规避首次转发失败，但能加速故障剔除）
真实 IP 必须准确还原，否则全盘失效
如果前面有 CDN、WAF 或多层代理，$remote_addr 就是上一跳地址，所有请求哈希值一样，等于把流量全打到一台后端：
- 启用
real_ip_module，在 http 块中声明可信网段：set_real_ip_from 10.0.0.0/8;、set_real_ip_from 192.168.0.0/16; - 指定原始 IP 头：
real_ip_header X-Forwarded-For;（注意：XFF 可伪造，仅适用于可信代理链） - 在 location 中透传：
proxy_set_header X-Real-IP $remote_addr;、proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
