Session不同步源于后端多实例状态未共享，Nginx仅转发请求；解决方式有四种：①ip_hash绑定IP（简单但易漂移）；②cookie哈希（更精准，需后端支持标准会话Cookie）；③Redis集中存储Session（推荐，高可用解耦）；④sticky cookie路由（零改造后端，需第三方模块）。
Session 不同步不是 Nginx 本身的问题，而是后端多实例间状态未共享导致的。Nginx 只负责转发请求，不管理 Session。解决的关键在于：要么让请求“固定”到同一台后端（会话粘性），要么让所有后端读写同一份 Session 数据（集中存储）。选哪种，取决于你能否改后端代码、网络环境是否稳定、以及业务对可用性和一致性的要求。
用 ip_hash 绑定客户端 IP（最简，适合内网固定 IP）
这是 Nginx 原生支持、无需后端改动的方案。它对客户端真实 IPv4 的前 3 段做哈希（如 192.168.1.x 全部视为同一个 IP），确保同一 IP 的请求始终落到同一台后端服务器。
- 配置只需在 upstream 块开头加 ip_hash;，注意不能和 weight、backup 等参数共存，否则启动失败
- 若前端有 CDN、WAF 或代理，$remote_addr 是上一跳地址，需配合 real_ip_module 还原真实 IP：
– 在 http 块中声明可信网段：set_real_ip_from 10.0.0.0/8;
– 在 location 中透传头：proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; - 缺点明显：后端列表变动（如扩容或某台宕机），大量用户会重新哈希“漂移”，原有 Session 丢失；NAT 或移动网络下，多个用户可能被识别为同一 IP，造成负载不均
用 cookie 哈希替代 IP（更精准，抗代理和 IP 变更）
避开 IP 不稳定的问题，直接基于后端已生成的会话 Cookie（如 JSESSIONID、PHPSESSID）做一致性哈希。用户切 WiFi/4G、走家庭宽带 NAT 时，Session 依然能保持。
- 配置示例：hash $cookie_JSESSIONID consistent;（放在 upstream 块内，Nginx 1.7.2+ 原生支持，无需第三方模块）
- 首次请求无该 Cookie 时，走默认轮询；后续携带 Cookie 的请求才被哈希绑定
- 前提是后端必须正确生成并返回标准会话 Cookie，且名称与配置中一致（大小写敏感）
后端统一接入 Redis 存 Session（推荐，解耦高可靠）
彻底放弃“绑定服务器”的思路，让所有后端实例都从同一个 Redis 实例读写 Session。Nginx 回归最简单的轮询或 least_conn，完全不参与会话逻辑。
- PHP：修改 php.ini，设 session.save_handler = redis，并配置 session.save_path = "tcp://redis-host:6379"
- Java（Spring Boot）：引入 spring-session-data-redis 依赖，自动接管 HttpSession
- Node.js：使用 express-session 配合 connect-redis 中间件
- 优势突出：单台后端宕机不影响用户会话；扩容缩容零感知；适合登录态、购物车等强状态场景
用 sticky cookie 插入路由标识（零改造后端）
当无法修改后端代码，又想避免 ip_hash 缺陷时，可用此方案。Nginx 主动下发一个内部 sticky cookie（如 route=abc123），记录该用户应路由到哪台后端，并在后续请求中依据此 cookie 转发。
- 需编译安装第三方 nginx-sticky-module-ng 模块
- 配置示例：sticky cookie srv_id expires=1h domain=.example.com path=/;
- 用户首次请求由 Nginx 分配一台后端，并 Set-Cookie；之后所有带该 cookie 的请求，Nginx 直接按值路由，不依赖 IP 或后端返回的 sessionid
- 适用于遗留系统、黑盒服务或容器化环境中无法侵入应用逻辑的场景
