proxy_set_header Authorization "";可清空客户端Authorization头，防止后端误用敏感凭证；需加双引号、置于proxy_pass前，并配合Cookie等头一并清理以保障安全。
在 Nginx 反向代理场景中，proxy_set_header 本身不能“清空”请求头，但可以通过显式设为空字符串来覆盖原始 Authorization 头，从而防止后端服务意外接收到上游客户端携带的敏感凭证（如 Bearer Token、Basic Auth 凭据）。
为什么需要主动清除 Authorization 头
默认情况下，Nginx 会将客户端请求中的 Authorization 头原样转发给后端。如果后端服务未做鉴权隔离、或被误配置为信任该头，就可能引发越权访问或凭证泄露风险。尤其在多租户网关、API 聚合层或前端代理静态资源时，必须确保后端无法获取用户原始认证凭据。
正确写法：用空字符串覆盖 Authorization
在 location 或 server 块中添加：
FastAPI + Flask 混合部署最佳实践，解决路由定义、API 代理等常见问题，适用于同时运行 FastAPI API 与 Flask 前端的场景。
proxy_set_header Authorization "";
注意：
- 必须使用双引号包裹空字符串（""），不能省略引号或写成 proxy_set_header Authorization;（语法错误）
- 该指令需放在 proxy_pass 之前，且优先级高于默认继承行为
- 若同时设置了其他 proxy_set_header，此行应保持位置合理，避免被后续同名指令覆盖
配合其他安全头一并清理
除 Authorization 外，以下头也常含敏感信息，建议按需清除：
-
proxy_set_header Cookie "";—— 防止后端读取用户会话 Cookie（适用于无状态后端） -
proxy_set_header X-Forwarded-For "";—— 避免伪造源 IP（若后端不依赖真实客户端 IP） -
proxy_set_header X-Real-IP "";—— 同上，与X-Forwarded-For配合使用时需谨慎
验证是否生效
可通过以下方式确认头已被清除：
- 在后端服务日志或调试接口中打印所有请求头，检查 Authorization 是否为空或缺失
- 使用 curl -H "Authorization: Bearer abc123" http://your-proxy/ 发起测试请求，抓包观察 upstream 请求中该头是否为空
- 在 Nginx 配置中临时加入 add_header X-Debug-Authorization "$http_authorization";，通过响应头查看原始值（仅用于调试，上线前移除）
