后端收不到 authorization 头，主因是 nginx 默认不透传且配置存在变量名错误、覆盖指令或命名不规范；须显式配置 proxy_set_header authorization $http_authorization;，确保变量名准确、无重置语句，并开启 underscores_in_headers on 以支持下划线头。
后端收不到 Authorization 头，绝大多数情况是 Nginx 默认不透传该头，且配置中存在变量名错误、覆盖指令或命名规范问题。解决核心就三点：显式透传、正确取值、避免丢弃。
必须显式配置 proxy_set_header Authorization $http_authorization
Nginx 默认剥离 Authorization 请求头，无论是否启用 proxy_pass，都不自动转发。必须在 location 或 server 块中添加：
-
proxy_set_header Authorization $http_authorization; —— 变量名严格为
$http_authorization（全小写，带下划线），不能写成$http_Authorization、$http_auth或$sent_http_authorization - 检查是否有其他配置覆盖了它，例如某些模板或发行版默认含
proxy_set_header Authorization "";，会清空该头 - 若上游（如 CDN、API 网关）已注入 Authorization，仍建议保留此行，确保沿用原始值
注意自定义认证头含下划线时需开启 underscores_in_headers
如果前端实际发的是 X-Auth-Token、auth_token 或 api_key 这类带下划线的头，Nginx 默认直接丢弃，后端根本收不到：
- 在
http或server块中启用：underscores_in_headers on; - 之后才能通过
$http_x_auth_token、$http_auth_token等变量提取 - 再用
proxy_set_header X-Auth-Token $http_x_auth_token;透传给后端 - 更推荐将头改为短横线命名（如
X-Auth-Token），兼容性更好
验证是否生效：从 Nginx 日志和后端日志双向确认
光配不等于通，必须验证请求头是否真正到达后端：
- 在 Nginx 配置中临时加日志：
log_format debug '$remote_addr - $request_uri $http_authorization $http_x_auth_token';，再查 access.log 确认变量有值 - 后端服务打印原始请求头（如 Node.js 的
req.headers.authorization，Spring Boot 的request.getHeader("Authorization")） - 用 curl 模拟请求：
curl -H "Authorization: Bearer abc123" http://your-api.com/test，观察后端输出 - 若后端收到空值但 Nginx 日志里有值，说明 proxy_set_header 生效；若 Nginx 日志也为空，说明客户端根本没发，或被浏览器/CDN 拦截
补充常见干扰场景
有些问题看似是 Nginx 配置问题，实则来自链路其他环节：
- 浏览器跨域预检（OPTIONS）不带 Authorization，仅实际请求才携带，后端不要在 OPTIONS 响应里依赖该头做鉴权
- Kubernetes Ingress-NGINX 默认在外部认证后 主动 unset Authorization，需用
nginx.ingress.kubernetes.io/auth-response-headers: "Authorization"注解恢复 - 若 Token 实际存在 Cookie 或 URL 参数中，需改用
proxy_set_header Authorization "Bearer $cookie_token";或配合map指令做多源 fallback
