Nginx实现基于Cookie的会话保持需启用nginx-sticky-module-ng模块，配置sticky指令对齐业务Cookie属性，并协同后端规范设置session Cookie，同时叠加健康检查避免故障僵化。
要在 Nginx 负载均衡中实现基于 Cookie 的会话保持，核心是让同一用户后续请求始终落到同一台后端服务器。官方 Nginx 不内置该能力，必须借助第三方 sticky 模块（如 nginx-sticky-module-ng）或使用内置 hash 指令配合已有业务 Cookie。关键不在于加一行配置，而在于模块启用、Cookie 生命周期控制和前后端协同。
编译并启用 nginx-sticky-module-ng 模块
这是最主流、免后端改造的方案。模块会在首次响应中自动注入路由 Cookie，并在后续请求中识别它完成绑定。
- 下载与当前 Nginx 版本兼容的
nginx-sticky-module-ng（如适配 1.20–1.25 系列），推荐从 Bitbucket 官方源获取 - 用
nginx -V查看原有编译参数，执行./configure --add-module=/path/to/module [原有参数]，再make && make install - 验证是否成功：
nginx -V 2>&1 | grep -o sticky应有输出；重启后检查错误日志无模块加载失败提示
在 upstream 中正确配置 sticky 指令
Cookie 名称、作用域、有效期和安全属性必须与业务实际对齐，否则浏览器不携带或 Nginx 无法识别。
- 写法示例：
sticky cookie srv_id expires=1h domain=.example.com path=/ httponly secure; -
srv_id是模块生成的 Cookie 名，值为内部哈希标识，也可设为JSESSIONID与 Java 应用对齐 -
domain=.example.com（开头带点）才能被所有子域名读取；path=/或设为应用实际路径（如/app） -
expires=1h建议略长于业务会话预期时长；太短易断连，太长影响扩缩容灵活性 -
httponly secure必须加上——前者防 XSS 窃取，后者强制 HTTPS 下传输（非 HTTPS 环境勿加secure）
配合后端统一设置会话 Cookie
sticky 模块依赖后端返回的原始会话 Cookie 来建立映射。若后端未规范设置 domain/path，Nginx 可能无法捕获或更新绑定关系。
- Tomcat 需在
conf/context.xml中补充：<Context sessionCookiePath="/" sessionCookieDomain=".example.com" /> - Spring Boot 推荐配置：
server.servlet.session.cookie.path=/和server.servlet.session.cookie.domain=.example.com - 避免后端返回多个同名 Cookie（如不同 path），建议归一化设置，否则 Nginx 默认只取第一个
搭配健康检查防止故障僵化
sticky 默认“认 Cookie 不认健康”，节点宕机后流量仍持续打过去，导致 502 错误。必须叠加主动探测机制。
- 引入
nginx_upstream_check_module，配置 TCP 或 HTTP 主动健康检查 - 例如：
check interval=3 rise=2 fall=3 timeout=1 type=http，配合check_http_send和check_http_expect_alive - 确保故障节点被及时摘除，同时 sticky 关系在恢复后可重建或由客户端重试触发新分配
