nginx会话保持核心区别在于用户识别依据：ip hash基于客户端ip哈希，简单但受nat/代理影响易导致负载不均和会话丢失；cookie绑定（如sticky cookie或hash $cookie_xxx）基于浏览器cookie，精准可靠，适用于移动、cdn等复杂网络环境。
IP Hash 和 Cookie 绑定是 Nginx 实现会话保持的两种主流方式，核心区别在于“依据什么识别用户”——前者靠客户端 IP，后者靠浏览器 Cookie。选错方案容易导致会话丢失、负载不均或安全风险，实际应用中需结合架构和业务特点判断。
IP Hash：简单但依赖网络环境
启用 ip_hash 后，Nginx 对请求源 IP 做哈希运算，固定映射到某台后端服务器。配置只需一行：
upstream backend {<br> ip_hash;<br> server 192.168.1.10:8080;<br> server 192.168.1.11:8080;<br>}
- 适合内网环境或客户端 IP 稳定的场景（如企业办公网）
- 无需修改响应头、不依赖浏览器支持，兼容性极强
- 典型问题：多用户共用出口 IP（如 NAT、代理、4G/5G 网关）会导致所有请求打到同一台后端，形成单点压力
- 后端宕机时，原属该节点的会话直接失效，且哈希表重排，其他用户也会被重新分配
Cookie 绑定：精准但需前后端配合
主流做法是使用 sticky cookie 指令（需 Nginx Plus 或第三方模块），由 Nginx 主动下发带服务标识的 Cookie：
upstream backend {<br> sticky cookie srv_id expires=1h domain=.example.com path=/;<br> server 192.168.1.10:8080;<br> server 192.168.1.11:8080;<br>}
- 首次请求无 Cookie，Nginx 按轮询选一台后端，并在响应中插入
Set-Cookie: srv_id=tomcat1 - 后续请求携带该 Cookie，Nginx 直接路由到对应服务器，完全绕过 IP 变化影响
- 要求浏览器启用 Cookie，且不能因 Secure/SameSite 设置被拦截（HTTP 站点不可设 Secure；跨域需合理配置 SameSite=Lax）
- 比 IP Hash 更可靠，尤其适用于移动客户端、CDN 回源、多层代理等复杂链路
进阶替代：基于已有会话 Cookie 的 Hash 路由
如果后端已生成标准会话 Cookie（如 Tomcat 的 JSESSIONID、Spring Boot 的 SESSION），可跳过 Nginx 插入新 Cookie，直接利用它做一致性哈希：
upstream backend {<br> hash $cookie_JSESSIONID consistent;<br> server 10.0.1.10:8080;<br> server 10.0.1.11:8080;<br> server 10.0.1.12:8080;<br>}
- 无需额外模块，Nginx 开源版原生支持
-
consistent参数让增减后端节点时，仅少量会话迁移，比ip_hash更平滑 - 前提是后端正确设置 Cookie 的
Path和Domain，确保前端能正常携带 - 首次请求若无该 Cookie，仍按轮询分发，后续才自动粘住——天然支持无状态伸缩
怎么选？看这三点
- 用户入口是否集中？如果是统一出口（学校、公司、运营商 NAT），IP Hash 基本失效，优先选 Cookie 方案
- 能否控制后端 Cookie 行为？能则推荐
hash $cookie_xxx consistent，轻量又稳定 - 是否已有 Nginx Plus 或可编译模块？有则
sticky cookie配置最直观，管理也更清晰
