x-forwarded-for 是否应该在 https 流量中包含代理？
Should x-forwarded-for contain a proxy in https traffic?
我在 proxy/load 平衡器后面有一个网络服务器集群。该代理包含我的 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 作为协议这是不可能的（或者至少不太可能）。
谁能解释一下这是怎么回事？
可能它正在使用 HTTPS 的代理协议。当然，您可能没有使用 httpproxy，但这似乎是一个不错的描述：
http://www.haproxy.org/download/1.5/doc/proxy-protocol.txt
我不确定 SSL 证书，但不能保证有人在做一些病态的事情（可能是无意的），比如 运行 他们所有的 HTTPS 流量都通过代理，然后接受所有无效的证书。但我怀疑代理协议 可能 使这项工作；它确实在某种意义上将 HTTP headers 暴露给代理。
根据 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代理
- header 是由请求者自己（浏览器、wget、脚本）添加的，无论出于何种原因，例如隐藏自己的 IP
- 像 Cloudflare 这样的 CDN 可以添加 header 如果使用
- 有意或无意定义了多个反向代理
结论：你应该只信任这个header如果它来自你自己的代理（如果有多个IP，只信任最后一个）。
我在 proxy/load 平衡器后面有一个网络服务器集群。该代理包含我的 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 作为协议这是不可能的（或者至少不太可能）。
谁能解释一下这是怎么回事？
可能它正在使用 HTTPS 的代理协议。当然，您可能没有使用 httpproxy，但这似乎是一个不错的描述：
http://www.haproxy.org/download/1.5/doc/proxy-protocol.txt
我不确定 SSL 证书，但不能保证有人在做一些病态的事情（可能是无意的），比如 运行 他们所有的 HTTPS 流量都通过代理，然后接受所有无效的证书。但我怀疑代理协议 可能 使这项工作；它确实在某种意义上将 HTTP headers 暴露给代理。
根据 RFC 7239，此 HTTP header 指定为
X-Forwarded-For: client, proxy1, proxy2, ...
其中 client 是原始客户端的 IP，然后每个代理在列表末尾添加它收到请求的 IP。在上面的示例中，您会在网络服务器中看到 proxy3 的 IP，而 proxy2 是连接到 proxy3.
由于任何人都可以将任何内容放入此 header，您应该只接受来自已知来源的内容，例如您自己的反向代理或已知合法代理的白名单。例如 Apache 有 mod_rpaf，它透明地将客户端 IP 地址更改为此 header 中提供的地址，但前提是从已知代理服务器的 IP 接收到请求。
在公司网络上，您可以轻松地对 HTTPS 流量进行透明代理，而不会引起普通用户的注意。只需创建您自己的证书颁发机构，例如使用 Windows 组策略在所有公司工作站上安装并信任此 CA。然后将所有 HTTPS 连接重定向到您的代理，代理将为所有访问过的域动态生成证书。这是正在发生的事情，您甚至可以使用这种方法购买企业硬件代理。
总结一下为什么您可以在 X-Forwarded-For header 中看到多个 IP 的原因：
- 如上所述的透明HTTPS代理
- header 是由请求者自己（浏览器、wget、脚本）添加的，无论出于何种原因，例如隐藏自己的 IP
- 像 Cloudflare 这样的 CDN 可以添加 header 如果使用
- 有意或无意定义了多个反向代理
结论：你应该只信任这个header如果它来自你自己的代理（如果有多个IP，只信任最后一个）。