会话保持核心是让同一客户端请求固定落到同一后端服务器，常用方式为基于源IP或Cookie：源IP通过哈希取模实现，配置简单兼容性好但受NAT和IP变动影响；Cookie通过插入并解析自定义键值实现，灵活可靠但依赖客户端支持。
负载均衡接入时实现会话保持，核心是让同一客户端的多次请求固定落到同一台后端服务器。常用方式就是基于 Cookie 或源 IP，两者原理不同、适用场景也不同，选对方法才能稳定又省事。
基于源 IP 的会话保持
负载均衡器拿到请求后，提取客户端的源 IP 地址，通过哈希算法（比如 CRC32 或 MD5）算出一个值，再对后端服务器数量取模，结果唯一对应某台服务器。后续来自该 IP 的请求，只要哈希规则不变，就会持续转发到同一台机器。
- 配置简单，Nginx 只需一行 ip_hash; 就能启用
- 不依赖浏览器 Cookie，兼容性好，适合老旧或特殊终端环境
- 缺点也很明显：NAT 环境下多个用户共用一个出口 IP，会被当成同一客户端；手机网络切换基站、Wi-Fi 切 4G 也会导致 IP 变更，引发会话中断
- 适用于内部系统、局域网服务或对一致性要求不高但对兼容性要求高的场景
基于 Cookie 的会话保持
这是 Web 应用更主流的选择。负载均衡器在首次响应中插入一个自定义 Cookie（比如 ROUTEID=server-01），浏览器自动保存并随后续请求携带。负载均衡器解析这个 Cookie 值，直接映射到对应后端节点。
- Nginx 可用 sticky cookie 指令，例如：sticky cookie srv_id expires=1h domain=.example.com path=/;
- HAProxy 用 cookie SERVERID insert indirect nocache，并在后端 server 行加上 cookie server-01
- 支持过期时间、域名和路径控制，灵活性高；不受 IP 变更影响，更适合公网用户
- 前提是客户端必须开启 Cookie 支持，且不能被拦截或清除；若应用本身已有 JSESSIONID，可选择重写模式复用它，避免新增 Cookie
怎么选？关键看你的业务特点
如果用户基本固定在内网、IP 稳定，且不想改任何应用逻辑，源 IP 方式够用；如果是面向公众的网站或 App，用户网络环境复杂，推荐基于 Cookie —— 它更可靠，也更容易配合 Java 应用的 Session 生命周期管理，比如设置 Max-Age 与后端 Session 超时对齐，避免“Cookie 还在，Session 已丢”的尴尬。
