Nginx实现基于Cookie的会话保持需借助nginx-sticky-module（开源方案）或Nginx Plus（企业方案），通过注入route型Cookie绑定客户端与后端服务器，配置session_sticky指令并设置expires、domain等参数，注意兼容性、安全性及健康检查配合。
要让 Nginx 实现基于 Cookie 的会话保持，核心是让客户端首次访问时被分配一台后端服务器，并通过 Cookie 记录该绑定关系，后续请求携带该 Cookie 就能持续路由到同一台服务器。免费版 Nginx 默认不支持 sticky cookie，需借助第三方模块或升级至 Nginx Plus；但有成熟、稳定且广泛使用的开源方案可落地。
使用 nginx-sticky-module（推荐开源方案）
这是最常用、轻量、无需商业授权的 Cookie 会话保持模块，适用于大多数 Linux 发行版（含统信 UOS）。它在 upstream 块中启用，自动注入 route 类型 Cookie，不依赖后端应用修改。
- 下载模块源码（如
nginx-sticky-module-1.1），确认与你当前 Nginx 版本兼容（例如 Nginx 1.20.x ~ 1.24.x） - 重新编译安装 Nginx：
./configure --add-module=/path/to/nginx-sticky-module-1.1 [其他原有参数]
再执行make && make install - 配置示例：
upstream backend {
session_sticky expires=1h domain=.example.com path=/ httponly secure;
server 192.168.1.10:8080;
server 192.168.1.11:8080;
}
其中 session_sticky 是该模块指令；expires 控制 Cookie 过期时间；domain 和 path 确保跨子域或路径时仍有效；httponly secure 提升安全性。
使用 Nginx Plus 的 sticky cookie（企业级方案）
如果你已采购 Nginx Plus，原生支持更精细的控制，适合对合规性、审计和高可用有严格要求的场景。
- 配置中直接使用
sticky cookie指令，支持自定义 Cookie 名、SameSite、Secure、HttpOnly 等属性 - 可结合
route参数显式指定每台 server 的标识，便于日志追踪和故障排查 - 支持
sticky learn模式：自动从上游响应的 Set-Cookie（如 JSESSIONID）中学习并绑定，适合 Java 应用零改造接入
示例：
upstream backend {
server backend1.example.com route=a;
server backend2.example.com route=b;
sticky cookie srv_id expires=1h domain=.example.com path=/ httponly secure samesite=lax;
}
注意事项与常见问题
基于 Cookie 的会话保持不是“万能胶”，需结合实际架构判断适用性。
- 浏览器禁用或不支持 Cookie 时，该机制失效（此时会退回到轮询）
- Cookie 中的 route 值若为明文（如 a/b），可能暴露后端拓扑；建议配合哈希或随机字符串增强隐蔽性
- 后端某台服务器宕机时，Nginx 默认会将新请求分发给其他节点，但已有 Cookie 的用户仍尝试访问故障节点——需配合健康检查（
max_fails/fail_timeout）自动摘除 - 若前端还有 LVS/HAProxy，需确保它们不覆盖或删除 Nginx 注入的 Cookie（尤其注意
proxy_cookie_path和proxy_cookie_domain配置）
验证是否生效
最直接的方式是观察响应头和浏览器 Cookie 变化：
- 首次访问时，响应头中应出现类似
Set-Cookie: srv_id=a; Path=/; Domain=.example.com; HttpOnly; Secure - 刷新页面后，请求头中应带
Cookie: srv_id=a，且后端日志或返回内容（如自定义 HTTP 头）始终来自同一台机器 - 清空浏览器 Cookie 后重试，应看到 route 值变更，说明重新绑定成功
不复杂但容易忽略。
