必须设置Host、X-Forwarded-For、X-Forwarded-Proto三项基础Header：Host应设为后端真实域名（如api.example.com），X-Forwarded-For用$remote_addr或$proxy_add_x_forwarded_for传递真实IP，X-Forwarded-Proto用$scheme告知协议类型。
在 Nginx 中使用 proxy_set_header 适配后端 API，核心是正确传递客户端真实信息（如 IP、协议、Host），避免后端误判请求来源或无法生成正确 URL。关键不是简单复制 Header，而是按需覆盖或补充，尤其注意 Host、X-Forwarded-For、X-Forwarded-Proto 这几项。
必须设置的三项基础 Header
大多数后端 API（尤其是 RESTful 或需要生成回调地址的服务）依赖以下三个 Header 才能正常工作：
-
Host：应设为后端服务真实的 Host 名（不是客户端请求的 Host），否则后端可能因 Host 校验失败而拒接或路由错误。例如：
proxy_set_header Host api.example.com; -
X-Forwarded-For：用于传递客户端真实 IP。Nginx 默认不覆盖，需显式设置：
proxy_set_header X-Forwarded-For $remote_addr;；若上游已有该 Header（如多层代理），可用$proxy_add_x_forwarded_for追加。 -
X-Forwarded-Proto：告知后端原始请求是 HTTP 还是 HTTPS，避免重定向循环或混合内容问题：
proxy_set_header X-Forwarded-Proto $scheme;
根据后端要求动态透传或改写 Header
有些 API 会校验特定 Header（如 Authorization、Content-Type、自定义 token Header），Nginx 默认会透传，但要注意：
FastAPI Flask Proxy
下载
FastAPI + Flask 混合部署最佳实践，解决路由定义、API 代理等常见问题，适用于同时运行 FastAPI API 与 Flask 前端的场景。
- 若后端只接受
Authorization: Bearer xxx，而客户端传的是Basic，可在 Nginx 中转换：proxy_set_header Authorization "Bearer $http_authorization";（需配合 map 模块提取 token） - 若后端要求固定
Content-Type（如必须为application/json），可强制覆盖：proxy_set_header Content-Type application/json;，但需确保前端请求体格式匹配 - 避免透传敏感 Header（如
Cookie、Set-Cookie），除非明确需要。可清空：proxy_set_header Cookie "";
避免常见陷阱
看似简单的一行配置，容易因上下文失效：
-
proxy_set_header只在location或server块中生效，不能写在http块顶层（除非所有 upstream 都适用） - 如果用了
proxy_pass后带 URI（如proxy_pass http://backend/v1/;），Nginx 会重写路径，此时$host和$uri的值可能与预期不同，影响 Header 构造 - 后端若依赖
X-Real-IP，记得设置：proxy_set_header X-Real-IP $remote_addr;，它比X-Forwarded-For更可靠（单层代理时）
验证是否生效
配置完别急着 reload，先用 curl 检查实际发出的请求头：
- 在后端服务日志中打印收到的所有 Header（如 Node.js 的
console.log(req.headers)） - 用
curl -v http://your-nginx-domain/api/test查看响应头和请求路径是否符合预期 - 临时在 Nginx 中加一行日志：
log_format debug '$http_host $http_x_forwarded_for $http_x_forwarded_proto';，配合 access_log 观察真实传入值
