必须在每层Nginx反向代理中显式配置proxy_set_header Host $http_host;，以透传客户端原始Host头（含端口），避免被逐层覆盖导致重定向异常、资源路径错误等问题。
当请求经过多层代理（如 CDN → 负载均衡器 → Nginx 反向代理 → 应用服务）时，后端应用看到的 Host 头往往不是客户端原始请求的域名，而是最靠近它的那层代理的内部地址（如 10.0.1.5:8080 或 localhost），导致重定向异常、静态资源路径错误、Cookie 域名不匹配等问题。关键在于：**让最终后端始终收到客户端发起请求时使用的原始 Host 值**，而不是逐层被覆盖后的值。
明确 Host 头在代理链中的流转逻辑
Nginx 默认会在反向代理时重写 Host 头为 proxy_pass 指令中指定的上游地址的 host 部分（例如 proxy_pass http://backend; 会设为 backend）。这会丢弃原始 Host。要保留它，必须显式用 proxy_set_header Host $host; 或更稳妥的 $http_host; 覆盖默认行为。
注意区别：
-
$host：取自请求行的 Host，自动小写，不带端口（如example.com） -
$http_host：取自请求头的 Host 字段原样值（可能含端口，如example.com:443） -
$server_name：当前 Nginx server 块的 server_name，与客户端无关，一般不用
在每层 Nginx 代理上正确配置 proxy_set_header Host
不是只在最后一层配，而是**每一级作为反向代理的 Nginx 都需显式设置**，确保 Host 不被下一层覆盖。典型配置如下：
location / {
proxy_pass http://app_backend;
proxy_set_header Host $http_host; # ← 关键：透传原始 Host
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
}
如果该 Nginx 本身也位于另一层代理之后（如前面还有 AWS ALB 或 Cloudflare），$http_host 仍是客户端最初发来的 Host，无需额外判断 —— 因为 HTTP 头部是逐跳传递的，只要上层没改，这里就读到原始值。
避免常见陷阱
-
不要写成
proxy_set_header Host $host;在有端口的场景下：比如用户访问https://api.example.com:8443，$host会变成api.example.com（丢端口），而后端若依赖端口做路由或生成 URL，就会出错；$http_host则保留完整值。 -
不要遗漏
proxy_set_header的作用域：它必须放在location或server块内，且在proxy_pass之前；放在http块虽生效，但缺乏上下文灵活性。 - CDN 或云负载均衡器可能已改写 Host：例如 Cloudflare 默认不透传原始 Host，需确认其设置是否开启 “Preserve original host header” 或类似选项；AWS ALB 默认透传，但若启用了“Host-based routing”，需检查规则是否干扰。
验证是否生效
在后端应用中打印接收到的 Host 请求头（如 Node.js 中 req.headers.host，Python Flask 中 request.headers.get('Host')），对比浏览器地址栏输入的域名和端口。也可用 curl 模拟多层代理：
curl -H "Host: test.example.com:3000" http://your-nginx-ip/health
观察后端日志输出的 Host 值是否为 test.example.com:3000。若一致，说明配置已起效。
