故障转移时Cookie或Token验证失效，本质是请求切到新节点后会话上下文丢失或不被识别；需聚焦三点：会话是否跨节点复用、Cookie/Token是否透传与路由正确、切换前后状态是否一致。
故障转移时 Cookie 或 Token 验证失效，本质不是“Nginx 没转发”，而是“请求被切到新节点后，会话上下文丢失或不被识别”。这通常发生在负载均衡集群中某台后端宕机、Nginx 自动将流量切走的瞬间。排查需聚焦三点：会话是否可跨节点复用、Cookie/Token 是否被正确透传与路由、以及切换前后状态是否一致。
确认会话是否真正支持跨节点
若后端是单体部署（如单台 Tomcat），未启用 Session 共享机制，故障转移必然导致验证失败——新节点没有旧 Session 数据。必须明确：
- 使用 Redis / Memcached 存储 Session，并在所有后端实例中统一配置（如 Tomcat 的
RedisHttpSessionConfiguration） - JWT 或 Token 类认证需无状态：Token 由授权服务签发、前端携带、后端校验签名+有效期，不依赖本地存储
- 避免依赖
JSESSIONID等容器级 Session ID 做核心鉴权，它天然不具备跨节点能力
检查 Cookie 路由与透传是否断裂
Nginx 故障转移本身不破坏 Cookie，但以下配置缺失会导致“看似转移成功，实则验证跳闸”：
Token Analyzer
下载
基于官方 GMGN API 的代币分析工具。通过合约地址查询代币在 SOL/BSC/Base 链上的准确市场数据、安全检测、KOL 分析、开发者分析和 AI 智能分析（叙事/筹码/老鼠仓/机器人）。支持自动识别链。
-
未启用 sticky 策略：轮询模式下，用户可能刚登录就因某节点宕机被切到新节点，而新节点无该会话；可临时启用
ip_hash或官方sticky cookie（1.29.6+）保活，但注意这不是长期方案 -
Cookie Path/Domain 不匹配：后端返回的
Set-Cookie: JSESSIONID=xxx; Path=/api;，但前端访问路径为/，浏览器不携带；应加proxy_cookie_path /api /; -
未重写 Domain 属性：后端设
Domain=backend.local，而用户访问app.example.com，浏览器拒收；需配proxy_cookie_domain ~\.?backend\.local ".example.com";
验证 Token 校验链路是否完整
若用 JWT 或自定义 Token，失效常源于校验环节断开：
- 新节点未同步密钥或公钥：RSA 验证需所有节点加载相同
public key；对称密钥需严格一致 - 时间不同步：Token 含
exp字段，节点间时钟偏差 >5 分钟即校验失败；建议全集群启用 NTP 同步 - Token 存储位置错误：如把 Token 存在内存缓存（如 Caffeine），故障转移后新节点查不到；应存入 Redis 并设合理 TTL
- 未透传关键 Header：
X-Forwarded-For、X-Forwarded-Proto缺失，导致后端生成的跳转 URL 错误或 HTTPS 判断失败
抓包定位具体失效环节
不要只看响应状态码，要分层验证：
- 用
curl -v或浏览器 Network 面板，确认请求头是否含Cookie或Authorization: Bearer xxx - 检查后端响应头是否有
Set-Cookie，且Domain/Path/Secure/SameSite符合当前环境 - 对比故障前后的
upstream_addr日志字段（开启log_format含该变量），确认是否真发生了节点切换 - 在新节点上查日志，搜索 Token 解析失败关键词（如 “invalid signature”、“exp expired”、“no such token in redis”）
