ip_hash是nginx原生会话保持方案，需在upstream首行配置，依赖真实客户端ip实现路由固定，但易受代理覆盖、nat、节点变动影响，须配合real_ip_module、规避weight、慎用于移动场景。
IP Hash 是 Nginx 原生支持的连接维持方案，核心目标是让同一客户端 IP 的请求始终路由到同一台后端服务器。但它本身不等于“连接不中断”，而是为会话状态提供路由一致性。要真正实现稳定、低漂移、可运维的连接维持，必须围绕 ip_hash 做系统性优化，而非仅加一行配置。
确保真实客户端 IP 可用
前端若有 CDN、WAF、Nginx 代理或多层负载均衡，$remote_addr 默认是上一跳地址，所有请求将被哈希到同一台后端，ip_hash 彻底失效。
- 在 http 块中启用 real_ip_module，并明确声明可信代理网段：
set_real_ip_from 192.168.0.0/16;
set_real_ip_from 10.0.0.0/8;
set_real_ip_from 172.16.0.0/12;
real_ip_header X-Forwarded-For; - 在 proxy_pass 所在 location 中透传原始 IP：
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; - 验证是否生效：在后端打印 $remote_addr 或检查 access log，确认字段为用户真实公网 IP（非内网或代理 IP）
规避 IP 哈希固有缺陷
IPv4 地址仅取前三段参与哈希（如 192.168.1.100 和 192.168.1.254 被视为同一 IP），在 NAT 环境下极易导致单节点过载；后端增删或顺序调整会触发全量重散列，引发大规模会话漂移。
- 避免在测试环境用虚拟机模拟多客户端——若 IP 段完全一致（如 192.168.1.x），ip_hash 实际不生效
- 扩容缩容时，优先使用 down 标记临时下线节点，而非直接删除 server 行，可保留原有哈希映射关系
- 生产环境若存在大量动态 IP 或移动客户端，应主动放弃纯 ip_hash，转向 cookie 粘滞或自定义 header 路由
配套关键参数协同设置
ip_hash 只解决“路由固定”，不解决“连接断开”。WebSocket 或长连接场景下，必须配合底层超时与协议头透传，否则仍会在 60 秒后被 Nginx 主动关闭。
- 强制使用 HTTP/1.1：
proxy_http_version 1.1; - 透传升级头（尤其 WebSocket）：
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection $connection_upgrade; - 延长空闲超时（建议设为 24 小时）：
proxy_read_timeout 86400;
proxy_send_timeout 86400; - 禁用 keepalive 连接复用干扰（可选）：
proxy_http_version 1.1;
proxy_set_header Connection '';
评估是否该换更稳方案
当业务出现以下任一情况时，ip_hash 已不是最优解，而应升级为更鲁棒的连接维持机制：
- 用户经由企业出口 NAT 或运营商 CGNAT 访问，大量真实 IP 被聚合为少数出口 IP
- 频繁扩缩容、滚动发布或节点自动伸缩，upstream 列表无法长期稳定
- 需兼容移动端网络切换（WiFi ⇄ 4G）、CDN 回源、小程序等复杂链路
- 已具备统一鉴权或 Session 外置能力（如 Redis 存储 JSESSIONID），可改用 hash $cookie_JSESSIONID consistent
