IIS在x-Forwarded-For标头中设置的端口号与最初的目标端口不同

我在我的dev box上设置了一个IIS反向代理，以测试我的应用程序如何处理通过SSL卸载的请求
我的应用程序需要重新创建原始请求，附加一些查询字符串参数，然后将其发送回客户端。默认情况下，IIS/ARR/URL重写似乎不会附加行业标准的“X-Forwarded-Host”和“X-Forwarded-Proto”头。相反，我能找到的最接近的东西是“X-ARR-SSL”和“X-Forwarded-For”
我很高兴从“X-Forwarded-For”解析出原始IP，但当我查看端口时，它似乎没有任何意义。我的SSL反向代理设置为在默认SSL端口（443）上侦听，但在标头中指定的端口是52585
我的问题是，是否有人知道如何确定原始请求的目标端口是什么？我希望我的应用程序能够可靠地处理IIS代理的请求，但看起来我必须根据请求是HTTP还是HTTPS来猜测端口。

与服务器无关。它是客户端的IP地址。它被附加到请求头中，以便web服务器能够识别真正的客户机而不是反向代理。您提到的其他标题是事实上的标准，现在已被替代。根据RFC，端口号将包含在

转发的

报头的主机部分中，如下所示：

Forwarded: for=192.0.2.60;proto=http;host=example.com:888;by=203.0.113.43

我怀疑有些反向代理会将端口号添加到

X-Forwarded-Host

头中的冒号后面，就像在

Host

头中一样，但由于它不是一个定义的标准头，因此您只需使用反向代理尝试即可查看

---

另请参见：

我感兴趣的是客户。我看到了你在回复中引用的链接，但我正在尝试让我的应用程序与现在的应用程序一起工作。我安装了一个带有ARR 2.5的IIS 7，目前，作为代理时，它似乎没有默认提供

转发的

头。您希望使用哪个端口，除了记录它之外，您认为您可以使用它做什么？它将是一个动态高端口，并且将连接到IIS，因此您将无法向其发送任何内容。听起来你好像不太明白端口是如何工作的。在大多数情况下，服务器侦听固定端口（如80或443），客户端使用动态高端口连接到该端口。两侧的端口号很少相同。应为80或443（客户端向其发出请求的服务器端口）。原因：我的应用程序正在尝试发送一个链接回我的应用程序的url，而我正在将此url发送到反向代理的另一侧的客户端。因此，我的应用程序需要一个GET req，如

https://site/myapp.aspx

可能会在我的应用程序中出现url字符串，看起来像`。如果我想发回一个链接回我的站点的url，我需要知道原始协议是什么（https），原始服务器名称，以及原始目标端口是什么（可能是443）。如果我发回一个类似

http://serverBehindFirewall:95/myapp.aspx?page=2

，那么客户端对该URL的请求将永远不会到达我的app.PS。我很了解波尔图葡萄酒的工作原理，因为我以前一直喝波尔图葡萄酒。