s
我们在压测请求报文里面带了这个"x-forward-for":"10.24.51.132"这个字段，所以我们所有的压测请求穿透到应用系统的时候，应用系统上采集到的请求ip都是这个"10.24.51.132"，但是这个不代表所有的请求是来自同一个ip地址，实际上的压测请求还是来自40台agent服务器
HTTP 请求头中的 X-Forwarded-For（XFF）
https://blog.csdn.net/yizhenn/article/details/60955599
在Java代码实践中，有两种方式可以从HTTP请求中获得请求者的IP地址。一个是从Remote Address中获得，另一个是从X-Forward-For中获得，但他们的安全性和使用场景各有不同。一旦用错，就可能为系统造成漏洞。因此，需要开发者对这两个参数深入的理解。
Remote Address代表的是当前HTTP请求的远程地址，即HTTP请求的源地址。HTTP协议在三次握手时使用的就是这个Remote Address地址，在发送响应报文时也是使用这个Remote Address地址。因此，如果请求者伪造Remote Address地址，他将无法收到HTTP的响应报文，此时伪造没有任何意义。这也就使得Remote Address默认具有防篡改的功能。
在一些大型网站中，来自用户的HTTP请求会经过反向代理服务器的转发，此时，服务器收到的Remote Address地址就是反向代理服务器的地址。在这样的情况下，用户的真实IP地址将被丢失，因此有了HTTP扩展头部X-Forward-For。当反向代理服务器转发用户的HTTP请求时，需要将用户的真实IP地址写入到X-Forward-For中，以便后端服务能够使用。由于X-Forward-For是可修改的，所以X-Forward-For中的地址在某种程度上不可信。
所以，在进行与安全有关的操作时，只能通过Remote Address获取用户的IP地址，不能相信任何请求头。
当然，在使用nginx等反向代理服务器的时候，是必须使用X-Forward-For来获取用户IP地址的（此时Remote Address是nginx的地址），因为此时X-Forward-For中的地址是由nginx写入的，而nginx是可信任的。不过此时要注意，要禁止web对外提供服务。
nginx 反向代理与 Real-IP 和 X-Forwarded-For
https://blog.csdn.net/broadview2006/article/details/54570943
总结 1.通过“proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for” 把从真实客户端IP和反向代理IP通过逗号分隔，添加到请求头中； <br> 2.可以在第一个反向代理上配置“proxy_set_header X-Real-IP $remote_addr” 获取真实客户端IP； <br> 3.配合realip模块从X-Forwarded-For也可以获取到真实客户端IP。<br> 在整个反向代理链条的第一个反向代理可以不配置“proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for”，<br> 否则客户端可以伪造X-Forwarded-For从而伪造客户端真实IP，<br> 如果服务端使用X-Forwarded-For第一个IP作为真实客户端IP，则就出问题了。<br> 如果通过配置X-Real-IP请求头或者配合realip模块也不会出现该问题。<br> 如果自己解析X-Forwarded-For的话，记得使用realip算法解析，而不是取第一个。<br> 当我们进行限流时一定注意限制的是真实客户端IP，而不是反向代理IP，我遇到过很多同事在这块出问题的。
end