要让后端正确识别用户身份，必须显式配置 Nginx 透传 Authorization 头：proxy_set_header Authorization $http_authorization；同时后端需主动读取并校验该头，且配合 X-Real-IP、X-Forwarded-Proto 等安全头协同使用。

要让后端服务正确识别用户身份，关键不是简单转发 Authorization 头，而是确保它在代理链中不被丢弃、不被覆盖、且能被后端安全可信地使用。

Authorization 头默认不会透传

Nginx 默认不会自动转发 Authorization 请求头——即使你写了 proxy_pass，这个头也会被静默剥离。这不是 bug，而是出于安全考虑的默认行为。如果你没显式配置，后端收到的请求里根本看不到 Authorization。

• 必须手动添加：proxy_set_header Authorization $http_authorization;
• 变量名严格区分大小写：$http_authorization 对应请求头 Authorization（注意首字母大写，中间无下划线）
• 若客户端发的是 authorization: Bearer xxx（小写），Nginx 仍能通过 $http_authorization 正确捕获——HTTP 头名本身不区分大小写

避免重复或污染 Authorization 值

某些场景下（如多级代理、网关前置认证），上游可能已注入或修改过 Authorization。直接覆盖可能丢失原始凭证，或引发双认证冲突。

FastAPI Flask Proxy

FastAPI + Flask 混合部署最佳实践，解决路由定义、API 代理等常见问题，适用于同时运行 FastAPI API 与 Flask 前端的场景。

下载

• 如果上游（如 API 网关、CDN）已提供该头，优先沿用：proxy_set_header Authorization $http_authorization;
• 如果上游未提供，而 Nginx 自身需补充（例如统一加 Bearer），可改用固定值：proxy_set_header Authorization "Bearer $api_token";（需配合 map 或 env 预设变量）
• 切勿写成 proxy_set_header Authorization $sent_http_authorization;——这是响应头变量，用在请求透传中完全无效

后端必须主动读取并校验

透传只是第一步。后端框架通常不会自动从 Authorization 头提取 token，更不会默认信任它——尤其当请求经过代理时，需明确启用“信任代理头”机制：

• Express/Node.js：设 app.set('trust proxy', true)，再通过 req.get('Authorization') 获取
• Spring Boot：默认忽略该头；需在 Controller 中手动调用 request.getHeader("Authorization")，或集成 Spring Security 的 BearerTokenResolver
• Flask：Werkzeug 不自动解析，直接用 request.headers.get('Authorization') 即可，无需额外中间件
• 注意：不要依赖 req.user 或 current_user 等封装对象——它们往往只在直连模式下生效，代理后需重写认证逻辑

配合其他安全头协同使用

单传 Authorization 不足以保障完整链路安全。还需同步透传上下文信息，防止伪造或歧义：

• proxy_set_header X-Real-IP $remote_addr; 和 X-Forwarded-For $proxy_add_x_forwarded_for;：辅助后端做 IP 级限流或风控
• proxy_set_header X-Forwarded-Proto $scheme;：避免因协议误判导致 token 在 HTTP 下明文传输警告
• 如需透传自定义认证字段（如 X-Api-Key），同样需显式声明：proxy_set_header X-Api-Key $http_x_api_key;