X-Forwarded-Host头文件的真实用法？
我在X-Forwarded-*头文件中发现了一些有趣的内容，包括Apache文档中的反向代理请求头部分，以及X-Forwarded-For的维基百科文章 。
我明白那个：
-
X-Forwarded-For给出了连接到代理的客户端的地址 -
X-Forwarded-Port给客户端连接的端口（例如80或443） -
X-Forwarded-Proto给出用于连接到代理的客户端协议（http或https） -
X-Forwarded-Host给出客户端发送给代理的Host头的内容。
这些都是有道理的。
但是，我仍然无法弄清楚X-Forwarded-Host的真实生活用例。 我知道需要在不同的端口上重复连接，或者使用不同的scheme，但为什么代理服务器在向目标服务器重复请求时会更改Host头？
如果您使用像Apigee这样的前端服务作为您的API的前端，那么您将需要X-FORWARDED-HOST之类的东西来了解使用哪个主机名连接到API，因为Apigee使用任何后端DNS是，nginx和你的应用程序堆栈只能看到主机头作为你的后端DNS名称，而不是首先被调用的主机名。
我可以告诉你一个真实的生活问题，我有一个使用IBM门户的问题。
在我的情况下，问题是IBM门户网站有一个rest服务，它检索资源的URL，如：{“url”：“ http://internal.host.name/path ”}
发生了什么？ 很简单，当你从内部网进入时，一切正常，因为internalHostName存在，但…当用户从互联网input，然后代理无法parsing主机名和门户网站崩溃。
IBM门户的修正是读取X-FORWARDED-HOST头，然后将响应更改为：{“url”：“ http://internet.host.name/path ”}
看到我把互联网，而不是内部的第二个回应。
这是我今天工作的场景：用户使用指向反向代理的“ https://neaturl.company.com ”URL访问某个应用程序服务器。 然后代理终止SSL并将用户的请求redirect到URL为“ http://192.168.1.1:5555 ”的实际应用服务器。 问题是，当应用程序服务器需要使用绝对path将用户redirect到同一服务器上的其他页面时，它使用的是后一个URL，用户无权访问此页面。 使用X-Forwarded-Host（+ X-Forwarded-Proto和X-Forwarded-Port）允许我们的代理告诉应用服务器最初使用哪个URL用户，因此服务器开始在其响应中生成正确的绝对path。
在这种情况下，没有选项可以停止应用程序服务器生成绝对URL，也不会手动将其configuration为“公用URL”。
一个例子可能是阻止某些主机并将其redirect到外部块页面的代理。 事实上，我几乎可以肯定我的学校filter是这样做的…
（他们之所以不把原来的Host作为Host传递，是因为有些服务器[Nginx？]拒绝任何stream量到错误的Host 。）
对于“x-forward-host”的需求，我可以想象一个虚拟主机场景，其中有几个内部主机（内部networking）和一个位于这些主机和Internet之间的反向代理。 如果请求的主机是内部networking的一部分，则请求的主机parsing为反向代理IP，Web浏览器将请求发送到反向代理。 这个反向代理find合适的内部主机，并将客户端发送的请求转发给这个主机。 这样做时，反向代理将主机字段更改为匹配内部主机，并将x-forward-host设置为客户机请求的实际主机。 关于反向代理的更多细节可以在这个维基百科页面http://en.wikipedia.org/wiki/Reverse_proxy中find 。
查看这篇文章，了解有关x-forwarded-for标题和一个简单的演示python脚本的详细信息，该脚本显示了web服务器如何检测代理服务器的使用情况： x-forward-for-
X-Forwarded-Host只是挽救了我的生命。 CDN（或反向代理，如果你想下降到“树”）确定哪个来源用户来到他们的主机头使用。 因此，CDN不能使用相同的主机头来接触原点 – 否则，CDN将循环进入本身，而不是去原点。 因此，CDN使用IP地址或某个虚拟FQDN作为从原点获取内容的主机头。 现在，来源可能希望知道什么是主机头（即网站名称）内容被要求。 在我的情况下，一个起源服务2个网站。
另一种情况是，您将应用程序授权到主机URL，然后在n> 1个服务器上进行负载平衡。
