# 

一个客服后台的登录态会随机丢失：用户刚填完半张工单，点下一步提示未登录，重新登录后数据还在，就是得重来一遍。这类问题最先怀疑 session 存储、Cookie 域、跨域配置，查两天没结论。

后来在负载均衡控制台看到两件事：会话保持开着，时间填的 3600 秒；均衡方式选的是加权最小连接数。

会话保持和均衡方式有约束关系，配了不等于生效。文档把这条写在中段的表里，配的时候很容易只看到开关。

## 为什么配了会话保持还是不粘？

先看文档对「默认行为」的描述：

> 会话保持可使得来自同一 IP 的请求被转发到同一台后端服务器上。默认情况下，负载均衡会将每个请求分别路由到不同后端服务器上。但是，您可以使用会话保持功能使特定用户的请求被路由到同一台后端服务器上，这样可以使某些需要保持会话的应用程序（如购物车）合理地工作。

默认每个请求独立调度，会话保持把它改成「同一来源固定到一台」。

但它不是无条件的。文档在四层和七层两节里各给了一张表，两张表的最后一行是同一个结论：

> 加权最小连接数：根据服务器负载和权重来综合调度，不支持会话保持

四层不支持，七层也不支持。原因是机制上的：最小连接数要按「当前连接数」实时调度，而会话保持要求「同一来源固定到一台」，两者的目标直接冲突。选了前者，后者就没有落脚点。

我们那次就是这样：以为「会话保持」是一个独立开关，打开就生效；实际上它依附于均衡方式，方式不对，开关等于装饰。

## 四层和七层的机制差在哪？

差在「靠什么认人」。

**四层（TCP/UDP）靠源 IP。** 文档原文：

> 四层协议（TCP/UDP）支持基于源 IP 的会话保持能力，会话保持时间可设为30 - 3600秒中的任意整数值，超过该时间阈值，会话中无新请求则断开会话保持状态

**七层（HTTP/HTTPS）靠 Cookie。** 文档原文：

> 七层协议（HTTP/HTTPS）支持基于 Cookie 插入的会话保持能力（由负载均衡器向客户端植入 Cookie），会话保持时间设置支持30 - 86400秒

两个数字差得很多：四层最多 1 小时，七层最多 24 小时。这个差别跟着机制走——源 IP 会变（切网络、出口变化），Cookie 存在客户端，更稳定。

七层的 Cookie 由负载均衡器植入，后端不用改配置，也不用引入共享 session。

还有个第三种情况，藏在同一张表里：

> IP Hash：根据客户端 IP 和权重来综合调度，支持基于源 IP 的会话保持，不支持基于 Cookie 插入的会话保持

IP Hash 是均衡算法，不是会话保持配置。它按 IP 做哈希，天然把同一 IP 的请求分到同一台，但它的「粘性」来自算法，不来自那个时间参数。所以它只对应「源 IP」这一种语义，拿不到 Cookie 那一套。

把三张表合成一张，选型就看得很清楚了：

| 协议 | 均衡方式 | 支持的会话保持 | 最长时间 |
| --- | --- | --- | --- |
| TCP/UDP | 加权轮询 | 基于源 IP | 3600 秒 |
| TCP/UDP | 加权最小连接数 | 不支持 | — |
| HTTP/HTTPS | 加权轮询 | 基于 Cookie 插入 | 86400 秒 |
| HTTP/HTTPS | 加权最小连接数 | 不支持 | — |
| HTTP/HTTPS | IP Hash | 基于源 IP，不支持 Cookie | 按算法，不受时间参数控制 |

表里最后一行要留意：**IP Hash 看起来「也能保持」，依据的是 IP 不是 Cookie。** 用户在公司网关后面和同事共用一个出口 IP 时，会一直被分到同一台——功能上「粘」了，负载却不均。

## 会话保持和长连接是一回事吗？

不是。这两个概念经常被混着用，但它们在链路上处在不同位置。

长连接说的是 **TCP 连接不关**；会话保持说的是 **请求被分到同一台后端**。前者是一条链路的状态，后者是一个调度决策。文档专门用两个场景解释了这件事。

场景一是七层：

> HTTP keep-alive 是由 Client 端跟 CLB 建立的，若此时没有开启 Cookie 会话保持，则下一次访问，CLB 会根据轮询策略，随机挑选一台后端服务器，此前的长连接等于白费了。

> 当设置 Cookie 会话保持的时间为1000秒时，Client 端再次发起请求。由于距离上一次请求，已经超过了75秒，TCP的连接要重新建立。应用层判断 Cookie，找到同一台后端服务器

合起来说明：**TCP 连接会因 75 秒空闲断开，但 Cookie 还在，请求仍回到同一台机器。** 长连接断了不影响会话保持，反过来也一样。

场景二是四层：

> 当 TCP 启用长连接时，如果该长连接一直没有断开，前后两次访问都是同一条连接，则可以访问到同一台机器。如果第二次访问时，第一条连接由于其他原因（网络重启、连接超时）被释放，这时第二次访问就有可能调度到其他后端服务器上

四层没有 Cookie，连接一断就丢了「同一来源」的记忆，这也是它只给到 1 小时的原因。

