x-forwarded-host需用$host动态透传原始域名，禁用$http_host（含端口）和硬编码；必须配合x-forwarded-proto及后端可信代理配置，防止伪造与协议误判。
在 Nginx 作为反向代理时，后端应用（如 Django、Flask、Node.js）经常需要知道用户最初访问的域名（比如 https://shop.example.com），而不是 Nginx 自己监听的地址（如 127.0.0.1:8000）。X-Forwarded-Host 是一个常用且轻量的 HTTP 头字段，专门用于透传原始请求中的 Host 头。正确配置它，能避免后端生成错误跳转链接、静态资源路径异常、HTTPS 判断失准等问题。
为什么用 X-Forwarded-Host 而不是 Host？
Nginx 默认会把客户端发来的 Host 头直接转发给后端，但如果你用了 proxy_set_header Host $host; 或类似覆盖，就可能丢失原始值。而 X-Forwarded-Host 是业界约定俗成的“只读透传字段”，后端可明确区分：它是代理带进来的，不是客户端直连时自己设的。尤其当 Nginx 做多站点统一入口（如泛域名路由）时，这个头是唯一可靠来源。
基础配置写法（安全且实用）
在 Nginx 的 location 或 server 块中添加：
proxy_set_header X-Forwarded-Host $host;
FastAPI Flask Proxy
下载
FastAPI + Flask 混合部署最佳实践，解决路由定义、API 代理等常见问题，适用于同时运行 FastAPI API 与 Flask 前端的场景。
注意几个关键点：
-
别用
$http_host：它可能包含端口（如example.com:443），而多数后端只期望纯域名；$host自动剥离端口，更干净 -
不要硬编码域名：避免写成
proxy_set_header X-Forwarded-Host shop.example.com;，否则无法复用配置处理多个子域 -
配合其他转发头更完整：建议同时设置
X-Forwarded-For和X-Forwarded-Proto，方便后端识别真实 IP 和协议
后端如何安全使用这个头
不能无条件信任该头——攻击者可能伪造 X-Forwarded-Host。务必只从可信代理（即你的 Nginx）接收并使用它：
-
Django：启用
USE_X_FORWARDED_HOST = True，并确保SECURE_PROXY_SSL_HEADER = ('HTTP_X_FORWARDED_PROTO', 'https')已配好；Django 内部会自动校验ALLOWED_HOSTS是否匹配X-Forwarded-Host -
Flask / WSGI 应用：用
ProxyFix中间件（来自 Werkzeug），设置trusted_hosts=['your-nginx-ip']，它会自动提取并验证X-Forwarded-Host -
Node.js（Express）：启用
app.set('trust proxy', '127.0.0.1')，然后通过req.hostname获取解析后的原始域名（底层已基于X-Forwarded-Host安全推导）
常见踩坑与验证方法
配置完别急着上线，快速验证是否生效：
- 在后端加一行日志：
console.log('X-Forwarded-Host:', req.headers['x-forwarded-host'])或等效语句，用浏览器或curl -H "Host: api.example.com" http://your-nginx/测试 - 如果始终为空：检查是否漏写了
proxy_set_header，或被其他 location 块覆盖；也可能是 Nginx 版本太低（需 ≥1.3.12） - 如果出现
localhost或内网 IP：说明$host没取到客户端 Host，确认客户端请求里 Host 头确实正常（非 curl 未带 -H 时的默认行为） - HTTPS 场景下，若后端仍生成 http 链接：单靠
X-Forwarded-Host不够，必须同步设置X-Forwarded-Proto: https并让后端识别
