排查Nginx集群重定向不一致导致会话断开，关键在于确认所有节点重定向行为物理统一：需逐行比对配置、禁用proxy_redirect、统一return URL、验证响应头Location与Set-Cookie、协同后端context-path及前端base路径。
排查 Nginx 集群中因重定向策略不一致导致的用户会话断开，关键在于确认“重定向行为是否在所有节点上完全统一”，而非仅检查单台配置是否能跑通。问题常表现为：用户登录后跳转异常、刷新页面丢失 session、部分节点返回 302 到错误域名或路径、前后端 base 路径错位引发白屏等。
核对各节点的重定向逻辑是否物理一致
集群中任意一台 Nginx 的重定向配置若有差异（哪怕只是少一个 proxy_redirect off 或多一条隐式 rewrite），都可能造成响应头 Location 字段不一致，从而破坏前端路由或 Cookie 域名绑定。
- 登录所有 Nginx 节点，执行 nginx -T | grep -A5 -B5 "return 301\|rewrite.*redirect\|proxy_redirect"，比对输出是否逐行相同
- 重点检查是否所有节点都禁用了自动重写：proxy_redirect off; 必须显式存在，否则 Nginx 可能根据 upstream 响应头中的 Location 自动改写为本机域名
- 若使用了 return 301/302，确保 URL 中的协议、域名、路径前缀（如 /admin）在所有节点上完全一致，避免混用 $host、$http_host、硬编码域名
验证重定向响应头的真实内容
用户看到的跳转，取决于浏览器最终收到的 HTTP 响应头，而不是你写的配置意图。必须从客户端视角抓取真实响应。
- 用 curl -Iv https://yourdomain.com/login 分别请求不同 VIP 或节点 IP，观察 Location: 值是否一致（注意：需绕过 DNS 和负载均衡器直连各 Nginx）
- 检查响应头中 Set-Cookie 的 Domain= 和 Path= 是否统一；例如，若有的节点设 Path=/admin，有的设 Path=/，会导致 Cookie 不携带，session 失效
- 开启 Nginx access_log 的完整 header 记录（使用 log_format 自定义字段），在日志中确认每条 301/302 请求的 $sent_http_location 和 $sent_http_set_cookie
检查与上游服务协同的重定向语义
很多“重定向不一致”实际是后端服务返回的 302 Location 被 Nginx 错误透传或改写所致，尤其当多个后端实例部署路径或 context-path 不同时。
- 确认所有后端服务的 server.servlet.context-path（Spring Boot）、APP_BASE_URL（Node.js）或类似配置完全一致，且与 Nginx 的 location 前缀严格对齐
- 在 upstream 中添加 proxy_pass_request_headers on; 并关闭自动重写：proxy_redirect off;，防止 Nginx 擅自修改后端返回的 Location
- 若后端返回的是相对路径（如 Location: /dashboard），需确保所有 Nginx 节点的 server_name 和 listen 配置一致，否则浏览器会按当前 host 拼接，导致跨节点跳转到错误域名
前端与 Nginx 协同验证路径基准
重定向断开会话，往往是因为前端 JS（如 Vue Router）基于错误的 base 路径生成跳转链接，而该路径又受 Nginx 重定向影响形成闭环。
- 检查前端构建时的 publicPath 和运行时的 router.base，是否与 Nginx 暴露给用户的路径前缀（如 /app/）完全匹配
- 在浏览器控制台执行 location.href 和 document.baseURI，确认当前页面基础路径是否被某次重定向意外改变
- 模拟用户操作：登录 → 点击菜单跳转 → 刷新页面，全程用 Network 面板过滤 302 和 XHR，观察每次重定向后的 URL 是否稳定落在同一路径域内
