Nginx反向代理之proxy_set_header详解：真实IP与Host透传实践

不知道你有没有遇到过这种场景：后端服务明明能收到请求，但日志里客户端的IP全是内网网段，或者服务端拿到的Host域名怎么都不对，再或者明明是HTTPS进来的，后端却认为是一次HTTP请求。十有八九，问题就出在Nginx反向代理那一层的proxy_set_header参数上。

很多刚入门的朋友配置反向代理，能写通proxy_pass就万事大吉，对proxy_set_header的态度是“抄别人配置、报错就删”，从没认真研究过这些请求头到底改变了什么。实际上，proxy_set_header解决的是反向代理场景下“真实客户端身份信息如何向后端传递”这个核心问题。无论是给后端透传真实IP、保持原始域名、还是处理HTTPS协议判定，都绕不开它。

这篇文章我不打算把官方文档复述一遍，而是结合我在生产环境里配置Nginx的经验，把proxy_set_header的常用参数、使用逻辑、真实场景配置，以及那些特别隐蔽的坑一次讲透。即使你之前完全没研究过这一块，照着我下面的思路也能把配置写明白。

1. 先搞明白proxy_set_header到底是干什么的

1.1 反向代理会让“身份信息”丢在哪一层

要理解proxy_set_header，得先搞清楚一次反向代理请求经历了什么。

假设用户在浏览器访问https://example.com，Nginx收到请求后，根据proxy_pass配置把请求转发给内网的一台Tomcat，Tomcat处理完再原路返回。这个过程中，Nginx实际上做了两件事：第一，接收客户端的TCP连接，此时Nginx知道客户端的IP（存在$remote_addr变量里）；第二，作为HTTP客户端，向Tomcat发起一个新的HTTP请求。

问题就出在这第二次请求上。Nginx向Tomcat发起新请求时，默认情况下，HTTP请求头里的Host字段会被改成proxy_pass指定的上游地址，而不是用户浏览器里的example.com。同时，Tomcat看到的请求来源IP是Nginx的IP，而不是用户的真实IP。如果你不主动设置proxy_set_header，后端服务拿到的，就是一套“被代理加工过”的身份信息。

举个例子，我在一个PHP项目里见过这样的情况：应用统计用户地区，全部依赖$REMOTE_ADDR，结果部署到Nginx后面后，所有用户都显示成了服务器机房的位置。原因就是后端收到的REMOTE_ADDR是Nginx服务器的内网IP，根本没有拿到真实客户端IP。

1.2 不设置这些头，实际会发生什么

很多人觉得“不设置也能跑，为什么要折腾”。确实，简单的静态页面或接口转发不设置也可以，但一旦涉及下面这几类场景，不设置就会出问题：

• 虚拟主机路由错乱：后端同一台服务器上跑了多个域名，通过Host头来区分站点。Nginx转发时如果默认把Host改成了上游IP，后端不知道你要访问哪个域名，很可能就把默认站点的内容返回给你。
• 用户IP统计失效：所有访问后端的IP都变成Nginx服务器的IP，日志分析、地域统计、频率限制全部失效。
• HTTPS协议判断错误：后端需要区分用户是通过HTTPS还是HTTP访问，用来生成绝对链接（比如支付回调地址）。如果Nginx没有传递原始协议信息，后端就会拿HTTP去生成链接，导致各种奇怪的回调问题。
• 安全策略误判：一部分安全组件会根据IP做黑白名单或风控，拿不到真实IP，这些策略全部形同虚设。

对proxy_set_header的理解，直接决定了你排查此类问题时的方向是否准确。它本质上是一组“身份信息透传指令”，告诉Nginx在转发请求时，如何构造或改写特定请求头。

2. 高频使用的参数逐个拆解：每个头都有它的脾气

2.1 Host参数：后端认定“你在访问谁”

Host请求头是HTTP/1.1协议里的标准头，后端服务常常用它来识别访问的是哪个域名、哪个虚拟主机。在Nginx里，和Host相关的值有几个容易混淆的变量：

最常见的配置是：

nginx复制proxy_set_header Host $host;

这样，后端收到的Host就是用户访问时用的域名（不含端口）。如果你的服务明确需要端口号，比如前端根据端口判断环境，可以改成$http_host。

那什么时候用$proxy_host？比如后端服务