会话保持配置指南

为什么需要会话保持

负载均衡默认将每个请求独立分发，但很多应用场景要求同一个用户的一系列请求必须到达同一台后端服务器。例如：

用户登录后，Session 存储在服务器 A 的内存中。如果下一个请求被分到服务器 B，用户就变成"未登录"了
购物车数据存在某台服务器的本地缓存中，请求跳到另一台就找不到购物车了
WebSocket 长连接建立在服务器 C 上，后续消息必须继续发给 C

会话保持就是让负载均衡"记住"某个用户（或某个会话）已经被分配到了哪台服务器，后续请求继续往那台服务器转发。

在何处生效

会话保持策略绑定在分发规则（包括默认分发规则）使用的七层策略或者四层策略上，只在使用了该策略的分发规则范围内生效。

虚拟服务 → 分发规则（通过*七层策略*或者*四层策略*绑定会话保持策略）
              └── 命中此规则的请求，按会话保持策略路由到固定节点
              └── 会话保持记录：{ "会话标识" → "服务器节点", 剩余时间 }

六种会话保持类型

1. 源地址（最简单）

根据客户端 IP 地址保持会话。同一个 IP 来的所有请求都转发到同一台服务器。

维度	说明
原理	对客户端源 IP 做哈希，绑定到服务器节点
优点	无需后端配合，配置即生效
缺点	同一 NAT/代理后的所有用户共用一个 IP，都会被路由到同一台服务器；客户端切换网络（如 WiFi → 4G）后 IP 变化，会话丢失
适用	内网系统、客户端 IP 固定且唯一的场景

负载均衡在服务器返回的 HTTP 响应中插入一个 Cookie，浏览器后续请求会带上这个 Cookie，负载均衡根据 Cookie 值路由到对应服务器。

维度	说明
原理	首次请求无 Cookie，按负载均衡算法选服务器；响应时插入 Set-Cookie（如 `N6_LB_SESSION=abc123`）；后续请求携带该 Cookie，负载均衡解密后找到之前的服务器
优点	精确到浏览器级别，不受 NAT 影响；Cookie 值由负载均衡生成和管理
缺点	仅适用于 HTTP/HTTPS 协议；首次请求到 Cookie 生效之间可能有一次路由不一致
适用	绝大多数 Web 应用的首选方案

关键配置项：

会话保持策略配置

参数	建议
Cookie 名称	自定义，如 `N6_LB_SESSION`（不要与业务 Cookie 重名）
HTTPOnly	开启，防止 JavaScript 读取 Cookie，提升安全性
Secure	HTTPS 站点建议开启，仅允许 HTTPS 请求携带此 Cookie
密钥	用于加密 Cookie 值中的服务器信息。多台转发引擎或跨虚拟服务共享时必须配置相同密钥
Cookie 过期	浏览器端 Cookie 的有效期。设为 0 表示会话级（浏览器关闭即失效）

不插入新 Cookie，而是利用后端服务器已有的 Cookie 值做哈希，将相同 Cookie 值的请求路由到同一台服务器。

维度	说明
原理	指定一个业务 Cookie 名称（如 `JSESSIONID`），负载均衡对该 Cookie 的值做哈希计算后选择服务器
优点	不修改 HTTP 响应，对业务透明
缺点	需后端服务已返回该 Cookie；哈希分配可能不均匀
适用	后端已使用 `JSESSIONID` 等常见 Session Cookie 的 Java 应用

与 Cookie Insert 类似，但 Cookie 由后端服务器生成，而非负载均衡插入。负载均衡和服务器约定好加密算法和密钥。

维度	说明
原理	服务器在响应中主动设置一个 Cookie（值与 Cookie Insert 格式兼容），负载均衡读取并解析该 Cookie 来路由
优点	Cookie 由业务侧控制，可携带业务自定义信息
缺点	需要后端代码配合，开发成本高
适用	需要业务完全掌控 Cookie 内容的高级场景

5. SSL Session ID

根据 SSL/TLS 握手时协商的 Session ID 做会话保持。仅适用于 HTTPS 或 TCP+TLS 协议。

原理	同一 SSL 会话的后续请求路由到同一台服务器
优点	对应用层完全透明，不依赖 HTTP 头部
缺点	SSL 会话重协商或超时后 Session ID 变化，会话丢失；仅适用于 SSL 卸载场景
适用	非 HTTP 的 TLS 加密协议、需要完全透明的会话保持

根据请求中的 URI 路径、URL 参数值或特定 Header 值来做会话保持。

类型	匹配依据	示例
URI	请求路径	`/users/123/orders` 中的 `123`
URL 参数	URL 中的查询参数	`?user_id=456` 中的 `456`
请求 Header	自定义 HTTP Header	`X-User-Id: 789` 中的 `789`

适用于 RESTful API 场景，URL 或 Header 中本身就携带了用户标识。

如何选择：快速决策表

你的场景	推荐类型	原因
普通 Web 网站、后台管理系统	Cookie 插入	最通用，无需后端改动
Java 应用（已有 JSESSIONID）	Cookie Hash	复用已有 Cookie，不修改响应
内网系统、API 网关	源地址	配置最简单
RESTful API（URL 中含用户标识）	URI / URL 参数 / Header	天然适合
TCP+TLS 服务（非 HTTP）	SSL Session ID	不依赖 HTTP
需要业务完全控制 Cookie	Cookie Passive	后端配合开发

跨虚拟服务共享会话保持

使用场景

