X-Forwarded-For定义
这个定义，以防万一有人浏览这篇文章并看到它，但我认为我们已经准备好了：
X-Forwarded-For: <client>, <proxy1>, <proxy2>
这就是您基本上在每个描述标题的页面上看到的内容。X-Forwarded-For误用如此普遍有什么奇怪的吗？
X-Forwarded-For标头不可信
首先，也是最重要的，您必须始终意识到，由不受您控制的任何代理添加（或看似已添加）的任何 XFF IP 都是完全不可靠的。任何代理都可以按照自己想要的方式添加、删除或修改标头。客户端最初也可以将标头设置为它想要的任何内容，以使恶搞球滚动。例如，如果您向 AWS 负载均衡器2发出此请求……
curl -X POST https://my.load.balanced.domain/login -H "X-Forwarded-For: 1.2.3.4, 11.22.33.44"
...负载均衡器后面的服务器将得到以下信息：
X-Forwarded-For: 1.2.3.4, 11.22.33.44, <actual client IP>
和这个：
curl -X POST https://my.load.balanced.domain/login -H "X-Forwarded-For: oh, hi,,127.0.0.1,,,,"
...会给你这个：
X-Forwarded-For: oh, hi,,127.0.0.1,,,,, <actual client IP>
正如您所看到的，已经存在的所有内容都只是通过，未更改且未经验证。最终的实际 IP 只是附加到已有的 IP 上。
（除了curl'ing和自定义客户端之外，还有至少一个Chrome扩展程序可以让您在浏览器请求中设置XFF标头。但是如何设置标头对我们来说并不重要，唯一重要的是攻击者可以做到。）
总结
具体说明， 参考：The perils of the “real” client IP | adam-p
让我们总结一下我们学到的一些东西、我们获得的智慧以及我们形成的观点：
-
从标头中导出“真实客户端 IP 地址”时
X-Forwarded-For，请使用列表中最右边的 IP。 -
XFF 标头中最左边的 IP 通常被认为是“最接近客户端”和“最真实”，但它很容易被欺骗。不要将其用于任何与安全相关的事情。
-
选择最右边的 XFF IP 时，请确保使用该标头的最后一个实例。
-
使用由反向代理（如
X-Real-IP、True-Client-IP等）设置的特殊“真实客户端 IP”可能会很好，但这取决于 a) 反向代理实际如何设置它，b) 反向代理是否设置它（如果它已经存在）/欺骗，以及 c) 您如何配置反向代理（有时）。 -
任何未由自己反向代理专门设置的标头都不可信。例如，如果您不在 Nginx 或其他始终设置标头的后面，则不得检查标头，因为您将读取欺骗值。
X-Real-IP -
许多速率限制器实现都使用可欺骗的 IP，并且容易受到速率限制器逃逸和内存耗尽攻击。
如果您在代码或基础设施中的任何位置使用“真实客户端 IP”，您需要立即检查如何派生它。
避免说您应该只使用最右边的 XFF IP，而永远不要使用最左边的 IP。但是，说真的，不要使用它。