Nginx反向代理导致登录失效主因是认证头透传缺失；需显式配置proxy_set_header Authorization $http_authorization、proxy_pass_header Set-Cookie，并检查Cookie双向流转、下划线头部支持及日志比对。
排查 Nginx 因请求头丢失导致的登录失效，核心是确认关键认证头（如 Authorization、Cookie、X-Forwarded-For 等）是否完整透传到后端服务。常见于反向代理场景下，Nginx 默认行为或配置疏漏会截断、重写或忽略某些头部。
检查 Nginx 是否透传 Authorization 头
Nginx 默认不会转发 Authorization 头（出于安全考虑），若后端依赖该头做 Bearer Token 或 Basic 认证，就会直接 401。需显式开启：
- 在
location或server块中添加：proxy_pass_request_headers on;（默认已开启，但建议显式声明） - 确保未意外覆盖：
proxy_set_header Authorization $http_authorization; - 若使用了
proxy_pass_request_body off;等非常规设置，也要同步检查头部传递逻辑
验证 Cookie 和 Set-Cookie 的处理是否合规
登录态通常依赖 Cookie，而 Nginx 对 Cookie 和 Set-Cookie 的转发有特殊规则：
-
Cookie请求头默认可透传，但若后端域名与前端不一致（如跨域），浏览器可能因 SameSite 策略不发送，此时需确认前端请求是否带credentials: 'include' -
Set-Cookie响应头默认会被 Nginx 丢弃（尤其当后端设了Secure、HttpOnly或Domain属性时）；必须显式透传：proxy_pass_header Set-Cookie; - 若后端设置了
Domain属性（如Domain=example.com），而 Nginx 反向代理的域名是api.example.com，可能导致浏览器拒绝存储 Cookie——此时应让后端不设 Domain，或由 Nginx 用proxy_cookie_domain重写：proxy_cookie_domain ~. example.com;
抓包比对：确认头在 Nginx 入口和出口是否一致
最直接的方式是定位问题环节：
- 在客户端（浏览器 DevTools → Network → 登录请求）查看原始请求头，记下
Authorization、Cookie值 - 在 Nginx 机器上用
tcpdump或nginx -s reload配合log_format打印入站头：log_format debug '$remote_addr - $remote_user [$time_local] "$request" $status $body_bytes_sent "$http_referer" "$http_user_agent" "$http_authorization" "$http_cookie"'; - 在后端服务（如 Node.js/Java 日志）打印收到的全部请求头，对比是否缺失或被篡改
- 若发现 Nginx 入口有头、后端没收到，说明问题出在
proxy_set_header配置或缓冲区限制（如underscores_in_headers on;缺失导致含下划线的头被忽略）
检查 Nginx 全局与 location 级别的 header 覆盖行为
容易被忽略的是隐式覆盖：
-
proxy_set_header Host $host;会覆盖原始 Host，但一般不影响登录；而proxy_set_header Cookie "";这类清空操作会直接干掉登录态 - 若配置了
underscores_in_headers on;未开启，且上游传来类似X_Api_Key的头，Nginx 会静默丢弃（默认忽略含下划线的头） - 注意
proxy_buffering off;不影响头转发，但若启用缓冲且响应体过大，可能间接干扰头解析——不过登录失效主因极少在此
只要逐项核对 Authorization 透传、Cookie 双向流转、实际流量头一致性、以及隐式覆盖项，90% 的“登录突然失效”问题都能快速定位。不需要改业务代码，往往一行 proxy_pass_header Set-Cookie; 就能解决。
