网站单机运行时登录正常，增加一台应用服务器后，刷新页面却偶尔变回游客，购物车和验证码也可能失效。可以先检查登录状态是否只保存在某台服务器的文件或进程内存里。请求切换到另一台服务器时，浏览器虽然仍带着会话 Cookie，新服务器却可能找不到对应数据。
共享 Session 让不同应用实例读取同一份会话数据；粘性会话让同一个客户端尽量持续访问同一台后端。前者处理状态的存放方式，后者调整请求的分配方式。选择方案前，需要确认应用怎样保存登录状态，以及节点切换时业务允许发生什么。
本文适用于使用服务端 Session 的网站或应用，涉及 Nginx、云负载均衡及常见 Web 框架。示例用于说明排查方法，未在读者的生产环境中执行。资料核验日期：2026 年 10 月 16 日。
看清浏览器 Cookie 和服务端 Session 的关系
在常见的服务端会话模式中，浏览器保存会话标识，登录身份和临时业务数据保存在服务端。两台服务器收到相同标识后，如果各自读取独立目录或内存，就可能得到不同结果。
例如，用户在 A 节点完成登录，会话只写入 A 的本地存储；下一次请求被分给 B，B 查询不到该会话，应用便要求重新登录。这是说明故障机制的假设场景，需要用实际日志确认。
PHP 配置文档列出的默认 session.save_handler 是 files；实际部署可能已被框架或运行时配置覆盖。Express 的 express-session 默认 MemoryStore 也不适合生产环境，并且无法扩展到单个进程之外。[1][2]
服务器数量以外，还要检查进程数量。同一台机器上的多个 Worker，如果各自使用进程内存保存会话，同样可能发生状态不一致。
如果应用把登录信息保存在经过签名或加密的客户端令牌中，则应沿令牌验证、密钥与有效期排查。增加 Redis 不会自动修复这一类认证问题。
用一次登录后的连续请求缩小范围
准备一个测试账号，在浏览器开发者工具里观察登录响应和后续请求，同时通过内部日志判断请求落到哪个实例。日志可以记录时间、请求标识、后端节点和“会话是否命中”，不要记录 Cookie 值、会话 ID 或访问令牌。
重点核对以下现象：
- 登录响应是否发出了预期 Cookie，浏览器是否接受。
- 后续请求是否仍携带该 Cookie，有无域名、路径或 HTTPS 变化。
- 请求切换节点时，会话命中状态是否随之变化。
- 登录后是否发生了应用设计中的会话标识轮换，多个实例能否读取轮换后的会话。
- 失败是否集中在重启、发布、缩容或固定超时间隔之后。
“换节点时失败”可以支持本地会话或配置差异这一方向；“始终在同一节点失败”则需要继续检查应用自己的过期与认证逻辑。排查结论应同时包含请求落点和会话读取结果。
共享 Session 适合需要跨节点保持状态的应用
对于原本使用服务端 Session、并且要求滚动发布或节点切换后继续保留登录状态的应用，可以优先评估框架支持的共享会话存储。各节点使用兼容的客户端、序列化方式及会话配置，访问相同的存储空间。
例如，Spring Session 提供使用 Redis 支持 Web 应用 HttpSession 的官方集成示例。这类框架集成会接管会话读写；仅安装 Redis 服务而不修改应用的会话处理器，不会完成迁移。[3]
上线前，应逐项核对共享存储地址、数据库或命名空间、键前缀、访问权限、网络连通性与过期策略。同一应用的节点需要读到相同数据，不同环境则应做好隔离。Cookie 名称和应用所需的签名、加密配置也要保持兼容。
还要确认两个容易被忽略的业务行为。一个是并发请求写入同一会话时，框架和存储驱动怎样处理竞争；另一个是会话存储故障时，应用会报错、要求重新登录，还是进入其他已定义的降级流程。这两项都应按实际驱动验证。
共享会话会增加公共依赖，需要一起设计访问控制、连接超时、容量告警和故障恢复。登录状态是否需要跨存储重启保留，也应由业务决定，再选择相应持久化与可用性方案。
粘性会话可以缓解切换问题，但有节点故障边界
当旧应用暂时难以迁移本地 Session 时，可以评估粘性会话，让同一个用户的请求尽量保持在原后端。它通常适合作为过渡方案，但无法把本地会话复制到其他节点。
以 AWS Application Load Balancer 为例，官方文档说明，粘性目标失效或变为不健康时，负载均衡会选择新的健康目标。新目标若没有原来的本地会话，用户仍可能需要重新登录。[4]
粘性 Cookie 的有效期与应用会话的有效期也需要分别检查。即使路由绑定仍有效，应用自己的 Session 也可能已经过期；反过来，应用会话仍存在，也不代表请求一定继续落在原节点。
Nginx 的 ip_hash 根据客户端 IP 选择后端，在目标不可用等情况下会转向其他节点。[5] 共享出口、移动网络切换，以及前置代理传递的地址都会影响这种方案的实际效果。评估时应先确认 Nginx 看到的客户端地址，不要把 IP 绑定直接等同于某个用户身份。
Cookie 与代理配置也要单独检查
如果多个节点能够读取同一份会话，仍然反复掉登录，可以继续核对 Cookie 的 Domain、Path、Secure、SameSite，以及应用所需的签名密钥是否一致。
Express 官方文档明确提醒，使用安全 Cookie 需要 HTTPS；应用处于代理之后时，还需要正确配置受信任代理，才能按部署方式判断连接安全性。[2] 代理信任范围应限定到实际链路，避免直接信任任意客户端提交的转发头。
排障时不应直接在生产站点上关闭 Secure、扩大 Cookie 域范围或放宽跨站限制。可以在测试环境复现同样的 HTTPS 和代理拓扑，观察浏览器拒收 Cookie 的具体原因，再调整对应设置。
同一应用的实例若使用不同的签名或加密密钥，也应按框架文档统一部署并设计轮换。密钥只核对配置来源和版本，不要把明文写进排障日志。
迁移时保留旧会话的处理方案
从本地文件或进程内存切换到共享存储之前，先备份配置，确认新旧版本是否兼容，并明确现有用户是否需要重新登录。旧存储中的会话不会因为改了连接地址就自动出现在新存储中。
迁移方案可以是安排可控的重新登录窗口，也可以在应用确实支持的情况下设计兼容过渡。具体采用哪一种，应先在测试环境完成演练。未经评估，不要把批量复制会话文件、在线同步目录或共享挂载当作通用迁移步骤。
回滚也需要考虑状态差异。恢复旧配置可能让已经写入新存储的会话无法继续使用，因此验收和回滚计划应同时覆盖配置、应用版本与用户登录状态。
验收必须包含节点切换
在测试环境先完成登录，再让连续请求实际经过至少两个应用节点，确认它们读取到一致的身份和业务状态。随后演练单节点重启、节点摘除、滚动发布与正常注销，并观察会话过期行为。
购物车、验证码和权限变更如果依赖会话，也要分别验证。共享存储不可用时的表现则应与预先设计的故障处理一致。这些是建议的验收场景，不代表本文已经完成相关实测。
需要跨节点连续保留服务端登录状态的应用，可以把共享会话作为主要改造方向；短期保留本地状态的旧应用，可以评估粘性会话并接受相应的切换影响。方案是否满足需求，应以切换节点、重启和发布后的实际登录结果为准。
官方参考资料
[1] PHP：Session 运行时配置
https://www.php.net/manual/en/session.configuration.php
[2] Express：express-session（MemoryStore、Cookie 与代理设置）
https://expressjs.com/en/resources/middleware/session.html
[3] Spring Session：Spring Boot 与 Redis 集成
https://docs.spring.io/spring-session/reference/guides/boot-redis.html
[4] AWS：Application Load Balancer 目标组属性与粘性会话
https://docs.aws.amazon.com/elasticloadbalancing/latest/application/edit-target-group-attributes.html
[5] Nginx：HTTP 负载均衡与 ip_hash
https://nginx.org/en/docs/http/load_balancing.html