Nginx反向代理实现基于Cookie的会话保持需依赖第三方sticky模块（如nginx-sticky-module-ng）或Nginx Plus，配置upstream时使用sticky cookie指令指定名称、过期时间及安全属性，并配合proxy_pass自动完成路由与Cookie管理。
在反向代理层（如 Nginx）启用 sticky 模块实现基于 Cookie 的会话保持，核心是让同一客户端后续请求始终被转发到同一后端服务器。Nginx 官方版不自带 sticky 模块，需使用第三方模块（如 nginx-sticky-module-ng），或改用 Nginx Plus（商业版）的原生 sticky 指令。以下以开源方案为主，说明配置要点与常见实践。
确认 Nginx 支持 sticky 模块
官方 Nginx 编译默认不含 sticky 功能。必须提前编译安装支持该功能的版本：
- 下载并编译
nginx-sticky-module-ng源码，将其作为动态模块（--add-dynamic-module=...）或静态模块（--add-module=...）加入 Nginx 构建过程 - 验证是否加载成功：运行
nginx -V 2>&1 | grep -o 'sticky'，有输出即表示模块已集成 - 若无法重新编译（如使用系统包管理器安装的 Nginx），可考虑替代方案：用
ip_hash（仅限 IPv4/6 一致性哈希）、或通过cookie+map+upstream自定义路由逻辑（无需额外模块）
配置 upstream 中启用 sticky cookie
在 http 或 stream 块中定义 upstream，并添加 sticky 指令：
upstream backend {
sticky cookie srv_id expires=1h domain=.example.com path=/ httponly secure;
server 192.168.1.10:8080;
server 192.168.1.11:8080;
server 192.168.1.12:8080;
}
-
srv_id是 Cookie 名称，客户端首次访问时由 Nginx 自动生成并写入响应头；后续请求携带该 Cookie，Nginx 解析后绑定对应后端节点 -
expires=1h控制 Cookie 过期时间，建议设为略长于业务会话预期时长 -
domain和path需与应用部署路径一致，确保浏览器正确发送该 Cookie -
httponly和secure提升安全性（后者要求 HTTPS）
配合 location 使用 proxy_pass 并注意 header 处理
在 server 块中将请求代理至上述 upstream：
server {
listen 443 ssl;
server_name example.com;
<pre class="brush:php;toolbar:false;">location / {
proxy_pass http://backend;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
# 确保后端能识别原始协议与客户端真实 IP
}}
- 无需额外设置 Cookie 转发规则 — sticky 模块自动处理 Cookie 的生成、校验与路由分发
- 若后端应用本身也写入同名 Cookie（如
srv_id），可能造成冲突，建议后端禁用该 Cookie 的写入或改用不同名称 - 注意 SSL 终止场景下，
X-Forwarded-Proto必须设置，否则后端生成的跳转链接可能误用 HTTP
验证与调试方法
部署后可通过以下方式确认 sticky 生效：
- 用 curl 发起多次请求，观察响应头中是否包含
Set-Cookie: srv_id=...，且后续请求携带该 Cookie - 检查各后端服务器访问日志，相同客户端 IP 在短时间内应只命中固定一台（非轮询切换）
- 清除浏览器 Cookie 后重试，确认新会话被分配到不同后端（体现负载均衡初始分配）
- Nginx 错误日志中如出现
sticky: no server found for cookie，说明 Cookie 解析失败或后端列表变动未同步，需检查 upstream 配置一致性
