我在代理/负载均衡器后面有一个Web服务器集群。该代理包含我的SSL证书，并将解密的流量交给Web服务器，并且在此过程中添加了一个＆＃34; x-forwarded-for＆＃34;标头到Web应用程序接收的HTTP标头。在过去十年中，该应用程序已经看到数百万的IP地址，但今天发生了一些奇怪的事情。
我第一次看到x-forwarded-for包含第二个地址到达应用程序[已更改地址]：
x-forwarded-for: 62.211.19.218, 177.168.159.85
这表示流量来自代理，我知道这对x-f-f来说是正常的。我认为用https作为协议是不可能的（或者至少不太可能）。
有人可以解释这是合法的吗？
答案 0 :(得分：0)
可能正在使用HTTPS的代理协议。当然，您可能没有使用httproxy，但这似乎是一个不错的描述：
http://www.haproxy.org/download/1.5/doc/proxy-protocol.txt
我不确定SSL证书，但不能保证有人在做某些事情（可能是无意的），比如通过代理运行所有的HTTPS流量，然后接受所有无效的证书。但我怀疑代理协议可能使这项工作;它确实在某种意义上将HTTP标头暴露给代理。
答案 1 :(得分：0)
根据RFC 7239，此HTTP标头指定为
X-Forwarded-For：客户端，proxy1，proxy2，...
其中client是原始客户端的IP，然后每个代理添加从列表末尾收到请求的IP。在上面的示例中，您会在网络服务器中看到proxy3的IP，proxy2是与proxy3相关联的IP。
任何人都可以在此标题中放置任何内容，您应该只接受来自已知来源的已知来源，例如您自己的反向代理或已知合法代理的白名单。例如，Apache有mod_rpaf，它透明地将客户端IP地址更改为此标头中提供的IP地址，但前提是从已知代理服务器的IP接收请求。
在公司网络上，您可以轻松地对HTTPS流量进行透明代理，而无需普通用户的任何通知。只需创建自己的证书颁发机构，例如使用Windows组策略即可安装＆amp;在所有公司工作站上信任此CA.然后将所有HTTPS连接重定向到您的代理，这将为动态生成所有访问域的证书。这是正在发生的事情，你甚至可以使用这种方法购买企业硬件代理。
总结一下您可以在X-Forwarded-For标题中看到多个IP的原因：
结论：如果此标头来自您自己的代理，则应该只信任此标头（如果是多个IP，请仅信任最后一个）。