游戏集群负载均衡会话保持配置，先要回答两个问题：请求按什么规则分配，连续请求需要维持关联多久。若只打开“粘性会话”却不核对这两项，玩家可能在重连、切换网络或节点故障后落到没有会话状态的服务器上。以下按五步配置，适用于使用负载均衡器分发连接的游戏服务；具体选项需以实际产品和协议为准。
第一步：明确调度规则与超时边界
先画出连接路径，记录客户端使用 TCP 长连接、WebSocket，还是由 UDP 承载实时数据，并区分登录、匹配、房间和战斗等服务。会话保持不是调度算法的替代品：轮询或最少连接决定新连接先去哪台节点，保持规则则影响后续请求是否继续到同一节点。
同时列出应用心跳间隔、允许的空闲时间、最长会话时长，以及负载均衡器和防火墙的空闲连接超时。下游超时若短于上游，连接可能被提前清理。没有统一的超时值；可先以应用的空闲判定为依据，将相关超时留出余量，再通过断线重连和长时间空闲测试确认。
第二步：选择会话关联方式
按来源 IP 绑定
适合没有 Cookie 或其他会话标识、且客户端来源地址相对稳定的场景。以 NGINX 的 ip_hash 为例，可让同一来源 IP 的请求倾向于同一上游节点。缺点是运营商网络、校园网或家庭路由器可能让许多玩家共用公网 IP，造成流量集中；移动网络换址也可能改变映射。
按 Cookie 或应用标识关联
HTTP 登录与 WebSocket 握手可考虑 Cookie 持久化；HAProxy 支持基于 Cookie 的服务器持久性配置，具体语法和能力应核对所用版本。若服务主要使用自定义 TCP 或 UDP 协议，可由应用携带会话标识，或采用支持相应协议的负载均衡方案。不要假定 HTTP Cookie 能自动关联任意 UDP 数据包。
第三步：确定会话标识的生命周期
把保持时长与业务状态分开设计。登录令牌有效期、房间存续时间和负载均衡器的粘性记录可能不同：前者用于身份或业务授权，后者只负责选择后端。标识应有明确的创建、更新和失效条件；避免将长期不变的固定标识暴露在客户端，也不要让已结束的房间继续占用旧映射。
对长连接服务，检查空闲连接如何续期：如果心跳没有经过负载均衡器，或者中间设备不把它计作活动流量，仅延长应用会话期限并不能防止连接被中断。
第四步：配置健康检查和故障处理
为后端设置能反映服务可用性的健康检查，并确认检查失败后，负载均衡器会停止向故障节点分配新连接。会话保持通常不能把节点内存中的房间状态自动搬到另一台服务器。若节点退出时仍需保留进度，需要应用支持状态共享、持久化或可恢复的重连流程。
还要明确摘除节点的方式：维护时先停止接收新会话，再等待存量会话结束；突发故障则按产品能力摘除并引导客户端重连。测试时分别模拟健康检查失败、进程退出和网络中断，不要只验证正常请求。
第五步：分阶段上线并验证
- 记录基线：统计各节点的新连接数、活跃会话数、重连率和错误码，确认观测口径一致。
- 小范围启用：先对测试环境或一小部分流量应用保持规则，检查同一会话是否稳定落到预期节点。
- 验证边界情况：覆盖空闲超时、客户端换网、节点摘除、扩缩容和会话结束，观察是否出现断连或流量偏斜。
- 保留回退方案：记录修改前的调度和超时配置；出现节点负载不均或重连异常时，先回退保持策略，再定位标识、健康检查与状态存储。
上线判断不只看“是否黏住”，还要看节点分布是否可接受、故障后是否能恢复、超时是否符合玩家流程。完成这五步，游戏集群负载均衡会话保持配置才有清晰的验证和回退依据。
常见问题
会话保持开启后，是否还需要应用层状态管理？
需要。保持规则只影响请求路由，不会复制节点内存里的房间、战斗或登录状态。
来源 IP 绑定适合所有游戏吗？
不适合。共享公网 IP 可能造成节点流量集中，客户端换网也可能改变映射；应结合协议和玩家网络环境选择。
超时时间设得越长越好吗？
不是。过长可能留下无效映射或连接占用，过短则可能提前断开有效会话，应按心跳、业务空闲规则和中间设备限制共同验证。