authorization头丢失主因是nginx默认不透传，需显式配置proxy_set_header authorization $http_authorization;，并确认log_format含$http_authorization、underscores_in_headers on（防关联头丢弃）、large_client_header_buffers足够，最终以后端实际接收为准。
排查 Nginx HTTP 基本认证（Basic Auth）在代理转发中认证头丢失问题，核心是确认 Authorization 头是否从客户端完整抵达后端服务。它不是被“删除”，而是常因默认不透传、命名变量错误、或中间层过滤而中断。无需额外工具，靠配置检查 + 日志验证即可闭环定位。
确认 Authorization 头是否真正到达 Nginx
很多问题其实卡在最前端：浏览器或客户端根本没发这个头，或被前端网关/WAF 清洗掉了。
- 用 curl 显式携带 Base64 编码的认证头发起测试请求：
curl -v -H "Authorization: Basic dXNlcjpwYXNz" http://your-domain.com/api/protected - 检查 Nginx access_log 是否记录该头内容，需确保 log_format 包含
$http_authorization变量，例如：log_format main '$remote_addr - $remote_user [$time_local] "$request" $status $body_bytes_sent "$http_authorization"'; - 若日志中
$http_authorization为空，说明头未送达；若 curl 带了但日志没出现，需排查防火墙、CDN、WAF 或上游 LB 是否拦截或剥离了 Authorization 头
验证 Nginx 是否显式透传 Authorization 头
Nginx 默认不会把 Authorization 头转发给后端，必须手动声明。漏配是最常见原因。
- 在对应
location块中添加明确透传指令：proxy_set_header Authorization $http_authorization; - 注意：
$http_authorization是 Nginx 内置变量，对应客户端发送的原始 Authorization 值；不能写成$auth或漏掉$http_前缀 - 避免误用
proxy_pass_request_headers off;（已弃用），该指令在新版 Nginx 中无效，应统一用proxy_set_header控制 - 可配合
add_header X-Debug-Auth "$http_authorization";返回响应头，用curl -I快速验证变量是否取到值
检查多层代理与下划线兼容性干扰
虽然 Authorization 本身不含下划线，但若你同时使用自定义认证头（如 X-Api-Key、Auth-Token）或在 Basic Auth 的用户名/密码中混用特殊字符，可能触发关联配置问题。
- 确保所有参与转发的 Nginx 节点（包括前置 LB、ingress controller）的
http{}块中均启用：underscores_in_headers on;
否则带下划线的辅助认证头（如api_key_id）会被静默丢弃，影响整体认证逻辑 - 禁用
ignore_invalid_headers on;（默认为 on），否则某些非标准但合法的认证头格式可能被拒绝 - 增大 header 缓冲区，防止长 Token（如 JWT）被截断：
large_client_header_buffers 8 16k;
通过后端日志与 Nginx error_log 交叉验证
最终以“后端实际收到什么”为准，结合 Nginx 错误日志快速锁定环节。
- 在后端服务中打印原始请求头（如 Node.js 的
req.headers.authorization，Java 的request.getHeader("Authorization")），确认是否为空或被篡改 - 开启 Nginx warn 级别 error_log：
error_log /var/log/nginx/error.log warn;
触发请求后查看是否有client sent invalid header line或upstream sent too big header类警告 - 对比 access_log 中的
$http_authorization和后端日志中的实际接收值，若前者有、后者无，说明问题出在 proxy_set_header 配置或 upstream 连接环节
