Java应用在Nginx集群下会话丢失的本质是后端实例间Session不互通，解决方向只有粘性会话或集中存储；需先确保JSESSIONID正确透传，再依业务选型Redis统一管理（推荐）或Nginx粘性策略。
Java 应用在 Nginx 负载均衡集群下出现会话丢失，本质不是 Nginx “没传 JSESSIONID”，而是多个后端实例之间 Session 数据不互通。解决方向只有两个：要么让请求总落到同一台机器（粘性会话），要么让所有机器读写同一份 Session（集中存储）。实际选型需看业务规模、改造成本和可靠性要求。
确保 JSESSIONID 正确透传到后端
这是前提，否则后续策略全失效：
- 检查 Nginx 配置中是否误写了 proxy_set_header Cookie "" 或 proxy_hide_header Set-Cookie，这两条会直接清空或屏蔽 Cookie；
- 避免滥用 proxy_cookie_path 和 proxy_cookie_domain，除非你明确需要修改路径或域；
- 确认后端应用返回的 Set-Cookie: JSESSIONID=xxx 响应头未被 Nginx 意外截断——可在浏览器开发者工具 Application → Cookies 查看是否成功写入；
- 若用了 context-path（如 Spring Boot 的 server.servlet.context-path=/api），需确保 Tomcat 的 sessionCookiePath 或 Spring 的 server.servlet.session.cookie.path 设为 /，否则 Cookie 可能因路径不匹配而不发送。
方案一：Nginx 粘性会话（轻量、免改代码）
适合中小流量、暂无法改造后端的场景，但有明显局限：
- ip_hash：最简单，按客户端 IP 哈希固定路由。缺点是 NAT 环境下大量用户共用一个 IP，导致负载倾斜；用户换网络（WiFi→4G）时 IP 变更，Session 断开；集群扩缩容会引发大规模会话漂移；
- hash $cookie_JSESSIONID consistent：更精准，基于已有 Cookie 做一致性哈希。首次请求无 Cookie 时走轮询，后续带 JSESSIONID 的请求自动绑定同一节点。要求后端必须生成标准 JSESSIONID 且浏览器正常携带（HttpOnly/Secure 设置合理）；
- 注意：启用任一 hash 方式后，upstream 中不能配置 weight、backup 或 max_fails，否则 Nginx 启动报错。
方案二：Redis 统一管理 Session（推荐生产环境）
彻底解耦会话与服务器绑定，是 Java 生态最成熟可靠的方案：
立即学习“Java免费学习笔记（深入）”；
- Spring Boot 项目只需引入 spring-session-data-redis 依赖，加上 @EnableSpringHttpSession 注解，并配置 Redis 连接地址；
- 所有 Tomcat/Spring Boot 实例连接同一个 Redis（单机、哨兵或 Cluster 均可），Session 自动序列化存取；
- Nginx 可回归使用 轮询 或 least_conn，完全无需粘性配置；
- 关键细节：确保 Cookie 的 Domain 设为一级域名（如 .example.com），Path 为 /，否则跨子服务时 JSESSIONID 不会自动带上。
不建议单独使用的方案
这些方法存在硬伤，仅作了解：
- Tomcat Session 复制：靠组播同步内存 Session，节点增多后网络开销剧增，官方已不推荐用于生产；
- 数据库存 Session：读写延迟高，易成性能瓶颈，且无过期自动清理机制；
- 仅靠 Nginx sticky cookie（如 upstream 中用 sticky）：需第三方模块（nginx-sticky-module），维护成本高，且不如 Redis 方案健壮。
