ip_hash不支持原生cookie联动或降级，所谓“ip_hash结合cookie降级”实为通过hash $cookie_xxx consistent替代ip_hash实现cookie优先路由，首次无cookie时自动轮询，后端返回set-cookie后即绑定，配合真实ip还原与后端会话配置形成双层保障。
ip_hash 本身不支持与 cookie 联动，也没有原生“降级机制”。所谓“ip_hash 结合 cookie 降级”，实际是指在 ip_hash 失效时（如首次请求无 Cookie、IP 变更、NAT 干扰），让 Nginx 自动 fallback 到基于会话 Cookie 的哈希路由，形成双层保障。这不是一个开关式配置，而是通过组合 upstream 策略 + 条件判断 + 后端配合实现的多维会话保持。
用 hash $cookie_xxx consistent 替代 ip_hash（推荐主路径）
这是最直接、最稳定的“Cookie 优先”方案，无需第三方模块，Nginx 1.7.2+ 原生支持：
- 在 upstream 块中移除 ip_hash;，改用 hash $cookie_JSESSIONID consistent;（或你后端实际使用的会话 Cookie 名，如 PHPSESSID、connect.sid）
- 首次请求若无该 Cookie，Nginx 默认走加权轮询（即自动“降级”到无状态分发）；一旦后端返回 Set-Cookie，后续请求立刻被哈希绑定
- consistent 参数启用一致性哈希，后端增减节点时，仅少量用户会重映射，避免 ip_hash 那种全局漂移
真实 IP 还原是 ip_hash 生效的前提（否则全走错）
前端有 CDN、WAF 或代理时，$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;
- 指定真实 IP 来源头：real_ip_header X-Forwarded-For;（或 X-Real-IP，需与上游一致）
- 在 proxy location 中透传：proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
避免 ip_hash 和 weight/backup 冲突（硬性限制）
ip_hash 与加权、备份、临时下线等参数互斥，强行混用会导致 Nginx 启动失败：
- 如果必须保留权重，就放弃 ip_hash，改用 hash $remote_addr consistent;（四层场景）或上面的 cookie 哈希
- server 行不能写 weight=3 或 backup，也不能用 down 标记；临时下线某台，只能注释掉或用 max_fails=1 fail_timeout=10s 触发健康检查剔除
- 内网 NAT 环境（如 192.168.1.x 全部视为同一 IP）下，ip_hash 易导致单台过载，此时 cookie 哈希是更合理的选择
后端配合决定降级是否真正可用
所谓“降级”，本质是首次请求未命中会话时，后端能否快速生成新 Session 并正确返回 Cookie：
- 确保后端应用开启标准会话管理（如 Spring Boot 的 session 自动配置、Tomcat 的 JSESSIONID 默认行为）
- 响应头中必须含 Set-Cookie: JSESSIONID=xxx; Path=/; HttpOnly;，且域名、Path 与前端访问一致，否则浏览器不携带
- 若后端使用 JWT 或无 Cookie 方案，$cookie_JSESSIONID 永远为空，此时应改用 hash $arg_session_id consistent;（从 URL 参数提取）或接入 Redis 统一存 Session
