Nginx 本身不支持分布式 Session 管理，需结合 ip_hash、cookie sticky 或外置 Redis 等方案实现；推荐将 Session 存储于 Redis 由应用统一读写，Nginx 仅作无状态反向代理。
直接用 Nginx 本身无法实现真正的分布式 Session 管理，它不存储或同步 Session 数据。但可以通过 Nginx 配合外部机制，实现 Session 的一致性与高可用——核心思路是：让请求始终落到同一台后端节点（粘性会话），或把 Session 数据外置（如 Redis），由应用统一读写。
使用 ip_hash 实现会话保持
这是最轻量的“伪分布式”方案，适合无状态改造成本高的老系统。Nginx 根据客户端 IP 哈希，固定分发到某台后端服务器，保证同一用户后续请求命中同一节点。
配置示例：
upstream backend {
ip_hash;
server 192.168.1.10:8080;
server 192.168.1.11:8080;
}
- 优点：零代码改动，部署快
- 缺点：IP 变化（如 NAT、移动网络）会导致 Session 丢失；哈希分布不均可能引发负载倾斜；无法应对单点故障
- 注意：不适用于代理层层转发的场景（真实 IP 被覆盖），需配合
real_ip_header和set_real_ip_from使用可信来源 IP
基于 Cookie 的 sticky session（如 upstream_hash 模块）
比 ip_hash 更可靠的方式是依据用户标识（如 JSESSIONID、自定义 token）做哈希路由。需要编译安装第三方模块 nginx-sticky-module-ng 或使用 OpenResty 的 balancer_by_lua。
示例（sticky 模块）：
upstream backend {
sticky cookie srv_id expires=1h domain=.example.com path=/;
server 192.168.1.10:8080;
server 192.168.1.11:8080;
}
- 客户端首次访问时，Nginx 写入
srv_idCookie，标记所属后端 - 后续请求携带该 Cookie，Nginx 自动转发到对应机器
- 支持失效自动漂移（如后端宕机时重新分配），但原 Session 仍丢失，需搭配外置 Session 存储才真正可靠
将 Session 外置到 Redis（推荐方案）
Nginx 不参与 Session 管理，而是由后端应用（Spring Session、PHP RedisSession、Node.js connect-redis 等）统一读写 Redis。Nginx 仅作无状态反向代理，可自由轮询或加权分发。
- 所有后端节点连接同一个 Redis 实例（或集群），Session 写入即全局可见
- 需在应用层配置序列化方式、过期时间、前缀隔离（避免多环境冲突）
- 建议启用 Redis 持久化 + 主从/哨兵，避免单点故障
- Nginx 无需特殊配置，保持默认
least_conn或round_robin即可
结合 JWT 实现无 Session 架构
彻底规避服务端 Session 管理问题：登录成功后签发 JWT，由前端在 Header 中携带。后端校验签名并解析用户信息，状态完全存在客户端。
- Nginx 可用
auth_request模块做前置鉴权（转发到认证服务验证 JWT） - 敏感操作仍需后端二次校验（如权限、黑名单），JWT 仅承载身份声明
- 注意 Token 过期管理、刷新机制和安全存储（HttpOnly Cookie 更佳）
不复杂但容易忽略：无论选哪种方式，都要考虑 Session 清理、跨域共享、HTTPS 下 Cookie 安全属性（Secure + SameSite），以及灰度发布时的 Session 兼容性。真正可靠的分布式 Session，本质是把状态从进程内移到共享存储或客户端，Nginx 的角色始终是流量调度器，而非状态管理者。
