客户端 IP 伪造漏洞分析与修复实践
客户端 IP 是日志审计、接口限流、风控策略、黑白名单等安全能力的重要基础，但很多项目在获取客户端 IP 时都会直接信任 `X-Forwarded-For` 请求头，导致攻击者可以通过伪造请求头绕过 IP 限流、规避黑名单、污染审计日志，甚至影响安全事件溯源。本文将从 `X-Forwarded-For` 的工作原理出发，分析客户端 IP 伪造漏洞的成因及风险，并结合 Nginx 与 Spring Boot 的实际部署场景，介绍如何构建可信的 IP 获取链路，避免因错误使用代理请求头而引入安全隐患。
前言
在业务开发中，获取客户端 IP 是一个非常常见的需求。
登录日志、操作审计、接口限流、黑白名单、异常登录检测、IP 归属地分析……很多功能最终都会依赖客户端 IP。因此，大多数项目里都会有一个类似 IpUtil.getIpAddr() 的工具方法，业务代码需要 IP 时直接调用。
这类工具通常已经存在很多年，平时也很少有人专门去关注它。
但问题恰恰可能出在这里。
不少项目为了兼容 Nginx、SLB、CDN 等代理环境，会优先读取 X-Forwarded-For，拿不到时再回退到 request.getRemoteAddr()。从功能上看，这套逻辑完全正常，但如果没有建立可信代理边界，就可能留下一个很容易被忽略的问题：
客户端可以主动构造 X-Forwarded-For。
这意味着，如果应用无条件相信这个请求头，那么攻击者甚至不需要突破任何权限，只需要修改一个 HTTP Header，就有机会伪造自己的来源 IP。
而一旦这个 IP 又被用于限流、黑名单或者风控，问题就不只是“日志记错了一个 IP”这么简单了。
一个很常见的实现
很多项目中都能看到类似代码：
String ip = request.getHeader("X-Forwarded-For");
if (ip == null) {
ip = request.getRemoteAddr();
}
if (ip.contains(",")) {
ip = ip.substring(0, ip.indexOf(","));
}逻辑很好理解：
- 优先获取
X-Forwarded-For。 - 获取不到就使用
RemoteAddr。 - 如果经过多级代理，就取第一个 IP。
甚至不少网上的工具类和开源项目中，也能找到类似实现。
问题不在于读取 X-Forwarded-For 本身，而在于：
这段代码默认相信了请求头里的内容。
而在安全场景下，“这个 Header 是谁写进去的”，往往比“这个 Header 叫什么”更加重要。
为什么需要 X-Forwarded-For？
先看一个常见的生产环境链路：
Client
│
▼
CDN
│
▼
SLB
│
▼
Nginx
│
▼
Spring Boot对于 Spring Boot 来说，真正和它建立 TCP 连接的通常不是最终用户，而是上一层代理，比如 Nginx。
因此：
request.getRemoteAddr()得到的实际上可能是：
Nginx IP而不是用户真正的出口 IP。
这也是 X-Forwarded-For 存在的意义。
代理服务器在转发请求时，可以把客户端地址记录到请求头中。例如：
X-Forwarded-For: 1.2.3.4经过多级代理之后，则可能变成：
X-Forwarded-For: 1.2.3.4, 100.10.0.1, 172.20.0.10它实际上描述的是一条代理链。
也正因为如此，很多项目逐渐形成了一个简单的处理习惯：
有
X-Forwarded-For就取第一个 IP。
在代理链完全可信、入口配置正确的情况下，这样做可能得到预期结果。但如果应用允许客户端直接访问，或者入口代理没有正确处理客户端自带的转发头，这个逻辑就存在风险。
问题就在于：Header 是可以自己写的
X-Forwarded-For 并不是某种由 HTTP 协议强制保护的字段。
从客户端角度看，它和其他普通请求头并没有本质区别。
攻击者完全可以主动发送：
GET /api/login HTTP/1.1
Host: example.com
X-Forwarded-For: 8.8.8.8也可以改成：
X-Forwarded-For: 114.114.114.114甚至：
X-Forwarded-For: 127.0.0.1如果应用代码无条件执行：
request.getHeader("X-Forwarded-For")然后直接把这个值认定为客户端 IP，那么最终日志里看到的可能是：
114.114.114.114但真正和入口服务器建立连接的客户端可能完全来自另一个地址。
本质上，这不是 X-Forwarded-For 有漏洞，而是系统出现了一个信任边界错误：
客户端提供的数据
↓
应用直接相信
↓
作为安全策略依据真正危险的地方就在最后一步。
如果这个 IP 只是用于普通访问统计，影响可能有限；但如果继续被限流、风控、审计等系统使用，问题就会被进一步放大。
一个伪造的 IP，可能影响整条安全链路
最直观的就是 IP 限流。
假设登录接口限制：
单 IP 每分钟最多尝试 10 次攻击者不断修改：
X-Forwarded-For: 1.1.1.1下一批请求：
X-Forwarded-For: 2.2.2.2再下一批：
X-Forwarded-For: 3.3.3.3如果限流 Key 直接来源于这个请求头，系统看到的就是三个不同来源。
原本设计好的 IP 限流，也就失去了意义。
黑名单也是一样。
假设系统已经将某个恶意来源加入 Redis 黑名单：
BLOCK_IP: xxx.xxx.xxx.xxx如果后续请求可以通过修改 X-Forwarded-For 改变系统识别出的 IP，那么黑名单机制同样可能被绕过。
更麻烦的是，这类问题通常不会只影响一个功能。
例如系统根据 IP 判断异地登录、异常访问地区：
上海
↓
北京
↓
广州看起来像用户在多个地区频繁切换，但实际上这些地址可能全部来自伪造的 Header。
再比如审计日志记录：
管理员登录
IP：192.168.x.x一旦 IP 来源本身不可信，这条日志在真正发生安全事件时就很难再承担溯源作用。
包括 IP 归属地、用户地域分布、异常访问分析等依赖 IP 的数据，也会一起受到污染。
所以这类问题真正值得关注的地方，不是“有人能把日志里的 IP 改掉”，而是：
一个不可信的数据源，被当成可信数据进入了后续安全体系。
为什么这种问题很容易被忽略？
因为在正常的生产链路里，X-Forwarded-For 确实通常是由代理服务器处理的。
开发人员看到的往往是：
Client
↓
Nginx
↓
Spring Boot于是很自然地形成一个认知：
X-Forwarded-For = Nginx 传过来的客户端 IP但这里少了一个非常重要的前提：
必须能够确认请求确实来自可信代理，并且代理正确处理了这个 Header。
否则：
X-Forwarded-For本质上依然只是客户端可控输入。
所以判断一个 IP Header 是否可信，不能只看 Header 名字，而应该看：
是谁把这个 Header 交给我的？这才是整个问题的关键。
正确思路：先建立可信代理边界
解决这个问题的核心原则其实并不复杂：
不要信任客户端声明的 IP，只信任经过明确配置的可信代理链。
假设生产环境是：
Client
│
▼
CDN
│
▼
SLB
│
▼
Nginx
│
▼
Spring BootSpring Boot 首先应该关心的是：
request.getRemoteAddr()因为它代表的是当前 TCP 连接的直接来源。
接下来再判断这个来源是不是我们明确知道的可信代理。
逻辑可以抽象成：
获取 RemoteAddr
│
▼
是否属于可信代理？
│ │
否 是
│ │
▼ ▼
直接使用 解析 Forwarded Header
RemoteAddr │
▼
根据可信代理链
确定客户端 IP这样一来，即使有人直接访问应用并发送：
X-Forwarded-For: 8.8.8.8只要他的 RemoteAddr 不属于可信代理范围，应用就不会相信这个 Header。
这才真正建立起了安全边界。
不要简单理解成“永远取第一个 IP”
这里还有一个经常被忽略的细节。
很多文章会直接告诉你：
X-Forwarded-For第一个 IP 就是真实客户端 IP。
这个结论并不严谨。
假设客户端自己先发送：
X-Forwarded-For: 8.8.8.8而某一层代理只是简单追加：
$proxy_add_x_forwarded_for最终可能得到：
X-Forwarded-For: 8.8.8.8, <实际客户端IP>, <代理IP>此时如果应用仍然无脑取第一个：
8.8.8.8伪造依然成立。
因此真正可靠的思路不是：
永远取最左边而是根据自己的网络拓扑建立可信代理列表，从连接的直接来源开始验证代理链，只信任自己能够确认的部分。
换句话说：
决定 IP 是否可信的不是它在字符串中的位置，而是它所在的代理链是否可信。
Nginx 配置同样重要
只修改 Java 工具类还不够。
客户端 IP 是从网络入口一层层传递到应用的，所以每一层代理都属于信任链的一部分。
常见的 Nginx 配置例如：
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;但这里也不能机械地认为“配置了这两行就安全了”。
如果 Nginx 前面还有 CDN、SLB 或其他网关，就需要明确：
- 哪一层负责识别真实客户端 IP；
- 哪些上游代理是可信的；
- 客户端自己传入的 Header 如何处理；
- 每一层是覆盖 Header，还是追加 Header；
- 应用最终应该信任哪一段代理链。
例如：
Client
↓
CDN
↓
SLB
↓
Nginx
↓
Application真正需要建立的是：
不可信区域 可信基础设施
──────────┬────────────────────
Client │ CDN → SLB → Nginx → App
──────────┴────────────────────
↑
信任边界一旦这条边界明确了，后面的处理逻辑才有依据。
Java 层应该怎么做？
Java 应用层不应该自己“猜”哪个 Header 更可靠，而应该按照已经确定的网络拓扑处理。
整体原则可以归纳为：
- 默认以
request.getRemoteAddr()作为直接连接来源； - 维护明确的可信代理地址或网段；
- 只有
RemoteAddr属于可信代理时，才解析X-Forwarded-For、X-Real-IP或标准ForwardedHeader； - 根据实际代理拓扑验证转发链，而不是无条件取第一个值；
- 对 IP 格式进行严格校验，忽略空值、
unknown和非法内容； - 是否允许私网、回环等地址，应根据实际网络架构判断，而不是简单一刀切；
- 应用入口尽量只允许可信代理访问，避免客户端绕过网关直接访问后端；
- 将 IP 获取逻辑统一封装，避免不同业务模块各自实现一套规则。
最后一点其实非常重要。
如果登录限流自己解析一次：
X-Forwarded-For操作日志又解析一次：
X-Real-IP风控模块再实现另一套规则，那么即使某一处修好了，整个系统依然可能存在不一致。
更合理的方式是：
HTTP Request
│
▼
统一客户端 IP 解析组件
│
├── 登录日志
├── 操作审计
├── Sentinel / Redis 限流
├── 黑白名单
├── 风控系统
└── IP 归属地所有依赖客户端 IP 的业务，都使用同一个经过验证的结果。
这其实不是一个 Header 的问题
最开始排查这类问题时，很容易把注意力集中在：
X-Forwarded-For 到底该怎么取？但真正理解之后会发现，这其实不是一个 Java 工具类的问题，甚至也不只是 Nginx 配置的问题。
它本质上是一个信任边界问题。
X-Forwarded-For 本身没有错，request.getRemoteAddr() 也不是万能答案。真正重要的是系统必须知道：
请求从哪里进入？
经过了哪些代理？
哪些代理是我控制的？
哪一段数据是客户端可以修改的？
从哪一层开始，我才愿意相信这个 IP？这些问题没有搞清楚之前，再完善的 IpUtil 也只能是在字符串层面做处理。
总结
客户端 IP 看起来只是一个很普通的基础字段，但一旦它被用于限流、黑名单、登录保护、风控和审计，它实际上就已经成为了安全体系的一部分。
如果应用直接相信客户端可控的 X-Forwarded-For，攻击者就有机会通过修改请求头伪造来源 IP，进一步影响限流、黑名单、风控判断以及安全审计。
真正可靠的方案不是寻找一个“绝对真实的 Header”，而是建立完整的可信代理模型：
客户端输入默认不可信，代理身份需要验证，转发链需要按照实际网络拓扑解析，应用只能信任自己能够确认的那一部分数据。
所以以后再看到这样的代码：
String ip = request.getHeader("X-Forwarded-For");真正应该问的可能不是：
这个 Header 里是什么？
而是：
我凭什么相信它？
这个问题，才是客户端 IP 获取逻辑里真正需要解决的问题。