在 nginx 中转发 authorization 请求头，核心做法是配置 proxy_set_header 指令。默认情况下，nginx 会过滤掉包含下划线的头部（如 http_authorization），因此必须显式声明 proxy_set_header authorization $http_authorization;。这样后端服务就能正确获取到客户端传递的 token 或凭证进行鉴权。
Nginx 如何配置以透传 Authorization 头
要实现透传，需要在 location 块中添加特定的 proxy_set_header 指令。这能覆盖 Nginx 默认的头部过滤行为，确保原始请求头被原样传递给上游服务器。
server {
listen 80;
server_name example.com;
location /api/ {
proxy_pass http://backend_server;
# 关键配置：透传 Authorization 头
proxy_set_header Authorization $http_authorization;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
}
}
上述配置中，$http_authorization 变量捕获了客户端发送的 Authorization 头。如果不加这一行，Nginx 可能会丢弃该头，导致后端收到空值。同时保留 Host 和 X-Real-IP 也是常见最佳实践，有助于后端识别真实来源。
如何处理非标准或自定义鉴权头
如果鉴权系统使用自定义头部（如 X-API-Key），Nginx 默认不会过滤它们，但仍建议显式设置以确保一致性。对于标准 Authorization 头，务必注意大小写敏感性和空格处理。
# 假设后端期望接收 X-API-Key
location /secure/ {
proxy_pass http://internal_api;
proxy_set_header X-API-Key $http_x_api_key;
proxy_set_header Authorization $http_authorization;
}
在处理自定义头时，变量名遵循 $http_ 前缀加上小写头部名称的规则。例如 X-API-Key 对应 $http_x_api_key。这种映射关系是固定的，开发者需根据实际使用的头部名称调整变量名。若头部包含特殊字符或复杂结构，建议在后端进行解析而非依赖 Nginx 预处理。
当 Authorization 头缺失时后端如何响应
当客户端未提供 Authorization 头时，$http_authorization 变量为空字符串。此时后端应返回 401 Unauthorized 状态码。Nginx 本身不拦截此情况，而是将空值传递给后端应用逻辑。
