凌晨两点将旧机房切到新机房，监控先出现一片401：部分用户仍拿着旧会话标识，登录态在入口被判无效；另一些请求落到没有粘性的节点，购物车又换了实例。棘手的不是服务器能否访问，而是切换后同一用户能否被稳定识别、回到原会话，并保留可逆通道。
如果你正在选机器，或者想先把线路和配置跑通再谈长期方案，可以先看看这几家的线路说明和技术参数：sixtynet（全球云服务器），先看清带宽线路、流量策略和退款条款，再决定要不要迁。
一、让登录态与节点解绑
首选无状态认证：登录后签发含有效期、受众和唯一标识的令牌，节点只验签与校时，不保存登录副本。令牌放Cookie或响应头，须核对SameSite、Secure、Domain和CORS，否则凭据被拒会被误判成账号失效。需踢下线或跨设备同步时，使用共享会话存储，以短TTL、版本号和原子续期防止旧值覆盖新值。
请求粘性不能替代认证。无状态接口可任意调度，购物车、结算再按用户或会话哈希路由；路由键须跨节点一致，不能只认源IP，否则代理和移动网络会造成“同键不同节点”。长连接要设计WebSocket重连：携带续传令牌与消息序号，配合退避和抖动。灰度切流依次控制身份、流量、连接：先兼容新旧令牌，再按比例切请求，最后迁长连接，每层保留撤销开关。
共享存储不可用时，敏感写宁可短暂拒绝或降级只读，也不能放宽校验；旧节点保持热备，路由回退与密钥撤销分开执行。
二、用证据判断粘性是否失效
先统一会话标识设计并贯穿链路：入口生成trace_id，负载层记录路由键与节点，业务层记录会话版本。按会话比对新旧机房的验签结果、落点和版本：401集中在单节点，先查密钥、时钟与受众；请求成功但状态为空，多半是本地会话或缓存未共享；命中均匀却操作错乱，检查粘性键是否误写成实例地址。
灰度门槛包含错误率、会话恢复率、版本倒退数和目标容量。先放1%新流量，覆盖完整会话周期后再扩大；兼容窗口长于旧会话TTL，旧密钥只验证不签发。WebSocket观察连接数、握手失败率和重复消息。出现登录风暴、版本回退或延迟陡升，立即把新流量调回0%，旧节点热备，回滚中不删共享存储。
常见坑还有DNS缓存、跨机房复制延迟、Redis主从切换丢会话及前端只取一次令牌。迁移期间可用随身服务器作临时只读代理或旧入口回退，但须限制写流量并沿用同一身份校验。回滚完成不等于页面能打开，而是旧入口重新承接、令牌可验、状态可读且敏感写恢复一致。
共享会话存储与灰度流量切换
会话标识应使用高熵随机值并带格式版本，避免泄露用户信息。迁移后的会话不能只放在单节点内存中，否则重调度或故障转移会造成随机掉线。共享会话存储可采用 Redis，并设置绝对过期时间、空闲超时和降级策略。若用无状态认证，令牌只携带用户标识、权限版本、签发及过期时间，由服务端验签；密钥轮换需保留旧密钥验证窗口，权限变更通过版本号或撤销列表即时生效。敏感操作仍需查询集中状态，因为无状态不等于不可撤销。
灰度流量切换前应统一 Cookie 名称、Domain、Path、SameSite 与 Secure 属性，并让新旧服务接受同一会话标识和签名格式。旧系统无法改造时，可用短期桥接层查询旧存储并重签新令牌，避免长期双写。灰度期间按用户或会话哈希稳定路由，比较登录成功率、401/403 比例和会话创建速率；出现异常时停止扩量，再按预设 TTL 让旧会话失效或定向撤销。
WebSocket重连与常见故障
WebSocket 已连接不代表消息不会丢失。服务端应记录最后确认的消息序号，WebSocket重连时由客户端携带该序号，从可靠队列补发；客户端采用带抖动的指数退避，避免切流后所有连接同时冲击新集群。连接需配置心跳、空闲超时和最大存活时间，网关要正确转发 Upgrade 头。令牌过期时先刷新再恢复订阅，服务端同时校验频道权限；补发与消费必须幂等，避免重复订单、通知或状态变更。
常见坑包括：多标签页并发刷新令牌后旧响应覆盖新值；漏配父域 Cookie；本地环境误用 Secure Cookie；Redis 切换丢失新数据；时钟偏差导致令牌提前失效；网关未透传来源；新旧实例序列化格式不同。排障应沿浏览器、网关、应用、会话存储和消息队列逐层核对，并区分未登录、会话过期、权限不足与网络中断。
上线前可执行检查清单：①用同一会话样本确认新旧节点均可验签，权限变更立即生效；②验证 Redis 超时、重启、主从切换和容灾降级时，登录、续期、退出符合预期；③用真实浏览器测试跨子域、Cookie 清理、多标签页和并发刷新；④模拟 WebSocket 断开、迟到及重复消息，确认重连无风暴且操作幂等；⑤监控登录成功率、401/403、存储延迟、活跃连接数、重连率和消息重复率；⑥写明停止放量条件、回滚步骤、旧令牌失效时间及存储恢复方案。全部通过后再逐级扩量，并保留至少一个旧会话 TTL 的观察窗口。
喜欢 
顶
难过
囧
围观
无聊
