如何配置 upstream 配合 sticky 模块实现基于标准 Cookie 的高级会话保持

实现Nginx基于Cookie的高级会话保持需编译启用nginx-sticky-module-ng模块，严格配置cookie名称、domain、path、expires及secure/httponly属性，协同后端统一设置会话Cookie，并叠加健康检查与故障转移机制。

要让 upstream 真正实现基于标准 Cookie 的高级会话保持，核心不是简单加一行 `sticky`，而是让 Nginx 主动管理、精准识别、安全传递、容错切换——全程围绕 Cookie 生命周期展开。

确保 sticky 模块已正确编译并启用

nginx-sticky-module-ng 是第三方模块，官方版本不内置。必须在编译阶段显式加入：

• 下载适配当前 Nginx 版本（如 1.25+）的 nginx-sticky-module-ng（推荐 Bitbucket 官方源）
• 用 nginx -V 查看原有 configure 参数，全部保留，追加 --add-module=../nginx-sticky-module-ng
• 执行 make（不要 make install），替换 sbin/nginx 前务必备份原二进制文件
• 验证：运行 nginx -V 2>&1 | grep -o sticky，应输出模块路径

upstream 中定义带语义的 Cookie 规则

Cookie 不是随便起个名、设个过期时间就行，它得和业务路径、安全策略、后端识别逻辑对齐：

• cookie 名必须与后端实际使用的会话标识一致：例如 Tomcat 用 JSESSIONID，就写 sticky cookie JSESSIONID ...；WebSocket 场景常用 route 或自定义名如 srv_id
• 作用域要精确控制：domain 写成 .example.com（开头带点）才能被所有子域名读取；path 设为 / 或应用实际部署路径（如 /app）
• 有效期需权衡稳定性与弹性：expires=1h 是常见选择，比浏览器会话周期更可控；太短易断连，太长不利于扩缩容或灰度发布
• 安全属性不可省略：HTTPS 环境下必须加 secure httponly，防止 XSS 窃取、明文传输

协同后端正确生成和响应会话 Cookie

sticky 模块依赖后端返回的原始会话 Cookie（如 JSESSIONID）来建立映射，但很多应用默认返回的 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 健康检查，设 fall=3 rise=2 动态标记 down
• 避免使用 no_fallback —— 它会让故障节点直接返回错误，而非重试其他节点
• 可补充 max_fails=3 fail_timeout=30s，让 Nginx 自动临时屏蔽异常节点（与健康检查配合效果更稳）
• 手动下线节点时，在 server 行末尾加 down，Nginx 会跳过该节点