在配置 Nginx 作为反向代理时，很多人都会遇到一个看似简单却暗藏玄机的配置项：proxy_set_header Host。
当你的 Nginx 接收来自公网的请求，并将其转发给内网的源站服务器（例如 172.16.0.10）时，这个 Host 头到底应该透传客户端的 $http_host，还是直接写死内网的源站 IP 呢？
如果你曾经遇到过“页面样式丢失”、“登录后无故跳转到打不开的内网 IP”、“接口报错 404”等灵异事件，那么这篇文章将为你彻底解开谜团。
一、 什么是 Host 头？为什么它如此重要？
在深入对比之前，我们需要先复习一下 HTTP 协议的基础。
在 HTTP/1.1 协议中，Host 请求头是必填项。它的作用是告诉服务器：“我这次请求的是你这台机器上的哪个域名”。
打个比方：源站服务器（比如 172.16.0.10）就像是一栋公寓大楼，而大楼里住着很多租户（也就是虚拟主机，比如 www.a.com 和 www.b.com）。
- IP 地址 只能把快递（请求）送到公寓大楼的收发室。
- Host 头 则是快递单上的“门牌号”，它告诉收发室，这个包裹到底该交给 A 租户还是 B 租户。
理解了这一点，我们再来看 Nginx 代理时的两种配置方式，它们的差异就会非常清晰了。
二、 方案 A：透传客户端域名 ($http_host)
这是目前业界最标准、最推荐的做法。
location / {
proxy_pass http://172.16.0.10:8080;
proxy_set_header Host $http_host;
}1. 它是如何工作的？
当外网用户访问 http://www.example.com/api 时，Nginx 会把请求转发给 172.16.0.10，并且在请求头中带上 Host: www.example.com。
2. 为什么推荐这样做？
- 精准匹配虚拟主机（Virtual Hosts）：如果你的内网服务器（如 Tomcat、Apache 甚至另一层 Nginx）配置了多个域名站点，它收到请求后，能够根据
Host头的www.example.com准确找到对应的网站目录并处理请求。 - 重定向与绝对路径生成完美契合：很多现代框架（如 Spring Boot、WordPress、Laravel）在进行 301/302 页面跳转，或者生成分页的绝对链接时，会动态读取请求中的
Host头。因为源站收到了真实的域名，生成的跳转链接依然是http://www.example.com/login，外网用户可以无缝访问。
三、 方案 B：写死源站 IP (172.x.x.x)
有些开发者在配置时，可能会忽略这个请求头，或者显式地将其设置为源站的 IP 地址。
location / {
proxy_pass http://172.16.0.10:8080;
proxy_set_header Host 172.16.0.10;
# 或者不写这个配置，使用 Nginx 默认的 $proxy_host
}在这种情况下，源站收到的请求头会变成 Host: 172.16.0.10。这会在实际生产环境中引发一系列灾难性的问题：
🚨 踩坑场景 1：访问错乱或直接 404
就像前面提到的公寓大楼，快递单上没写门牌号，只写了“大楼地址”。
如果内网服务器配置了多个网站，它一看 Host 是个 IP，不知道该交给谁，通常会直接把请求扔给默认站点（Default Server）。如果你的目标站点不是默认站点，用户看到的可能就是 404 错误页，或者是别人的网站内容。
🚨 踩坑场景 2：重定向“内网泄漏”导致网页打不开
这是最常见、也最让人头疼的 Bug。
假设用户访问 www.example.com/admin（注意末尾没加斜杠）。后端程序（比如 Tomcat）发现这是一个目录，会自动发起一个 302 重定向，让你跳转到 /admin/。
因为后端认为当前的域名是 172.16.0.10，它生成的跳转链接会是：Location: http://172.16.0.10/admin/
外网用户的浏览器收到这个指令后，会傻乎乎地去请求 172.16.0.10 这个局域网 IP。结果可想而知——浏览器一直转圈，最后提示“无法访问此网站”。
🚨 踩坑场景 3：云平台与 WAF 的拦截
如果你的内网源站不是一台物理机，而是阿里云、腾讯云上的负载均衡（SLB）或 API 网关。这些云产品为了安全和路由转发，通常会强制校验 Host 域名。如果你直接传一个内网 IP 过去，云平台的网关会认为这是一个非法请求，直接给你返回 400 或 403 Forbidden。
四、 核心差异一览表
为了方便记忆，我们可以通过下表快速对比：
| 维度 | 使用 $http_host (透传域名) | 使用 172.x.x.x (写死IP) |
|---|---|---|
| 源站接收的 Host | www.example.com (用户实际访问的域名) | 172.16.0.10 (内网 IP) |
| 多站点(虚拟主机)支持 | ✅ 完美支持，精准路由 | ❌ 无法匹配，通常落入默认站点 |
| 301/302 跳转链接 | ✅ 生成正常的公网域名链接 | ❌ 生成内网 IP 链接，导致外网访问断开 |
| 日志记录 (Access Log) | ✅ 记录真实的访问域名，方便统计排查 | ❌ 满屏都是内网 IP，无法区分业务来源 |
| WAF/云网关兼容性 | ✅ 正常通过校验 | ❌ 极大概率被安全策略拦截 |
五、 最佳实践总结
在 99% 的反向代理场景中，为了保证 HTTP 请求的原貌被完整保留，请务必透传客户端的域名。
🌟 标准配置模板：
location / {
proxy_pass http://172.16.0.10:8080;
# 透传 Host 域名 (推荐使用 $host，它包含了 $http_host 的功能并做了兜底)
proxy_set_header Host $host;
# 顺手带上用户的真实 IP，这也是反代必备配置
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;
}🤔 什么时候才会用到源站 IP？
凡事无绝对，如果你遇到以下极其特殊的场景，才会考虑不透传域名：
- Nginx 仅仅作为纯内网的端口转发工具，且后端是一个完全不依赖域名的纯净微服务（如一个简单的 Python RPC 接口）。
- 你需要通过反向代理“伪装”身份，比如利用 Nginx 去抓取或代理别人的网站，这时候你需要把 Host 设置为目标网站的域名，而不是客户端的域名。
希望这篇文章能帮你彻底搞懂 Nginx 的 Host 配置逻辑。下次再遇到神秘的 302 重定向报错时，不妨先去检查一下你的 proxy_set_header 写对了没有！
版权属于：soarli
本文链接：https://blog.soarli.top/archives/980.html
转载时须注明出处及本声明。
