应统一使用$http_host变量并逐层显式配置proxy_set_header Host $http_host;，同时补充X-Forwarded-Proto和X-Forwarded-Host头以增强可信度，避免端口丢失或中间代理覆盖导致后端构造URL错误。
要让后端应用准确识别客户端最初请求的 Host 头，关键不是“保留”某个中间值，而是把最原始、最贴近用户意图的那个 Host 值，逐层透传下去。多层代理链路中每跳都可能覆盖或丢失 Host，必须在每一级代理上主动配置，且用对变量。
明确该用哪个变量：$host 还是 $http_host？
两者区别直接影响后端能否生成正确链接：
$host
：取自请求行中的 Host 字段，自动去掉端口（如
→
），适合标准 HTTP/HTTPS 场景
$http_host
：原样复刻客户端发送的 Host 头（含端口），更真实，尤其当后端需拼接跳转 URL 或处理非标端口时必须用它
推荐统一使用
，避免因端口缺失导致后端构造的绝对路径出错。
每一级代理都要显式设置，不能依赖默认
Nginx 默认不透传 Host，也不会继承上一级的设置。只要链路中有一层漏配，Host 就会在那断掉：
第一层（面向客户端）：在 server 或 location 块中加
第二层（转发给下一级代理）：同样位置加相同指令，确保它把收到的
再传下去
最后一层（直连后端应用）：仍需配置，否则后端看到的是 upstream 地址（如
），不是原始域名
注意：不要写
，那是 Nginx 自己解析 upstream 时用的，会覆盖原始值。
配合 X-Forwarded-* 头增强可信度
仅靠 Host 不够，后端常需判断协议和真实来源：
加
，让后端知道客户端用的是 http 还是 https
加
，提供一个可校验的原始 Host 备份，比直接信任 Host 更安全
如果链路中某层做了重写（如 rewrite 或
proxy
_redirect），确认它没意外修改 Host 头
排查干扰项：重复设置与 header 过滤
常见静默失效原因：
同一 location 内出现多次
，后写的会覆盖前写的
启用了
，虽不直接禁 Host，但若其他自定义头含下划线，Nginx 可能整条请求头解析失败
后端服务自身逻辑覆盖了 Host（例如某些框架强制设为本地地址），需检查其日志是否真没收到，而非收到后丢弃
改完务必运行
验证语法，再
生效。
example.com:8080example.com$http_hostproxy_set_header Host $http_host;$http_host127.0.0.1:3000$proxy_hostproxy_set_header X-Forwarded-Proto $scheme;proxy_set_header X-Forwarded-Host $http_host;proxy_set_header Hostunderscores_in_headers on;nginx -tnginx -s reload