nginx多实例集群实现会话粘滞首选nginx-sticky-module-ng自动管理srv_id cookie，其次可用hash $cookie_jsessionid实现软粘性；需注意domain、secure、samesite等cookie属性配置及浏览器兼容性。
Nginx 在多实例集群中实现会话粘滞，核心是让同一用户后续请求始终落到同一台后端服务器上。当 Session 存在本地内存（如 Tomcat 默认 HttpSession）且未接入 Redis 等共享存储时，靠轮询或 ip_hash 容易丢会话——Cookie 方案更可靠、更贴近用户粒度。
用 nginx-sticky-module-ng 自动管理路由 Cookie（推荐）
这是目前最成熟、免改后端的开源方案，适合大多数生产环境。
- 下载模块源码，确认与当前 Nginx 版本兼容（1.20–1.24 均支持）
- 编译时加入：
./configure --add-module=/path/to/nginx-sticky-module-ng [原有参数]，再make && make install - 配置示例：
upstream backend { sticky cookie srv_id expires=1h domain=.example.com path=/ httponly secure; server 192.168.1.10:8080; server 192.168.1.11:8080; } -
srv_id是模块自动生成的 Cookie 名，值为内部哈希标识；domain和path必须与业务一致，否则浏览器不携带；httponly secure防 XSS、强制 HTTPS 传输
用 hash + $cookie_jsessionid 实现软粘性（免编译）
适用于无法重新编译 Nginx 的场景，依赖后端已生成的标准会话 Cookie。
- 要求后端（如 Tomcat）已正常返回
Set-Cookie: JSESSIONID=xxx，且客户端持续携带 - 配置只需一行：
upstream backend { hash $cookie_jsessionid consistent; server 192.168.1.10:8080; server 192.168.1.11:8080; } -
consistent启用一致性哈希，增减后端节点时尽量减少用户路由变更 - 注意：首次请求无 JSESSIONID 时走轮询，后续才绑定；该方案不如专用 route Cookie 稳定，因 JSESSIONID 可能被后端重置或过期
验证是否生效的实用方法
- 打开浏览器开发者工具，查看响应头是否含
Set-Cookie: srv_id=或JSESSIONID= - 多次刷新页面，检查请求头中的 Cookie 值是否不变
- 对比两台后端日志，确认同一用户 IP 的多次请求只命中一台（可配合
add_header X-Backend $upstream_addr;辅助识别）
关键细节不能漏
- Cookie 的
domain写成.example.com（带点前缀），才能覆盖www.example.com和api.example.com - HTTPS 站点必须加
secure参数，否则浏览器拒绝发送 - 若前端跨域调用，后端
Set-Cookie需声明SameSite=None; Secure，前端请求需带credentials: include - 浏览器禁用 Cookie 时，所有 Cookie 粘滞方案都会退化为轮询，需有兜底提示或引导
不复杂但容易忽略
