Nginx本身不维护后端Session，所谓“粘性连接”仅通过ip_hash或sticky模块（需第三方）将同一客户端请求持续转发至同一台后端服务器，解决的是Session不一致引发的登录掉线、购物车丢失等问题，而非真正的Session共享。
直接说结论：Nginx 本身不维护后端 Session，所谓“粘性连接”只是把同一客户端的请求持续转发到同一台后端服务器，靠的是 ip_hash 或 sticky（需第三方模块）——但它们解决的不是 Session 共享问题，而是避免因 Session 不一致导致的登录掉线、购物车丢失等现象。
ip_hash 是最常用也最容易踩坑的方案
它用客户端 IP 的哈希值决定转发目标，天然支持“同一个 IP 总打到同一台后端”：
- 必须写在
upstream块里，且不能和least_conn、hash $cookie_xxx等混用 - 如果用户走的是 NAT 网关（比如公司出口、运营商级 NAT），大量真实用户共用一个公网 IP，会导致所有请求被压到同一台后端，严重失衡
- IPv6 地址哈希后可能分布不均；移动端 IP 经常变动，也会触发“跳节点”
- 示例配置：
upstream backend { ip_hash; server 192.168.1.10:8080; server 192.168.1.11:8080; }
用 cookie 实现更可靠的 sticky（需 nginx-plus 或 openresty）
开源版 Nginx 官方不支持 sticky 指令，只有商业版 Nginx Plus 或集成 nginx-sticky-module-ng 的定制编译版才支持。如果你用的是标准源码编译安装，这条路基本走不通：
- 常见错误是照着 Nginx Plus 文档写
sticky cookie srv_id expires=1h domain=.example.com path=/;，结果nginx -t直接报错unknown directive "sticky" - 强行编译第三方 sticky 模块风险高：需要匹配 Nginx 版本（如 1.24.x 对应特定 commit）、重编译、且无法保证 TLS/HTTP/2 下的 cookie 注入稳定性
- 替代思路：让后端应用自己种
Set-Cookie: ROUTEID=...; Path=/; HttpOnly，再用hash $cookie_ROUTEID转发 —— 这要求后端配合，且首次请求仍需靠ip_hash或轮询落定
真正要解决 Session 保持，得跳出 Nginx 看后端
Nginx 的角色只是流量分发器，Session 数据必须由后端统一管理，否则任何粘性策略都只是临时补丁：
- Spring Boot 应用优先配
spring-session-data-redis，把 Session 存 Redis，所有实例共享读写 - PHP 项目改
session.save_handler = redis+session.save_path = "tcp://127.0.0.1:6379" - Node.js 可用
connect-redis或express-session配 Redis Store - 如果后端实在没法改（比如老旧 ASP.NET WebForms），那只能接受
ip_hash的局限性，并确保后端服务器之间通过数据库或文件同步 Session 文件（极不推荐）
别在 Nginx 配置里死磕“Session 粘性”，先确认后端有没有共享 Session 的能力。很多线上故障，根源其实是开发没配 Redis Session，运维却花三天调 upstream 参数。
