nginx 默认不透传 authorization 头，需显式配置 proxy_set_header authorization $http_authorization; 并确保变量名正确、无覆盖指令，后端才能可靠接收并验证 token。
在 Nginx 中，可以通过 proxy_set_header 指令将客户端携带的 Token（如 Authorization 头中的 Bearer Token）原样或改写后传递给上游服务。关键在于正确提取、保留或构造请求头，确保后端能可靠验证身份。
从客户端提取并透传 Authorization 头
如果客户端在请求中通过 Authorization: Bearer xxx 发送 Token，Nginx 默认不会自动转发该头（因安全策略限制），需显式配置：
- 在
location或server块中添加：proxy_set_header Authorization $http_authorization; - 确保未被其他配置覆盖（例如某些发行版默认清空该头，需检查是否有
proxy_set_header Authorization "";这类重置语句） - 若使用 HTTPS，且前端是浏览器，注意跨域场景下预检请求（OPTIONS）不带 Authorization，实际请求才携带
手动构造 Token 头（如从 Cookie 或 URL 参数提取）
当 Token 不在 Authorization 头中，而是存在 Cookie 或 query string 里时，可借助 Nginx 变量提取并设置：
CPA Update - Secure CLI Proxy API Maintenance
下载
安全更新和维护 CLI Proxy API（CPA）部署与配置。用于 CPA 镜像升级、配置变更、认证目录兼容修复、上线验证与回滚。适用于用户提到“CPA 更新/升级/配置改了/容器重建/回滚”等场景。
- 从 Cookie 提取：
proxy_set_header Authorization "Bearer $cookie_token";
（假设 Cookie 名为token=abc123） - 从 URL 参数提取（仅限调试或特定场景）：
proxy_set_header Authorization "Bearer $arg_token";
（对应?token=abc123） - 组合判断（更健壮）：
用map指令定义优先级逻辑，例如先查 Authorization，再 fallback 到 Cookie
避免常见陷阱
几个容易出错但影响认证的关键点：
-
$http_authorization变量名必须小写且带下划线，不能写成$http_Authorization或$http_authorisation - 若上游服务要求固定格式（如只接受
Bearer开头），而客户端传的是Token xxx或纯 token 字符串，需手动拼接：proxy_set_header Authorization "Bearer $http_authorization";（前提是 $http_authorization 已含完整值） - 启用
underscores_in_headers on;（若自定义头含下划线，如X-Auth-Token），否则 Nginx 默认忽略带下划线的请求头 - 确认后端服务监听的 header 名称，有些框架（如 Spring Security）默认只认
Authorization，不识别X-Auth-Token
验证是否生效
最直接的方式是在上游服务日志或调试接口中打印收到的请求头。也可临时用 curl + Nginx 日志辅助验证：
- 开启 Nginx 请求头日志：
log_format headers '$http_authorization $http_x_auth_token';
再在 access_log 中引用该格式 - 用 curl 手动测试：
curl -H "Authorization: Bearer test123" http://your-nginx/，观察后端是否收到对应头 - 注意：浏览器开发者工具 Network 标签页显示的是**发出**的请求头，不是 Nginx 转发后的，最终以服务端收到为准
