会话亲和性确保同一用户请求始终路由至同一后端服务器，常用方式包括：1. ip_hash（Nginx原生支持，但不兼容weight）；2. hash $cookie_xxx consistent（基于会话Cookie，适应IP变动）；3. hash $http_x_session_route consistent（基于自定义Header，适合微服务）；4. WebSocket场景必须启用粘性并透传Upgrade头及调大超时。
会话亲和性（Session Affinity），也就是常说的“粘性会话”，核心目标是让同一个用户的多次请求始终落到同一台后端服务器上。这在未使用 Redis、数据库等共享 Session 存储的场景中非常关键——否则用户可能反复登录、购物车清空、表单提交失败。
用 ip_hash 实现最简粘性
这是 Nginx 开源版原生支持、无需额外模块的方式，适合中小流量且客户端 IP 相对稳定的环境。
- 在 upstream 块中添加 ip_hash; 指令，Nginx 会自动对客户端 IPv4 地址前 3 段（或 IPv6 前 64 位）做哈希，映射到固定后端
- 注意：upstream 中不能同时配置 weight 和 ip_hash，否则启动报错；如果需要权重，得改用其他方式
- 若后端服务器临时下线（比如 down 或健康检查失败），Nginx 会自动将该 IP 的请求重新哈希到其余可用节点，但原有会话会中断
按 Cookie 值做 hash（兼容开源版）
当你的应用通过 Cookie（如 JSESSIONID、PHPSESSID）传递会话标识时，可以用变量哈希实现更精准的绑定。
- 写法示例：hash $cookie_jsessionid consistent;（加 consistent 启用一致性哈希，增减后端时影响更小）
- 这个方式不依赖客户端 IP，能更好应对 NAT、移动网络切换等导致 IP 变动的情况
- 前提是后端已正确生成并返回该 Cookie，且 Nginx 能正常读取（默认支持，无需额外设置）
用自定义 Header 做路由（适合微服务场景）
当你的上游服务（比如网关或 Spring Cloud Gateway）已在请求头中注入了唯一路由标识（如 X-Session-Route），可直接基于它做分发。
- 配置：hash $http_x_session_route consistent;
- 优势在于完全由业务控制路由逻辑，与客户端特征解耦，也便于灰度或 A/B 测试
- 需确保该 Header 在整个链路中被透传（Nginx 默认不丢 header，但要检查 proxy_pass 配置里没显式清除）
WebSocket 连接必须开启粘性
WebSocket 是长连接，轮询会导致握手成功后后续帧被分到不同后端，直接断连。
- 必须配合 ip_hash 或 hash $cookie_xxx 使用
- 同时要在 location 块中显式透传协议升级头：proxy_set_header Upgrade $http_upgrade; 和 proxy_set_header Connection "upgrade";
- 建议调大超时：proxy_read_timeout 86400;（1天），避免 Nginx 主动断开长连接
