这可能会有所延伸，但似乎值得一提。假设我在nginx-host（linux）上有一个静态Angular Web应用程序以及以下/ etc / hosts文件，由一些粗略的配置管理工具自动为主机生成：
127.0.0.1 localhost
10.0.0.1 internalhost
接下来，我有nginx-host的库存Nginx配置，服务器块没有任何花哨 - 这个有问题的位置块：
location ^~ /app {
return 301 http://internalhost/end/point
}
问题是这个块返回精确位置块中列出的url而没有从internalhost到适当IP的任何转换，导致客户端错误 - 我在交还之前需要它解决该IP。
请注意，我们无法在此处使用地图或上游。这里的Immovable Wall是我们的配置系统通过查找和生成主机文件来处理所有服务发现和主机依赖性解析，并且它与我们的内部nginx配置完全分离，因此我们无法将查找连接到nginx设置允许动态映射或上游。对于各种测试环境，这也发生在几个独立的网络部分，因此我们很难要求我们引用nginx主机的/etc/hosts文件来解析主机名之前传回重定向路径，因为internalhost可以是从dev-internalhost到production-backup-internalhost的所有内容，所有这些都有不同的IP。
注意：此处proxy_pass不是解决方案，我们需要重定向用于SSO目的，当请求发送到internalhost位置时，请求参数需要继续执行{来自internalhost的{1}}机器，客户需要查看重定向，以了解它现在与nginx-host服务器的说话条件。
为清晰起见进行编辑：客户端无法自行解决internalhost：internalapp具有静态UI，该UI上的链接会点击nginx-host端点，以及nginx需求传回从生成的本地主机文件派生的基于IP的链接。除了本地主机文件之外，/app根本没有DNS记录 - 但是hosts文件中的IP地址将解析为实际可以到达的internalapp
答案 0 :(得分：0)
301重定向中的主机名只是发送到网络浏览器的文字。
绝大多数客户将使用DNS从URL中的主机名中查找IP地址。
如果你有浏览器＆＃34;那里＆＃34;在互联网上，他们必须拥有一个完全合格的域名（例如www.example.com）作为内部或类似的东西永远不会指向你。在这种情况下，您将不得不更改由nginx发回的消息。如果您可以控制配置，那就太微不足道了......
如果您只有内部主机，则您的内部DNS应该能够允许内部主机正确解析＆＃34; internalhost＆＃34;到其内部IP地址。实质上，确保他们发送搜索域记录以及DHCP响应。
如果公司内部的网络/ IT团队知道他们在做什么，如何在公司内部设置DHCP和DNS相对容易。 如果他们有一个混乱 - 每隔一段时间就会发生 - 无论你做什么，都没有什么能正常工作。
很大程度上取决于他们如何设置，但总的来说，制作名称如＆＃34; internalhost＆＃34;在内部解析为IP地址，我使用：
选择一个内部域名（如果还没有）。例如.local是一个选项，或历史上in.example.com（其中example.com是其外部名称）。它不必在外部知道，它不能在外部使用。外部知道它使它稍微困难，所以避免这样做。
DHCP：我设置DHCP以发出可选的＆＃34;搜索域＆＃34;。如何做到这一点取决于他们使用的DHCP服务器，例如https://serverfault.com/questions/481453/set-search-domain-on-dhcp-server-without-changing-domain-name显示了一个示例。我通常会确保它会发出in.example.com, example.com因为这样可以更轻松地输入域名。
内部DNS：现在只需在内部DNS服务器上添加internalhost.in.example.com.的A记录，并将其指向您的RFC1918地址。
可选：我确保防火墙不允许内部客户端使用外部DNS服务器 - 或者（更好？）将它们透明地重定向到内部DNS服务器。这样你可以避免用户设置，例如8.8.8.8和8.8.4.4作为DNS服务器，取代他们从DHCP服务器获得的内容，因此没有看到您的内部名称。
那就是它。 http://internalhost/whatever现在将使用上面步骤3中给出的IP地址转到计算机，浏览器将发送internalhost的Host：标头（如果您有虚拟主机！）。