Nginx 反向代理后，真实 IP 为什么会丢？-速维云

为什么会出现“IP 都一样”

很多站点接入 Nginx 反向代理之后，后台日志、风控系统、程序记录里看到的访问 IP 突然都变成了 127.0.0.1、内网地址，或者统一变成某个代理节点的 IP。表面上网站还能访问，但真实访客是谁、访问从哪里来、哪些请求可疑，这些关键信息一下就不准了。后面无论做访问统计、封禁恶意请求、地区识别，还是排查攻击来源，都会跟着出问题。

这类情况本质上不是“用户 IP 消失了”，而是反向代理接手请求后，如果没有把源地址正确透传给后端，后端看到的就只剩下代理层自己。也就是说，请求链路多了一层，但后端没有被正确告知“最初是谁发来的”。

Nginx 反向代理与网络请求链路示意图

先弄清是谁在转发请求

真实 IP 丢失，最常见的场景就是站点前面加了 Nginx、CDN、WAF、负载均衡，甚至不止一层。请求先到前面的代理层，再由代理层转发给后端服务。后端默认只认识直接连过来的那一跳，于是它记录下来的自然是代理地址，而不是用户原始地址。

所以排查第一步不是急着改配置，而是先把链路看清：到底是“用户 → CDN → Nginx → 应用”，还是“用户 → 负载均衡 → Nginx → PHP / Node / Java 应用”。链路不同，应该信任哪个头、在哪一层恢复真实 IP，也会跟着不同。

常见原因一：没传 X-Forwarded-For

最常见的问题，是反向代理时根本没把客户端来源 IP 往后传。Nginx 默认不会替你自动把每个场景都配好，如果没有显式设置，后端应用拿到的就只会是 Nginx 自己的来源地址。

通常会看到的关键头包括 X-Forwarded-For、X-Real-IP。如果站点是标准反向代理场景，Nginx 至少要把客户端地址写进这些头里，再转发给后端应用处理。否则后端程序即使支持读取真实 IP，也没有数据可读。

常见原因二：后端不信代理头

还有一种情况是 Nginx 已经传了头，但后端程序、框架或者 Web 服务器没有正确读取。比如程序只看远端连接 IP，不看 X-Forwarded-For；或者只接受来自受信任代理的头信息，但你没有把当前代理层加入信任名单。

这类问题在 WordPress、Laravel、Django、Express、Spring Boot 里都很常见。前端代理配置看着没错，结果应用层没接住，最后日志和业务逻辑里仍然是一串代理地址。排查时一定要代理层和应用层一起看，别只盯着 Nginx 一边。

常见原因三：多层代理头被覆盖

如果站点前面不止一层代理，真实 IP 还可能在链路中被覆盖。例如 CDN 已经写了一次 X-Forwarded-For，后面的 Nginx 又直接重写，结果把前面的源地址冲掉了。这样后端最终拿到的，还是不完整甚至错误的信息。

多层代理场景里，最怕的不是“没配置”，而是每一层都在“自认为帮你配置”。最后谁覆盖谁、谁追加谁，如果不统一，就会让日志结果乱掉。此时不能只看单点配置，而要检查整条链路里的 header 传递规则。

真实 IP 丢了，会影响哪些事

很多人一开始觉得“能访问就行”，等后面碰到限流、防刷、登录风控、审计追踪，才发现真实 IP 丢失会牵出一串连锁问题。比如用户频繁登录失败，你想封掉攻击源，却发现所有请求都显示成同一个代理地址；又或者程序做地区识别时全部判断错，统计报表也跟着失真。

如果站点本身承接营销投放、表单收集、会员登录、接口调用，这类问题会更明显。因为一旦访问来源识别不准，后续的风控、分析和封禁规则就会跟着失灵。

排查时应该按什么顺序看

比较稳妥的做法，是从外到内一层层看：先确认前面有没有 CDN / WAF / 负载均衡；再看 Nginx 是否正确设置透传头；最后到应用层确认是否正确读取并信任这些头。日志里最好同时打印远端地址和代理头值，这样最容易定位到底卡在哪一层。

如果站点已经上了多层代理、海外访问、跨地域回源，建议把“真实 IP 恢复”当成一项基础配置，不要等业务系统上线后再补。尤其是有登录、支付、接口风控需求的站点，更应该在部署初期就把这一层理顺。对需要稳定托管 Nginx、网站服务和反向代理链路的场景，也可以结合业务需求评估更合适的速维云服务器环境，这样后续排障会轻松很多。