ip_hash本身不提供安全通道或算力平衡，仅实现ip级会话粘滞；其可靠生效依赖真实客户端ip还原、正确配置于upstream块内，并需规避代理覆盖、节点变动及ipv4哈希范围过小等问题。
ip_hash 本身不提供“安全通道”能力，也不支持算力平衡分配。它只是把同一客户端 IP 的请求固定打到某台后端，天然忽略 weight、backup 等参数，因此无法兼顾节点性能差异。所谓“安全通道下的会话粘滞”，重点不在 ip_hash，而在如何让 ip_hash 在真实生产环境中可靠生效——尤其是当流量经过 HTTPS、CDN、反向代理或 NAT 设备时。
确保真实客户端 IP 可被正确识别
ip_hash 依赖 $remote_addr 做哈希，但 HTTPS 入口常经由 TLS 终结设备（如云 WAF、ALB、CDN），此时 $remote_addr 是中间设备地址。必须还原真实 IP，否则所有用户会被哈希成同一个节点。
- 在 http 或 stream 块中配置 real_ip 模块：用 set_real_ip_from 声明可信代理网段（如 CDN 回源段、公司出口段）
- 用 real_ip_header X-Forwarded-For 或 X-Real-IP 提取原始 IP（注意 X-Forwarded-For 可能被伪造，建议配合 X-Forwarded-For 的最左非私有 IP 提取逻辑）
- 验证是否生效：临时加 log_format 输出 $remote_addr 和 $http_x_forwarded_for，对比日志确认真实 IP 已进入哈希计算
ip_hash 不等于算力平衡，需用替代方案补足
ip_hash 固定映射、不支持权重，强弱服务器混部时必然负载不均。若业务要求“既粘滞又按能力分发”，应放弃 ip_hash，改用更可控的机制：
- hash $remote_addr consistent：保留 IP 粘滞特性，同时支持 weight、max_fails、健康检查；扩容缩容时仅约 25% 请求重路由，远优于 ip_hash 的 75%
- sticky cookie srv_id：基于加密 Cookie 实现服务端生成的会话绑定，天然兼容 weight，且首次请求可按权重随机选择，后续复用 cookie；故障时支持 fallback 到其他可用节点
- 若必须用 IP 级绑定且存在大量 NAT 用户（如企业内网），可结合 map 指令提取业务标识（如 JWT 中的 user_id、Header 中的 X-User-ID），再 hash 该字段，比纯 IP 更稳定、更均衡
避免常见失效场景
即使配置正确，以下情况仍会导致会话粘滞“看起来失效”：
- 后端某 server 被标记为 down 或触发 max_fails，Nginx 会剔除它并重新哈希剩余节点——原有 IP 映射关系仍在，但目标变了；建议搭配 slow_start 和合理 fail_timeout 避免抖动误判
- IPv6 地址参与哈希时使用完整地址，而 IPv4 默认只取前三个八位组（192.168.1.x → 视为 192.168.1），可能导致 /24 内用户全打到一台机器；如需 IPv4 全量哈希，需升级 Nginx 并启用 ip_hash_ipv6 on（部分版本支持）
- HTTPS 下未透传 Host 头或未设置 proxy_set_header X-Forwarded-Proto https，虽不影响 ip_hash 本身，但可能造成后端鉴权/跳转异常，间接破坏会话体验
小结：安全 + 粘滞 + 平衡 ≠ ip_hash 单挑
ip_hash 是入门级方案，适合内网直连、IP 稳定、无扩缩容压力的简单场景。在 HTTPS、多层代理、混合算力集群等真实环境下，“安全通道”靠 TLS 终结与头信息透传保障，“会话粘滞”靠 consistent hash 或 sticky cookie 实现，“算力平衡”靠 weight + 健康检查落地——三者需协同设计，而非寄望于 ip_hash 一揽子解决。
