nginx upstream中ip_hash与hash $cookie_jsessionid互斥，不能混用；因路由决策仅允许一种算法，ip_hash优先级高且独占生效，后者会被忽略或导致启动报错。
ip_hash 和 Cookie 维持会话一致不是“结合使用”的关系，而是两种互斥的会话保持策略。Nginx 的 upstream 块中，不能同时启用 ip_hash 和基于 Cookie 的 hash 路由（比如 hash $cookie_JSESSIONID），因为它们作用机制冲突：一个按 IP 分发，一个按 Cookie 值分发，Nginx 只会执行其中一种逻辑。
为什么不能混用？
upstream 模块在一次请求路由决策中只应用一种负载均衡算法。如果你写了：
upstream backend {
ip_hash;
hash $cookie_JSESSIONID consistent;
server 10.0.1.10:8080;
server 10.0.1.11:8080;
}
Nginx 启动会直接报错或静默忽略后者——ip_hash 优先级高且独占生效，后续的 hash 指令无效。
实际场景中该怎么选？
选择依据是你的网络环境和会话标识来源：
- 用 ip_hash：客户端 IP 稳定、无 NAT/代理干扰（如内网办公系统），且后端未生成标准会话 Cookie；配置最简，一行搞定，但不抗 IP 变化
-
用 Cookie hash：公网用户多、存在移动网络切换、CDN 或企业代理（IP 不可靠），且后端已返回 JSESSIONID/PHPSESSID 等 Cookie；只需写
hash $cookie_JSESSIONID consistent;，无需额外模块，精准度更高
如果后端没 Cookie，又想用 Cookie 方式怎么办？
这时需引入外部能力，而非“结合 ip_hash”：
- 升级到 Nginx Plus，用
sticky cookie srv_id expires=1h;主动下发路由标识 - 编译安装开源 sticky 模块（如 nginx-sticky-module-ng），实现类似效果
- 让后端服务统一接入 Redis 存 Session，彻底摆脱粘性依赖——这是更现代、更可靠的解耦方案
一个小提醒：别被“跨域 Cookie 丢失”误导
有人误以为开启 ip_hash 就能解决跨域请求中 Cookie 无效的问题。其实不然：
ip_hash 只管请求分发，它不能修复浏览器因 SameSite、Secure 或 Access-Control-Allow-Credentials 配置不当导致的 Cookie 不携带问题。这类问题必须从前端 credentials 设置、后端响应头、Nginx proxy_cookie_path 三方面协同处理。
