阿里云获取真实IP全攻略：代理、SLB后端一招搞定

在云上部署业务之后，很多开发者和运维人员都会遇到一个看似简单、实际上非常关键的问题：客户端的真实IP到底该怎么获取。尤其是在阿里云环境中，网站、接口服务、微服务网关、WAF、防火墙、Nginx 反向代理、SLB 负载均衡、容器网关等层层叠加之后，请求到达后端时，应用程序看到的往往已经不是用户原始地址，而是代理节点地址、内网地址，甚至是本机回环地址。此时，如果没有正确处理，日志分析、风控策略、访问限制、地域识别、审计追踪都会失真。

所以，围绕阿里云 获取真实ip这个主题，真正要解决的并不是“某一行代码怎么写”，而是要建立一整套清晰的链路认知：请求从哪里来，经过了哪些代理，哪一层会改写源地址，哪一层会通过请求头或协议传递原始信息，后端又该如何可信地读取这些信息。掌握了这套方法，不管是传统 ECS 上的 Nginx+Tomcat，还是阿里云 SLB 后端集群，甚至是多层反向代理架构，都能一招搞定。

为什么“真实IP”在阿里云场景里容易丢失

先理解问题，才能避免误判。在最原始的互联网通信中，如果客户端直接访问服务器，那么服务器通过 TCP 连接就能拿到对端源地址，这个地址通常就是真实客户端 IP。然而当业务上线到阿里云后，为了高可用、高并发、安全防护，架构往往会变成这样：

• 用户 → CDN/WAF → SLB → Nginx → 应用服务器
• 用户 → 公网 SLB → ECS 反向代理 → 内部服务
• 用户 → API 网关 → 服务网格/Ingress → 容器应用

在这类链路中，后端直接建立连接的对象往往不是最终用户，而是上游代理节点。于是应用里常见的 remote_addr、getRemoteAddr()、Socket 对端地址等字段，看到的就成了代理服务器 IP。也就是说，不是后端“不会获取”，而是它获取到的是“当前连接发起方”，并非“最初用户”。这就是为什么很多人刚接触阿里云 获取真实ip时会觉得奇怪：明明网站有人访问，为什么日志里全是 SLB 内网地址。

本质上，真实IP的传递有两种主流方式：一种是通过 HTTP 头部传递，比如 X-Forwarded-For、X-Real-IP；另一种是通过四层协议扩展传递，例如 Proxy Protocol。阿里云不同产品、不同监听协议、不同代理层级，对真实来源地址的保留方式并不完全一样，因此不能用一个固定答案套所有场景。

先分清场景：四层转发和七层代理不是一回事

在实际部署中，很多问题都出在“没有区分四层和七层”。这一步不弄清楚，后面的配置很容易南辕北辙。

四层转发主要工作在传输层，典型是 TCP/UDP 转发。它关注的是连接本身，不解析 HTTP 语义。对于这类场景，后端要不要能拿到真实来源地址，通常取决于负载均衡是否保留源地址，或者是否开启 Proxy Protocol 之类的透传机制。

七层代理则工作在应用层，比如 HTTP/HTTPS 监听。代理服务器会终止连接、解析请求，再向后端重新发起新连接。此时后端连接对端自然是代理服务器，因此想要知道用户原始地址，一般需要从 HTTP 请求头里读取，例如 X-Forwarded-For。

换句话说，讨论阿里云 获取真实ip时，第一件事不是急着改代码，而是问自己三个问题：

1. 你的入口是 SLB、ALB、Nginx、WAF 还是 CDN？
2. 你的监听协议是 TCP、UDP、HTTP 还是 HTTPS？
3. 你的应用最终依赖请求头取值，还是依赖底层连接源地址？

这三个问题一旦回答清楚，方案就基本明确了。

阿里云 HTTP/HTTPS 场景：优先看 X-Forwarded-For

如果你的服务前面挂的是阿里云七层负载均衡，或者经过了 Nginx 这类反向代理，那么最常见、也最实用的真实IP获取方式，就是读取 X-Forwarded-For 请求头。

这个头部的意义很直白：每经过一层可信代理，就把前一跳识别到的客户端地址追加进去。于是一个请求经过多层代理后，X-Forwarded-For 可能会变成一个 IP 列表，例如：

203.0.113.10, 10.10.2.15, 172.16.1.8

其中最左侧通常代表最早的客户端地址，后面的则是各级代理逐步追加的结果。很多文章讲到这里就结束了，但真正上线时不能这么简单理解。因为你不能无条件相信客户端传来的所有头部。如果最外层没有做覆盖或清洗，恶意用户完全可以手动伪造 X-Forwarded-For，让你的应用误以为请求来自另一个地址。

因此，正确方式不是“见到 X-Forwarded-For 就取第一个”，而是要结合可信代理链来判断。通常推荐思路是：

• 如果前面是你自己控制的阿里云 SLB/Nginx/WAF，确认这些代理会规范地添加或改写头部。
• 应用只信任来自已知代理节点的转发头，不信任任意公网来源自带的头。
• 如果有多层代理，明确哪一层负责写入标准头，哪一层负责透传。

