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