三个超时数字放在一起看，才不会配错：

| 参数 | 默认值 | 作用对象 | 能不能调 |
| --- | --- | --- | --- |
| HTTP keepalive_timeout | 75 秒 | 客户端与 CLB 之间的 HTTP 连接 | 需开通个性化配置 |
| TCP 连接超时 | 900 秒 | TCP 监听器的空闲连接 | 可编辑监听器调整 |
| UDP 连接超时 | 300 秒 | UDP 监听器的空闲连接 | 可编辑监听器调整 |

容易配错的地方是：把「会话保持 3600 秒」理解成「连接能保持 3600 秒」。它们不是一回事，实际连接可能 75 秒就被回收，而会话保持还在。

## 粘在一台上的会话，会不会一直压着一台？

会。它牺牲均衡度换粘性，真正的问题不是「要不要开」，而是「这个业务需不需要粘性」。

判断标准很具体：**看会话状态存在哪里。**

| 状态存在哪 | 是否需要会话保持 | 理由 |
| --- | --- | --- |
| 后端进程内存 | 需要 | 换一台就丢，无法共享 |
| 后端本地文件 | 需要 | 同上，且更难迁移 |
| Redis 等共享存储 | 不需要 | 任一台都能读到，粘性没有收益 |
| 客户端 Cookie（签名态） | 不需要 | 状态在客户端，服务端无状态 |

前两种是遗留写法，短期只能靠会话保持兜住；后两种可以完全关掉，让调度回到纯均衡。

我们把登录态从进程内存挪到共享存储，然后关掉会话保持、均衡方式保持最小连接数。这样随时能摘一台，用户不掉线，负载也均匀。

代价是多一次网络往返。工单系统可以接受，每秒几万次的接口就要重算。

## 迁到 HTTPS 之后，为什么掉线更频繁了？

七层会话保持靠 Cookie，而 Cookie 的写入和读取都发生在 HTTP 层。理论上 HTTPS 不影响它，但实际迁移时有三处会出问题，和会话保持本身无关：

第一，**域名变了，Cookie 的域对不上**。从原来的子域迁到另一个子域，Cookie 带不过去，等于每次都是新会话。

第二，**安全属性变了**。加了 Secure 和 SameSite 之后跨站请求不再带 Cookie；有些后台是从别的域嵌进来的，顺手加上 SameSite=Lax，嵌入场景立刻失效。

第三，**回源协议和端口变了**。健康检查和转发规则还是旧的时，会出现「部分请求没到后端」，看起来像掉线。

验证方式很直接：连续请求几次，看 CLB 植入的 Cookie 是否稳定。

```bash
# 连续三次请求，观察 Set-Cookie 是否有变化
for i in 1 2 3; do
  curl -sI https://your.domain.com/ | grep -i 'set-cookie'
  sleep 1
done
```

三次值不同说明每次都被当成新会话；一致说明会话保持生效，问题在应用侧。

## 上线前该核对哪几项？

这类配置的错误特点是「配了但不生效」，核对重点是生效条件而不是开关状态：

| 核对项 | 具体看什么 |
| --- | --- |
| 均衡方式 | 是不是加权最小连接数，它会让会话保持失效 |
| 协议与机制 | 四层看源 IP，七层看 Cookie，两者不能互换 |
| 时间参数 | 四层上限 3600 秒，七层上限 86400 秒，填超了会被截断或拒绝 |
| 连接超时 | 别把会话保持时长当成连接超时时长 |
| IP Hash 场景 | 是否接受「出口 IP 相同的用户被分到同一台」 |
| 状态存放位置 | 后端是否已改为共享存储，能否直接关掉会话保持 |

这套核对流程后来写进了上线检查文档，和健康检查、安全组那几项放在一起，用 AI墨衍 把几次故障复盘归拢成「现象 / 原因 / 怎么确认」三列。具体到每条填什么值还得自己对着文档和拓扑核，同一个开关在不同协议下的语义确实不一样。

顺便问一句：你们的会话保持，是「需要」才开的，还是「以防万一」开的？如果状态已经放在共享存储里，那这个开关除了让流量分配更不均匀，没有别的作用。


一个客服后台的登录态会随机丢失：用户刚填完半张工单，点下一步提示未登录，重新登录后数据还在，就是得重来一遍。这类问题最先怀疑 session 存储、Cookie 域、跨域配置，查两天没结论。

开了会话保持还是不粘，因为均衡方式选的是最小连接数

网络与通信

运维

后端

负载均衡会话保持配置不生效？本文解析加权最小连接数不兼容会话保持的机制，四层TCP靠源IP限时3600秒，七层HTTP靠Cookie可达86400秒。IPHash粘性源于算法非时间参数。揭示长连接与会话保持的本质区别，提供三张配置核对清单，助你避免登录态丢失问题。

负载均衡

代码解释

服务器

路由

Redis

让每一个 Agent，都跑在云上

热销域名限时优惠，新客首年免费！


domain

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

开了会话保持还是不粘，因为均衡方式选的是最小连接数-腾讯云开发者社区-腾讯云

开了会话保持还是不粘，因为均衡方式选的是最小连接数

开了会话保持还是不粘，因为均衡方式选的是最小连接数

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