某云负载均衡真实IP的问题，我们这边已经遇到过两次了。而且每次和售后沟通的时候都大费周折，主要是要给售后说明白目前文档的获取真实IP是有问题的，他们觉得文档上说明的肯定没问题，售后要是不明白，他们不会给LB部门上报，这个事就没法推进。 我们这边的简单的网络架构设这样的。 DNS->负载均衡->web机组

按照文档说明获取客户端真实IP

七层负载均衡（HTTP或HTTPS协议）服务需要对应用服务器进行配置，然后使用X-Forwarded-For的方式获取客户端的真实源IP地址。真实的客户端源IP存放在HTTP头部的X-Forwarded-For字段，格式如下：

X-Forwarded-For: 用户真实IP, 代理服务器1-IP， 代理服务器2-IP，...

当使用此方式获取客户端真实IP时，获取的第一个地址就是客户端真实IP。 我们第一版的获取IP就是按照文档的要求这么写的。

被伪造IP攻击了

某一天，网站接口不停被打，一看攻击IP地址都是一样的，首先想到的是封IP，封了之后还是被打，真实服了，以为代码有问题，检查很多遍确定不是代码的问题，发现攻击IP不停变，又想到会不会购买什么动态IP的服务，user-agent是固定，而且IP地址是按数字累加的，比如刚开始是1.1.1.1，后来是1.1.1.2，再后来1.1.1.3，而且X-Forwarded-For这个头，比正常访问多了一层IP。 然后仔细分析了一下，首先觉得X-Forwarded-For获取IP的方式是有漏铜的，因为所有的请求头都是可以在客户端伪造的，所以我们测试了一下，

curl https://www.aaa.com -H"X-Forwarded-For:1.1.1.1"

通过这种方式，确实拿到了错误的真实ip。

真实IP只有负载均衡知道，因为建立连接的时候可以通过remote_addr拿到真实的IP，只有这种是可信的，如果这个IP错误的话，就无法三次握手建立连接。 没办法，提工单找售后，答复只这样的 您好，目前七层监听都是基于X-Forwarded-For 来获取客户端真实ip 信息的，或者您可以考虑下使用slb 四层监听。 觉得这样简单的东西肯定有啊，一个公有云怎么会没有真实IP。自己在上游服务抓包观察了一下，发现有一个这样的头 RemoteIp，我发现我不管怎么伪造X-Forwarded-For，RemoteIp都是正确的IP。然后找售后确定一下我们的猜测，果然是这个。 您好，RemoteIp也是真实ip，是LB防止 x_forwarded_for 伪造。 改完代码，一切顺利

IP地址又错了

IP地址好几年没出问题了，上个月有用户反馈，IP地址错了，我们网站按照要求，评论需要展示所在地理位置，我TM在苏州啊，怎么给我整到西安去了，没去过啊。 没办法，只能去提工单了。 然后售后说是我们不能使用RemoteIp，应该按照文档说明使用 x_forwarded_for，为了说明 x_forwarded_for 没问题，给我做了各种实验，x_forwarded_for 这个问题从周五下午一直给售后扳扯到周六，说不通了，还贴出了几年前的咨询工单，最后售后大哥终于说了一句，我跟LB部门反馈一下。 大概过了半个小时就有结果了，结果是因为我们开了waf防火墙。售后给的答复。

1、Client -- WAF -- LB -- 上游服务 这种架构 ，那么就得取  X-Real-IP  或X-True-IP 字段获取客户端真实IP。
2、Client  -- LB -- 上游服务 这种架构 ，那么就得取 RemoteIp 获取客户端真实IP。

然后改了一下代码，先检查头里面有没有X-True-IP，如果有就使用X-True-IP，如果没有就使用RemoteIp。

标签：