会话保持配置指南

会话保持用于让符合条件的后续请求继续访问同一后端节点。它不复制应用的登录状态，也不保证节点故障后用户无需重新登录。先确认业务需要保持什么标识，再选择策略。

在何处生效

关联顺序为：虚拟服务 → 实际命中的分发规则 → HTTP 或 TCP/UDP 策略 → 会话保持策略。修改默认分发规则使用的策略，不会自动改变其他分发规则。

如何选择会话保持类型

类型	需要准备什么	容易误解的地方
源地址段	客户端地址及子网掩码	同一 NAT 出口或同一掩码范围内的请求可能集中到一个节点；不是每个用户一份
Cookie Hash	请求携带指定名称的业务 Cookie	不负责插入 Cookie；首次无 Cookie 的请求不能据此保持
Cookie 插入	指定 Cookie 名称及密钥，由负载均衡设置 Cookie	客户端必须保存并回传 Cookie；仅重复发送无 Cookie 请求不能验证此模式
Cookie Passive	业务侧提供符合本产品格式、可用对应密钥解析的 Cookie	普通业务 Cookie 不能直接当作可解析的后端地址使用
URI	填写要匹配的完整路径，例如 /a/b/zz/	不是从 /users/123/orders 自动提取用户编号
URL 参数 / 请求 Header	填写参数名或头部名	当前按配置名称识别保持键，不能假定不同参数值或头部值对应独立用户会话
SSL Session ID	对端实际具备可用的 SSL 会话标识	不等同于 HTTP Cookie；须结合目标协议与客户端实际握手验证

源地址段按 255.255.255.255 配置时，以单个 IPv4 地址识别；配置更宽的掩码前，应评估请求集中到单节点的影响。解析 XFF 时，还需核对 真实客户端 IP 配置。

配置 Cookie 插入

1. 创建会话保持策略

进入【负载流量管理 → 策略配置 → 会话保持策略】，点击“新增”。

1. 应用类型选“七层”，会话保持类型选“COOKIE”。
2. COOKIE 方法选“Cookie插入”，填写独立于业务 Cookie 的名称，例如 N6_LB_SESSION。
3. 按业务要求设置 HTTPOnly、Secure 和 Cookie 有效期，填写自己的密钥。
4. 保存策略。

图中展示配置位置，密钥已遮盖；开关状态为录制时的示例，实际按业务配置。

字段	作用与核对方法
HTTPOnly	限制页面脚本读取 Cookie，不妨碍浏览器正常随请求发送 Cookie
Secure	开启后浏览器仅通过 HTTPS 发送此 Cookie；不能据此要求明文 HTTP 也携带它
密钥	用于 Cookie 解析；修改前评估已有 Cookie 是否仍可用，不要照抄示例密钥
Cookie 过期	可选 Session Cookie 或明确时长；以界面选项为准，不把业务登录超时与此值混为一谈

2. 在 HTTP 策略中引用

打开目标 HTTP 策略，在“会话保持策略”中选择刚创建的策略。确认虚拟服务实际命中的分发规则使用该 HTTP 策略，保存并执行变更。

Cookie 插入模式的浏览器过期设置，与其他模式的保持表超时时间不是同一参数。页面会随所选模式变化，填写时注意单位，尤其不要把秒和分钟混用。

3. 验证 Cookie 与后端结果

使用独立 Cookie 文件保存和回传，例如在客户端执行以下命令；地址替换成实际业务地址：

curl -D - -c /var/tmp/sticky-cookies.txt http://192.0.2.10/
curl -D - -b /var/tmp/sticky-cookies.txt http://192.0.2.10/

第一次检查响应是否包含预期的 Set-Cookie，第二次检查请求是否回传 Cookie，并通过后端标识或访问日志确认命中同一节点。HTTPS 业务应使用对应域名、可信 CA 和 HTTPS 地址验证。

不要仅凭“连续请求返回 200”判断保持有效；两个节点都能返回 200 时，需要能区分节点的响应或后端日志。

跨虚拟服务共享会话保持

适用范围

“是否共享”用于让同一引擎内、同一协议层、引用同一保持策略和同一服务器池的多个虚拟服务共享保持记录。服务器池里恰好有相同的节点，不等于引用同一个池。

开启该选项不会自动在两台引擎之间同步保持表，也不会同步应用的 Session 数据。四层与七层记录分别处理，不应将 HTTP 和 TCP 视为共用一份表。

配置步骤

1. 创建会话保持策略，按需选择七层 URI 或四层源地址段等类型，开启“是否共享”。
2. 创建对应的 HTTP 或 TCP 策略并引用它。
3. 多个同协议层的虚拟服务引用同一策略、同一服务器池。
4. 执行变更，对各监听地址发送同一保持条件的请求，核对后端标识。

上图单独展示共享开关的位置，录制时开关关闭；需要共享时按上述步骤开启，并核对引用关系。

已验证的组合包括多个 HTTP 虚拟服务共享 URI 保持，以及多个 TCP 虚拟服务共享源地址保持。它们分别验证，不代表两类协议互相共享记录。

HTTP 与 HTTPS 混用时

如果采用 Cookie，还要检查 Cookie 名称、密钥、域名、路径及 Secure 属性。开启 Secure 的 Cookie 不会随普通 HTTP 请求发送。可以让 HTTP 入口只做跳转，再在 HTTPS 上建立业务会话；不要把“是否共享”当成绕过浏览器 Cookie 发送条件的开关。

后端异常与恢复

会话保持依赖后端节点仍可用。配置了有效健康检查后，原节点被判定异常时，应验证新的业务请求是否转到健康节点；恢复后再次检查分配结果。不能承诺恢复的节点会自动接回所有旧会话。

验证阶段	需要记录的内容
正常时	保持条件、Cookie 或请求字段、选中的后端节点
原节点异常时	节点健康状态、新请求的后端节点及业务响应
原节点恢复后	恢复状态、已有保持关系与新会话的分配
引擎主备切换后	新连接是否可用、原保持条件下的实际后端；不要由 VIP 可用推断保持表已同步

应用把登录数据只放在故障节点内存中时，即使负载均衡正确转到其他节点，用户仍可能需要重新登录。应用状态共享需要由业务自身解决。

会话保持表与常见问题

会话保持表可辅助查看记录、服务器池、节点和剩余时间，入口与字段见 会话保持策略手册。Cookie 插入等依靠 Cookie 解析的方式，不要仅凭表中没有记录就认定失败。

现象	检查方向
总是换节点	是否引用正确策略、是否实际携带匹配条件、Cookie 是否被浏览器拒绝
Cookie 没有随请求发送	Secure、域名、路径、过期时间及客户端是否保存 Cookie
多个虚拟服务不共享	协议层、承载引擎、策略对象和服务器池对象是否一致
所有用户都到一个节点	NAT 出口、源地址掩码及实际保持键是否把用户归到同一组
后端故障后仍访问异常	健康检查是否已判定下线、是否存在可用替代节点，以及请求是否为原有连接