同一个业务通常同时提供 HTTP（80 端口）和 HTTPS（443 端口）两个虚拟服务。用户可能在 HTTP 页面上被重定向到 HTTPS 登录页，如果两个虚拟服务各自独立做会话保持，用户可能被分配到不同的后端服务器，导致登录状态丢失。

跨虚拟服务共享会话保持让两个虚拟服务的会话保持记录互通——用户在 HTTP 虚拟服务上被路由到的服务器，在 HTTPS 虚拟服务上也路由到同一台。

配置方法

创建一个会话保持策略
开启 "是否共享" 开关
在 HTTP 虚拟服务和 HTTPS 虚拟服务的分发规则中，绑定同一个会话保持策略

会话保持策略（共享模式，密钥 = "shared-key-123"）
  ├── HTTP 虚拟服务（80 端口） → 默认分发规则绑定此策略
  └── HTTPS 虚拟服务（443 端口） → 默认分发规则绑定此策略

结果：无论用户访问 HTTP 还是 HTTPS，都路由到同一台后端服务器

共享的前提条件

多个虚拟服务必须使用同一台转发引擎（或同一个流量组内的引擎共享会话表）
Cookie 插入模式下，密钥必须相同（否则 Cookie 值中的服务器信息加密结果不一致，无法解析）
各虚拟服务绑定的服务器池中的节点和端口必须一致（否则路由目标可能不存在）

查询会话保持是否命中

配置完会话保持后，如何确认它在正常工作？矩尺平台提供了会话保持表来实时查看。

查看方式

入口：【监控与告警 → 数据统计 → 会话保持表】

会话保持表

表中每条记录表示一个当前活跃的会话保持关系：

字段	含义
会话保持值	会话的标识（源 IP 地址、Cookie 值、URI 等）
类型	会话保持类型（源地址段、COOKIE、URI 等）
虚拟服务	该会话命中的虚拟服务
服务器池	该会话被路由到的服务器池
服务器节点	该会话被路由到的具体服务器节点 IP:端口
剩余保持时间	该会话保持记录还有多少秒过期

验证方法

从客户端发起一次请求（如浏览器访问 http://VIP/index.html）
打开会话保持表，按"类型"过滤（如 COOKIE），按"虚拟服务"过滤到目标虚拟服务
查看是否出现新的会话记录，确认"服务器节点"字段指向预期的后端服务器
再次发起请求，确认"剩余保持时间"被刷新，说明同一会话被持续识别
如果使用了 Cookie 插入模式，用浏览器开发者工具查看响应头中是否有 Set-Cookie: N6_LB_SESSION=...

常见配置场景

会话保持类型：COOKIE
COOKIE 方法：Cookie 插入
COOKIE 名称：N6_LB_SESSION
HTTPOnly：开启
Secure：HTTPS 站点开启，HTTP 站点关闭
超时时间：1800 秒（30 分钟）

场景二：HTTP + HTTPS 双协议共享会话

会话保持类型：COOKIE
COOKIE 方法：Cookie 插入
COOKIE 名称：N6_LB_SESSION
是否共享：开启
密钥：my-shared-key-2024（两个虚拟服务使用相同密钥）
HTTPOnly：开启
Secure：开启

→ HTTP 虚拟服务的默认分发规则绑定此策略
→ HTTPS 虚拟服务的默认分发规则绑定此策略

场景三：内网 API 网关（源地址）

会话保持类型：源地址段
超时时间：3600 秒（60 分钟）

常见问题

Q：会话保持和负载均衡算法冲突吗？

不冲突。会话保持是"已有会话记录时优先按记录路由"，负载均衡算法是"没有会话记录时（新会话）按算法选择服务器"。两者配合工作：新会话用算法分配，已建立的会话用记录路由。

Q：超时时间到了会话会怎样？

会话保持记录过期后自动删除。该客户端的下一个请求被视为"新会话"，重新按负载均衡算法分配服务器。超时时间需大于业务 Session 的超时时间，否则用户 Session 还没过期，负载均衡已经把他分配到别的服务器上去了。

Q：Cookie 插入模式下，负载均衡插入的 Cookie 长什么样？

Cookie 的值是加密后的服务器信息，看起来像一段乱码（如 N6_LB_SESSION=YWJjZGVm...）。这是经过密钥加密的，防止客户端伪造 Cookie 来绕过负载均衡的路由。

Q：转发引擎故障后会话保持会丢失吗？

非共享模式：会话保持记录存储在转发引擎的内存中。该引擎故障后记录丢失，所有会话重新分配。
主备流量组：主备引擎之间数据面 IP 相同（VIP），但会话保持表不会在主备之间同步。切换后会话需要重新建立。
跨虚拟服务共享模式：如果多个虚拟服务跑在同一台引擎上，共享的会话表不丢失。

会话保持策略的完整配置参数参见会话保持策略用户手册。

会话保持配置指南 ​

为什么需要会话保持 ​

在何处生效 ​

六种会话保持类型 ​

1. 源地址（最简单） ​

2. Cookie 插入（Cookie Insert）— 最常用 ​

3. Cookie Hash ​

4. Cookie Passive ​

5. SSL Session ID ​

6. URI / URL 参数 / 请求 Header ​

如何选择：快速决策表 ​

跨虚拟服务共享会话保持 ​

使用场景 ​

配置方法 ​

查询会话保持是否命中 ​

查看方式 ​

验证方法 ​

常见配置场景 ​

场景一：标准 Web 网站（Cookie 插入） ​

场景二：HTTP + HTTPS 双协议共享会话 ​

场景三：内网 API 网关（源地址） ​

常见问题 ​