我相信我发现了一个非常奇怪、狭窄的问题，它与 Windows 10 上的 Powershell 与 IIS 和 WINRM 的互操作性问题有关。
我有一台设备，其中有一个 IIS 站点专门绑定到本地主机地址 127.0.0.1。以这种方式配置时，在浏览器地址栏中使用“localhost”不起作用；连接将被拒绝或重置。该站点只能通过 127.0.0.1 访问（明确）。通过“netsh http add iplisten”命令将 127.0.0.1 添加到 iplisten 列表中可以解决此问题。完成后，本地主机绑定的站点即可正常工作。到目前为止一切顺利。
但这里有点奇怪。将 localhost 地址添加到 iplisten 列表后，通过 Powershell 执行的远程命令（invoke-command --> winrm）将停止工作。在设备上，对其执行 test-winrm民众IP 地址现在失败。“winrm quickconfig”表示设备已配置为远程并且工作正常。但是不远程命令工作正常，所有命令均报告“无法到达目的地”。查询目标设备上的侦听器显示已定义所有适当的端点，并且 RM 的配置符合预期 - 一切看起来都像应该工作。没有防火墙阻止访问。
解决方案是什么？从目标设备上的 iplisten 列表中删除 127.0.0.1 即可立即解决问题，powershell/remote 命令开始起作用。但随后我们又回到了最初的问题；浏览器中的“localhost”失败了。作为一种解决方法，我可以在指向 127.0.0.1 的主机中创建一个虚假的 DNS“别名”，但如果可能的话，我真的不想弄乱主机。
在我看来，这实际上是目标设备上最低限度的网络解析中的一个小问题/错误；将 127.0.0.1 地址添加到显式 iplisten 列表中不应该破坏通过完全不同的地址进行的远程 WinRM 连接。这似乎是无意中路由全部HTTP 流量到 IIS，当向其发送远程命令时，IIS 显然“首先”获取该命令，没有绑定它（通过端口 5985），不知道如何处理它，并丢弃它，导致远程命令失败。实际上，在我看来 IIS 根本就不应该看到它；但将环回地址添加到 iplisten 列表中正是以这种方式路由此类流量。
我是否遗漏了或不了解流量路由方式，或者我忽略了此设置的某些方面？如果我错过了其他一些步骤，我将非常感激您能提供解决该问题的指导。