当请求依次经过CDN、WAF、云负载均衡和API网关时，应用TCP连接的直接对端通常是最后一层网关。因此应用框架读取到负载均衡IP是正常的。真实客户端地址需要从受控代理写入的头部中解析，但绝不能无条件相信用户提交的X-Forwarded-For。
多层代理中的地址变化
| 位置 | 直接连接来源 | 可能写入的信息 |
|---|---|---|
| CDN/WAF | 客户端公网地址 | 清洗并写入客户端IP头 |
| 负载均衡 | CDN或WAF出口 | 追加Forwarded/XFF或代理协议 |
| API网关 | 负载均衡地址 | 再次追加代理链 |
| 应用 | API网关地址 | 按可信代理规则解析 |
为什么X-Forwarded-For可以被伪造
它只是HTTP请求头。客户端可以直接发送任意值。如果第一层受控代理没有删除外部传入值并重新构造，恶意请求就能把伪造地址放在列表左侧。应用若机械取最左项，会污染审计、限流和安全决策。
正确思路是可信代理链
应用先确认直接连接来源是否属于可信API网关。然后从代理链最右侧开始，跳过由组织明确控制的代理地址，取第一个不可信地址作为候选客户端。具体实现应使用框架的可信代理配置，不要手写简单字符串分割。
Forwarded与XFF有什么区别
Forwarded是标准化头，可包含for、proto和host；X-Forwarded-For是广泛使用的事实标准。现实环境可能同时存在。应选择基础设施明确维护的一套来源，规定覆盖与追加规则，避免两个头互相冲突。
X-Real-IP一定更安全吗
不一定。任何头的可靠性都取决于受控代理是否清洗外部输入并重新写入。若应用可被绕过CDN直接访问，攻击者还可以直接连接Origin并伪造头。应限制Origin只接受来自可信代理网络的连接。
IPv6和端口格式容易踩什么坑
标准Forwarded头中的IPv6可能带引号和方括号，XFF列表也可能包含IPv4、IPv6或无效文本。解析器应使用成熟库并验证地址格式。不要将主机和端口混为一个IP字符串，也不要因为日志系统不支持IPv6而截断。
Proxy Protocol什么时候使用
在TCP负载均衡场景中，Proxy Protocol可在连接层传递源地址，但发送端和接收端必须同时启用。错误地把Proxy Protocol流量发给普通HTTP服务会导致请求损坏。它同样依赖可信网络，不能从公网任意接受。
真实IP用于限流有哪些风险
家庭、公司、移动网络和CGNAT会让多个用户共享地址；移动切网又会频繁变化。IP限流适合做一层风险控制，不应成为唯一身份。对登录、支付或敏感API，应结合账号、设备、Token、行为和业务键。
CGNAT与共享公网IP可参考公网IP共享与CGNAT判断。
日志应同时记录哪些字段
- 应用看到的直接对端地址；
- 原始代理头的受控摘要；
- 解析后的候选客户端地址；
- 命中的可信代理规则版本；
- 请求ID、网关与服务实例；
- 解析异常或头冲突标记。
IP地址可能属于个人数据，应设置访问权限、使用目的和保留期限。
配置变更怎样验证
- 列出CDN、WAF、负载均衡和网关顺序；
- 明确每层是覆盖还是追加头；
- 限制Origin仅接受可信入口；
- 测试正常IPv4、IPv6和多层代理；
- 直接发送伪造XFF，确认被清洗；
- 绕过一层代理，确认应用拒绝或不信任；
- 核对日志、限流和审计结果。
结论
多层代理后的真实客户端IP不是“取XFF最左边”这么简单。只有建立可信代理列表、入口清洗规则和从右向左的解析逻辑，客户端地址才可用于审计和辅助风控。
