会话保持为什么不生效
会话保持异常有两种典型形态：同一用户的请求被分发到不同后端（表现为登录状态丢失、购物车为空），或者个别后端连接堆积（表现为流量严重不均）。排查思路是先确认保持开关与超时设置，再核对客户端是否携带 Cookie、源地址是否被上游改写，最后检查多层代理的干扰。顺序很重要——从最靠近负载均衡的配置往上游推，比一上来就去抓包高效。
基本信息
| 先确认 | 保持开关是否开启、保持超时是否小于业务会话时长 |
|---|---|
| 七层 | 抓包或日志确认请求是否带 Cookie、响应是否下发 Set-Cookie |
| 四层 | 确认客户端源 IP 是否被上游 NAT 或代理改写 |
| 多层链路 | 负载均衡前还有 CDN 或 WAF 时，源 IP 与 Cookie 会在各层变化 |
典型使用场景
- 用户登录后跳回未登录状态，排查七层会话保持的 Cookie 是否生效
- 购物车或表单分步提交丢数据，确认同一会话是否落在一台后端
- 个别后端 CPU 明显偏高，检查四层保持把大量长连接固定到同一台
- 接入 CDN 后发现保持失效，核对源地址是否已被改写
带 Cookie 复现请求
带 Cookie 复现请求
curl -sv -H 'Host: a.example.com' -H 'Cookie: SERVERID=xxx' \
http://<LB地址>/ 2>&1 | grep -i -E 'cookie|x-forwarded'
# 对比多次请求的响应头，确认是否持续落到同一后端常见失效原因
| 现象 | 可能原因 |
|---|---|
| 请求不带 Cookie | 客户端禁用或未保存 Cookie |
| Cookie 存在但转发乱跳 | 保持超时已过期 |
| 四层保持失效 | 源地址被上游 NAT 改写 |
| 接入新代理后失效 | 中间层改变了源 IP 或 Cookie |
在链路里新加代理层之后要重新评估会话保持：每层都可能改变源 IP 与 Cookie。
四层与七层的差异
四层会话保持基于源地址，七层基于 Cookie，机制选错就会出现「配置明明打开了却不生效」。七层保持更精确，因为同一出口地址下的不同用户也能被区分开；四层保持更简单，但在大量用户共用一个出口（企业专线、运营商 NAT）时，会把许多互不相关的用户固定到同一台后端，反而造成严重不均。因此能插入 Cookie 的场景优先用七层保持，四层保持留给无法携带 Cookie 的协议。