在 Nginx 中，常见做法是配合 real_ip_header 和 set_real_ip_from 使用，让 Nginx 只在请求来自可信代理网段时，才把指定头部中的地址还原为客户端真实IP。这样，后续日志、限流模块、上游应用看到的就是经过校验后的地址，而不是任意用户伪造的值。

阿里云 SLB 后端如何获取真实IP

谈到阿里云 获取真实ip，最典型的高频场景就是：业务前面挂了阿里云 SLB，后端 ECS 或容器里的应用拿到的却是负载均衡节点地址。那么，SLB 后端到底该怎么处理？答案要分协议看。

如果是 HTTP/HTTPS 监听，SLB 一般会通过标准请求头把客户端真实地址传给后端。此时，你的后端 Web 服务器或应用框架应该优先从这些头里取值，例如：

• X-Forwarded-For：最常见，通常用于记录代理链
• X-Real-IP：一些代理会额外设置，表示客户端真实地址
• 应用框架提供的“已解析客户端IP”能力：前提是你配置了可信代理

如果是 TCP 监听，情况就不同了。因为这类监听不解析 HTTP，自然也不会凭空产生 HTTP 头部。此时想在后端获取真实IP，就要看是否启用了源地址保留能力，或者使用 Proxy Protocol 将源地址信息附带到连接初始数据中。后端程序、Nginx、HAProxy、Envoy 等组件需要支持解析这种协议，否则即便前端传了，后端也无法识别。

很多运维事故就发生在这里：SLB 侧启用了某种真实源地址透传机制，但后端服务没适配，结果应用收到“奇怪的报文头”，甚至握手失败、健康检查异常。反过来，后端明明按 Proxy Protocol 解析，但前端并未开启，服务也会报错。因此，SLB 后端获取真实IP从来不是单边配置，而是前后端协同。

案例一：ECS 上 Nginx + Java 应用，日志里全是内网IP

来看一个非常典型的案例。某电商后台系统部署在阿里云上，入口是公网 SLB，后端两台 ECS 上运行 Nginx 和 Java 应用。上线后，开发团队发现风控日志里几乎所有访问都来自同一个 10.x 内网地址，导致登录异常检测完全失效。

排查后发现，Java 代码直接调用了 request.getRemoteAddr()。在有七层代理的情况下，这个方法返回的是最近一层代理地址，也就是 Nginx 或负载均衡来的连接地址，而不是用户真实地址。

最终处理方案分成两步：

1. Nginx 明确配置可信上游，只信任来自 SLB 网段的真实IP头，并将还原后的地址写入访问日志。
2. Java 应用层不再直接盲信客户端自带头部，而是从 Nginx 统一清洗后的头部读取，或直接使用已被 Nginx 还原后的转发结果。

改完后，日志中既能看到真实公网客户端地址，又保留了完整代理链，风控规则恢复正常。这个案例说明，在阿里云环境里做获取真实ip，最怕的是“应用自己随便解析请求头”，而最稳妥的是“由边缘代理统一收口处理”。

案例二：TCP 业务挂 SLB，应用根本拿不到请求头

再看一个更容易踩坑的例子。某游戏登录服务采用私有 TCP 协议，前面部署了阿里云负载均衡。开发同学照搬 Web 场景思路，试图在服务端代码里读取 X-Forwarded-For，结果当然一无所获，因为这是纯 TCP 服务，根本没有 HTTP 头。

后来运维团队调整思路，确认该服务需要的不是“从请求头取 IP”，而是“让后端感知连接的原始来源地址”。在这种情况下，就应该考虑四层透传能力或者 Proxy Protocol，并确保服务端接入层支持对应解析。经过改造后，登录服务终于能够准确识别玩家来源地址，用于异地登录告警和区域接入优化。

这个案例说明，阿里云 获取真实ip不能照搬教程，必须从协议层理解问题。HTTP 和 TCP 是两套完全不同的思路。

Nginx 中获取真实IP的核心思路

在阿里云上，Nginx 几乎是最常见的中间层，因此掌握它的处理方法非常重要。这里不堆大段配置，只讲核心原则。

第一，明确真实IP来自哪个头。多数七层代理会使用 X-Forwarded-For，部分场景也会设置 X-Real-IP。你要选定一个可信来源作为标准，不要多个字段混着用，避免口径不一致。

第二，只信任来自指定代理节点的请求头。也就是说，必须通过可信网段或代理地址白名单来限制“谁有资格告诉我真实IP”。否则客户端伪造头部就能骗过系统。

第三，把处理结果沉淀到日志格式中。很多团队虽然成功还原了客户端真实地址，但日志还是记录默认的 remote_addr，导致排障时信息混乱。正确做法是让访问日志同时记录：

• 还原后的客户端地址
• 连接实际对端地址
• 完整的 X-Forwarded-For 链

这样做的好处是，一旦线上出现访问异常、恶意刷接口、代理链配置错误，你可以立刻回溯究竟是哪一层出了问题。

