我在代理/负载平衡器后面有一个网络服务器集群。该代理包含我的 SSL 证书并将解密的流量交给 Web 服务器，并在此过程中将“x-forwarded-for” header 添加到 Web 应用程序接收的 HTTP header 中。此应用程序在过去十年中看到了 数百万 个 IP 地址，但今天发生了一些奇怪的事情。
我第一次看到包含第二个地址的 x-forwarded-for 到达应用程序 [地址已更改]:
x-forwarded-for: 62.211.19.218, 177.168.159.85
这表明流量来自代理，我知道这对于 x-f-f 来说是正常的。我原以为使用 https 作为协议(protocol)这是不可能的(或者至少不太可能)。
谁能解释一下这是怎么回事？
最佳答案
根据 RFC 7239 ，此 HTTP header 指定为
X-Forwarded-For: client, proxy1, proxy2, ...
其中 client 是原始客户端的 IP，然后每个代理在列表末尾添加它收到请求的 IP。在上面的示例中，您会在网络服务器中看到 proxy3 的 IP，而 proxy2 是连接到 proxy3 的 IP。
由于任何人都可以在此 header 中放入任何内容，因此您应该只接受来自已知来源的内容，例如您自己的反向代理或已知合法代理的白名单。例如 Apache 有 mod_rpaf，它透明地将客户端 IP 地址更改为此 header 中提供的地址，但前提是从已知代理服务器的 IP 接收到请求。
在公司网络上，您可以轻松地对 HTTPS 流量进行透明代理，而不会引起普通用户的注意。只需创建您自己的证书颁发机构，例如使用 Windows 组策略在所有公司工作站上安装并信任此 CA。然后将所有 HTTPS 连接重定向到您的代理，代理将为所有访问过的域动态生成证书。这是正在发生的事情，您甚至可以使用这种方法购买企业硬件代理。
所以总结一下您可以在 X-Forwarded-For header 中看到多个 IP 的原因:
- 如上所述的透明 HTTPS 代理
- 无论出于何种原因，请求者自己(浏览器、wget、脚本)添加了 header ，例如隐藏自己的 IP
- 如果使用 Cloudflare 等 CDN，可以添加该 header
- 有意或无意定义了多个反向代理
结论:如果这个 header 来自您自己的代理，您应该只信任它(如果有多个 IP，只信任最后一个)。
关于http - x-forwarded-for 是否应该在 https 流量中包含代理？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/30811131/