Nginx 实现会话保持需配合 upstream 策略而非 proxy_pass 本身：1. ip_hash 基于客户端 IP 哈希，简单但受 NAT 和节点变更影响；2. 开源版可通过 nginx-sticky-module 或 map+cookie 实现 Cookie 级粘性；3. 推荐后端统一用 Redis 共享 Session，Nginx 保持无状态。
在 Nginx 中通过 proxy_pass 实现集群环境下的会话保持（Session Persistence），核心不是靠 proxy_pass 本身，而是配合 upstream 模块的负载均衡策略与会话粘性机制。Nginx 默认不共享 session，所以需借助客户端标识（如 Cookie 或 IP）将同一用户持续转发到同一后端节点。
使用 ip_hash 实现基于客户端 IP 的会话保持
这是最简单、无需应用层配合的方式，适用于客户端 IP 稳定且分布较均匀的场景（注意：NAT 环境下可能失效）。
配置示例：
upstream backend_cluster {
ip_hash; # 启用基于源 IP 的哈希调度
server 192.168.1.10:8080;
server 192.168.1.11:8080;
server 192.168.1.12:8080;
}
<p>server {
listen 80;
location / {
proxy_pass <a href="https://www.php.cn/link/26a9c7ab6107b61166fbbc7e64756a1f">https://www.php.cn/link/26a9c7ab6107b61166fbbc7e64756a1f</a>;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
}
}- ip_hash 要求至少两个 server 才生效，单台 upstream 会自动忽略该指令
- 当某台后端宕机时，Nginx 会临时移除它，但哈希映射关系会变化，可能导致部分用户会话“漂移”
- 不适用于前后端分离且经多层代理（如 CDN、LB）的场景，因为 $remote_addr 可能是上一跳地址
使用 sticky cookie（需 nginx-plus 或第三方模块）
开源版 Nginx 不原生支持 sticky 指令，但可通过以下方式实现类似效果：
CPA Update - Secure CLI Proxy API Maintenance
下载
安全更新和维护 CLI Proxy API（CPA）部署与配置。用于 CPA 镜像升级、配置变更、认证目录兼容修复、上线验证与回滚。适用于用户提到“CPA 更新/升级/配置改了/容器重建/回滚”等场景。
-
使用 nginx-sticky-module（第三方模块）：编译时加入，支持基于 Cookie 的会话保持，例如：
sticky cookie srv_id expires=1h domain=.example.com path=/; -
使用 nginx-plus（商业版）：原生支持
sticky learn（从响应头学习 session ID）或sticky cookie，更可靠灵活 -
应用层配合 + rewrite + cookie 透传：后端返回带唯一标识的 Set-Cookie（如 JSESSIONID），Nginx 用
proxy_cookie_path和proxy_cookie_domain修正作用域，并用proxy_ignore_client_abort off配合连接保持（非会话保持，仅辅助）
结合后端 Session 共享方案（推荐长期架构）
真正解耦、可扩展的会话保持，应避免强依赖 Nginx 粘性，转而让后端统一管理 session：
- 后端应用接入 Redis / Memcached 存储 session，所有节点读写同一存储
- Nginx 使用默认轮询（
round-robin）或 least_conn，完全无状态 - 配合健康检查（
health_check）自动剔除异常节点，提升可用性 - 若仍需首请求“绑定”，可在应用登录成功后下发含后端标识的 Cookie（如
route=server-a），再由 Nginx 用map指令匹配并分发
用 map + cookie 实现轻量级路由识别（开源 Nginx 可用）
不依赖模块，利用 Nginx 内置的 map 指令解析 Cookie 并动态选择 upstream：
map $cookie_route $backend {
~^server-a$ backend-a;
~^server-b$ backend-b;
default backend-rr; # 默认走轮询
}
<p>upstream backend-a {
server 192.168.1.10:8080;
}
upstream backend-b {
server 192.168.1.11:8080;
}
upstream backend-rr {
server 192.168.1.10:8080;
server 192.168.1.11:8080;
}</p><p>server {
location / {
proxy_pass <a href="https://www.php.cn/link/7c677ff4c58e458338c5f7e74556735d">https://www.php.cn/link/7c677ff4c58e458338c5f7e74556735d</a>;
proxy_set_header Host $host;</p><h1>若后端需要知道原始 route，可透传</h1><pre class="brush:php;toolbar:false;"> proxy_set_header X-Route $cookie_route;
}}
- 需要应用在登录/首次请求时主动设置
routeCookie（如通过 Set-Cookie 响应头） - 适合灰度发布、AB 测试或按用户分组路由等场景，也间接实现会话保持
- 注意 Cookie 名称和值需规范，避免正则误匹配
