nginx 默认静默丢弃 authorization 头，需逐层排查：客户端是否发送、nginx 是否接收并识别、是否正确透传、后端是否读取；关键配置为 proxy_set_header authorization $http_authorization; 且需检查覆盖与信任代理设置。
后端收不到 Authorization 头，不是“偶尔出问题”，而是 Nginx 默认就把它静默丢弃了。排查要从客户端发没发、Nginx 拦没拦、透传配没配、后端读没读四个环节逐层验证，不能只改配置不看日志。
确认客户端是否真正发送了 Authorization 头
很多问题其实卡在第一步：请求压根没带这个头。
- 用 curl 直接模拟，明确指定头：curl -v -H "Authorization: Bearer abc123" https://your-api.com/test
- 浏览器开发者工具 Network 标签页里点开请求，查看 Request Headers 区域，确认 Authorization 行存在且格式正确（如 Bearer xxx 或 Basic YWRtaW46MTIz）
- 如果走的是前端 SDK 或网关（如 Kong、API 网关），检查它们是否在转发前已移除或重写了该头
检查 Nginx 是否接收并识别到了该头
Nginx 收到了，才谈得上转发；收不到，说明被上游（CDN、LB）或自身规则拦截了。
- 临时添加调试日志，在 http 或 server 块中加：log_format debug '$remote_addr - [$time_local] "$request" $status $http_authorization';，再在 access_log 中启用该格式
- 重启 Nginx 后发起请求，查 access.log。如果 $http_authorization 字段为空，说明 Nginx 没收到——可能是浏览器跨域预检（OPTIONS）没带、CDN 过滤、或客户端根本没发
- 注意：HTTP 头名不区分大小写，Authorization 和 authorization 都能被 $http_authorization 变量捕获
验证 Nginx 是否正确透传给了后端
这是最常出错的环节。默认不透传，必须显式配置，且变量名不能错。
- 在对应 location 块中确认有这行：proxy_set_header Authorization $http_authorization;
- 变量名必须是 $http_authorization（全小写 + 下划线），不能是 $http_Authorization、$sent_http_authorization 或 $auth
- 检查有没有其他配置覆盖它，比如某处写了 proxy_set_header Authorization ""; —— 这会清空值
- 如果 Authorization 实际是自定义变体（如 X-Auth-Token、api_key），且含下划线，需先在 http 块启用：underscores_in_headers on;，再用 $http_x_auth_token 等变量透传
确认后端服务是否真正收到了并正确读取
透传成功 ≠ 后端能用。框架通常不会自动解析或信任代理来的头。
- 后端代码里直接打印原始请求头：Node.js 用 req.headers.authorization，Spring Boot 用 request.getHeader("Authorization")，不要依赖封装好的 user 对象
- 检查后端是否启用了“信任代理”机制：Express 要设 app.set('trust proxy', true)；Spring Cloud Gateway 默认不传递部分头，需在 GlobalFilter 中显式保留
- 如果是 Kubernetes Ingress-NGINX，注意它在启用外部认证（oauth2-proxy）时会主动 unset Authorization 头，需通过 annotation 关闭：nginx.ingress.kubernetes.io/auth-signin: "..." 配合 nginx.ingress.kubernetes.io/auth-response-headers: "Authorization"
