Nginx反向代理时后端收不到原始Host头，主因是未正确配置proxy_set_header Host；应使用$host或$http_host透传，避免$proxy_host或硬编码，并配合X-Forwarded-Proto等头处理HTTPS和端口场景。
在 Nginx 作为反向代理时，后端服务（如 Node.js、Python Flask、Java 应用等）收不到原始请求的
头，通常是因为 Nginx 默认未透传该头部，或被显式覆盖。修复关键在于确保
指令正确配置，并匹配客户端真实意图。
确认 Host 头是否真的丢失
先在后端服务中打印所有请求头（例如用
或
），观察是否有
字段；同时用
查看原始请求的 Host 值。注意：浏览器自动补全的 Host 是域名，而 Nginx 默认转发的是 upstream 的地址（如
），这容易被误判为“丢失”，实则是被错误重写了。
正确透传原始 Host 头
在
或
块中添加或修正以下指令：
—— 传递客户端请求中的 Host（不含端口，适合标准 HTTP/HTTPS）
—— 传递原始 Host 头完整值（含端口，如
），更贴近客户端实际发送内容
避免写成
或硬编码（如
），否则会覆盖原始值
处理 HTTPS 和端口不一致场景
当 Nginx 终止 HTTPS，但后端走 HTTP 且监听非标准端口时，仅靠
可能丢失端口信息，导致后端生成错误的绝对 URL（如跳转链接、资源路径）。此时建议：
统一使用
，它保留客户端发起请求时的 Host 全貌
若后端依赖协议信息（如判断是 http 还是 https），需额外设置：
必要时补充
：
，供后端安全还原原始 Host
检查是否有其他配置干扰
某些情况下，Host 失效并非主配置问题，而是被其他规则覆盖：
确认没有重复的
出现在多个嵌套块中（如 server 内又套 location），后者会覆盖前者
检查是否启用了
—— 虽不直接影响 Host，但若自定义 header 名含下划线，可能触发 Nginx 忽略整个 header 解析（默认丢弃含下划线的 header）
验证是否启用
或 rewrite 规则意外修改了请求头
改完配置后执行
测试语法，再
生效。不复杂但容易忽略。
Hostproxy_set_header Hostconsole.log(req.headers)request.headershostcurl -v http://your-domain.com127.0.0.1:3000locationserverproxy_set_header Host $host;proxy_set_header Host $http_host;example.com:8080proxy_set_header Host $proxy_host;Host example.com$host$http_hostproxy_set_header X-Forwarded-Proto $scheme;X-Forwarded-Hostproxy_set_header X-Forwarded-Host $http_host;proxy_set_header Hostunderscores_in_headers on;proxy_redirectnginx -tnginx -s reload