脚本需主动携带Authorization头，Nginx默认透传但需避免auth_basic干扰或proxy_hide_header清除；推荐脚本端用auth=("user","pass")自动编码，或Nginx中proxy_set_header注入。
在自动化脚本中用 Nginx 作为反向代理或后端服务时，若目标接口启用了 HTTP 基本认证（Basic Auth），脚本需主动携带 Authorization 请求头。Nginx 本身不生成凭据，但可透传、校验或注入该头——关键在于脚本如何构造请求，以及 Nginx 配置是否允许或干预该头。
脚本端直接添加 Authorization 头
这是最常用且推荐的方式：脚本自身编码凭据并设置请求头，Nginx 默认透传（不修改）该头。
- 凭据格式为
username:password，经 Base64 编码后拼接为Basic base64_string - cURL 示例：
curl -H "Authorization: Basic dXNlcjpwYXNz" https://api.example.com/health - Python requests 示例：
requests.get("https://api.example.com/health", auth=("user", "pass"))（自动处理编码） - 确保 Nginx 未清除或覆盖该头（见下文配置注意点）
Nginx 配置中透传或强制注入 Authorization 头
若脚本无法控制请求头（如调用第三方工具），可在 Nginx 层面注入或保留凭据头：
- 透传客户端原始头（默认行为，但需确认未被 proxy_pass 过滤）：
proxy_pass_request_headers on;（默认即开启） - 从请求参数或 cookie 提取凭据并重写头（需配合 map 指令）：
map $arg_auth $auth_header { default ""; "abc" "Basic dXNlcjpwYXNz"; }proxy_set_header Authorization $auth_header; - 对特定 upstream 强制添加固定凭据（适用于后端服务要求统一认证）：
location /api/ {<br> proxy_set_header Authorization "Basic dXNlcjpwYXNz";<br> proxy_pass http://backend;<br>}
避免常见陷阱
Nginx 对 Authorization 头有特殊处理逻辑，容易导致凭据丢失或 400 错误：
-
不要在 location 中用 rewrite + break 修改 Authorization 头：rewrite 不影响请求头，应使用
proxy_set_header -
检查是否启用了 auth_basic：若 Nginx 自身开启了
auth_basic，它会先校验客户端凭据，再把请求转发给后端；此时后端收不到原始 Authorization 头（已被 Nginx 消费）。如需后端也校验，应禁用 Nginx 的 auth_basic，改由后端或 proxy_set_header 注入 -
注意大小写与空格：HTTP 头名不区分大小写，但值必须严格为
Basic <base64>，前后空格错误会导致认证失败 -
启用 proxy_pass_request_headers 时确认无 proxy_hide_header 干扰：默认不隐藏 Authorization，但显式配置
proxy_hide_header Authorization;会阻止透传
调试技巧
快速验证凭据是否送达后端：
- 在后端服务日志或临时接口中打印所有请求头（如 Node.js 的
req.headers.authorization，Python Flask 的request.headers.get('Authorization')） - 用 Nginx 日志记录请求头：
log_format debug '$remote_addr - $remote_user [$time_local] "$request" $status $body_bytes_sent "$http_authorization"';<br>access_log /var/log/nginx/debug.log debug;
- 抓包验证（如 tcpdump 或 curl -v）确认客户端发出的请求确实含正确头