应用层如何安全读取真实IP

很多开发者更关心代码层：后端程序到底怎么拿真实IP？原则其实很简单：不要直接相信任意请求头，要基于可信代理策略读取。

以 Java、PHP、Python、Go 这类常见 Web 应用为例，通常都可以按以下顺序设计获取逻辑：

1. 先判断当前请求是否来自可信反向代理。
2. 如果是，再解析约定好的真实IP头。
3. 如果头里有多个地址，按既定规则取最左侧真实客户端或按可信链回溯。
4. 如果不是来自可信代理，则直接使用连接对端地址。

这样做的好处在于兼容直连和代理两种模式，也能有效避免伪造头部带来的安全风险。尤其是在阿里云混合架构里，测试环境可能是直连，生产环境可能前面挂了 SLB、WAF、Nginx，如果没有这套兼容逻辑，环境一切换就容易出问题。

为什么有时拿到的“真实IP”还是不准确

现实中，很多人明明配置了代理头，还是会抱怨获取到的地址不对。这通常不是阿里云有问题，而是链路中某一层没有处理好。常见原因包括：

• 前面经过了 CDN 或 WAF，但后端只认 SLB 的头部，没有识别完整链路。
• Nginx 配置了真实IP头，却没有设置可信代理来源，导致无法正确还原。
• 应用直接取 X-Forwarded-For 第一个值，被恶意请求伪造。
• 多层代理都在重复改写头部，最终口径不统一。
• TCP 服务误用了 HTTP 获取方式，或者 Proxy Protocol 前后端配置不一致。

因此，想做好阿里云 获取真实ip，一定要建立“链路排查意识”。最有效的方法不是凭感觉改配置，而是逐层打印和比对：

1. 客户端出口 IP 是什么；
2. SLB 接收到的源地址是什么；
3. Nginx 入口看到的连接地址是什么；
4. 请求头中的 X-Forwarded-For 是什么；
5. 应用层最终使用的客户端IP是什么。

一旦这五步串起来，问题基本无所遁形。

真实IP不仅是日志问题，更关系到安全与业务策略

不少团队起初重视阿里云 获取真实ip，只是为了“日志看着顺眼”。其实它的价值远不止如此。真实IP一旦获取错误，会直接影响以下能力：

• 安全审计：无法准确定位恶意来源，封禁失效。
• 风控策略：同IP频控、异地登录识别、注册限制都会失真。
• 运营分析：地域分布、访问来源统计不准确。
• 合规追踪：出现投诉或攻击事件时，追溯链条断裂。
• 灰度与路由：按地区、线路、用户源地址做调度会出错。

尤其是面向公网的接口服务，一旦真实IP处理不当，最直接的后果就是限流规则误杀正常用户，或者攻击请求绕过风控。表面看只是“IP没取对”，本质上却是整套安全策略建立在错误基础上。

一套适用于大多数阿里云场景的实战建议

如果你不想在各种文档和配置之间来回试错，可以直接参考下面这套更稳妥的实践思路：

1. 先画出完整请求链路，明确经过了哪些代理层。
2. 区分是 HTTP/HTTPS 还是 TCP/UDP，选择请求头方案还是协议透传方案。
3. 在最靠近业务入口的可信代理层统一处理真实IP，不要让每个应用各自“自由发挥”。
4. 配置可信代理白名单，只信任阿里云负载均衡、WAF、网关等已知节点传来的头部。
5. 日志中同时记录真实IP、代理链、连接对端地址，便于审计与排障。
6. 应用层封装统一的客户端IP获取方法，避免不同项目使用不同规则。
7. 上线前做伪造头部测试、多层代理测试、健康检查测试，验证结果是否符合预期。

这样做看起来比“写一行代码取 X-Forwarded-For”复杂一些，但长期来看最省心。因为真正稳定的系统，从来不是依赖某个技巧，而是依赖清晰的一致性策略。

结语：把“获取真实IP”当成链路治理，而不是单点配置

总结来看，阿里云 获取真实ip并不是一个单纯的开发小技巧，而是云上架构中非常基础、也非常容易被忽视的一环。只要业务前面存在代理、网关、SLB 或安全层，后端拿不到原始客户端地址就是正常现象。关键不在于“为什么变了”，而在于你是否知道该由哪一层、通过什么机制、以什么可信规则把真实IP还原出来。

对于 HTTP/HTTPS 业务，核心是正确使用 X-Forwarded-For 等头部，并建立可信代理机制；对于 TCP 业务，核心是弄清是否需要源地址保留或 Proxy Protocol；对于阿里云 SLB 后端场景，核心则是前后端配置协同，避免只开一端或误用协议。只要这几点想明白，不管是 Nginx、应用程序、还是负载均衡后端节点，都能稳定、准确地识别客户端真实来源。

如果你正在排查日志里全是内网IP、风控策略不生效、SLB 后端无法识别用户来源等问题，不妨回到本文这条主线：先看链路，再分协议，再定可信来源，最后统一落地。当你把这套方法建立起来，代理再多、架构再复杂，真实IP也不再是难题。