我相信我發現了一個非常奇怪的、狹窄的問題，與 Windows 10 上 Powershell 執行的 IIS 和 WINRM 的互通性問題有關。
我的設備有一個專門綁定到本地主機位址 127.0.0.1 的 IIS 站點。以這種方式配置時，在瀏覽器網址列中使用“localhost”不起作用；連線將被拒絕或重置。該網站只能存取 127.0.0.1（顯式）。透過使用「netsh http add iplisten」命令將 127.0.0.1 新增至 iplisten 清單可以解決此問題。完成後，本地主機綁定的站點就可以工作了。到目前為止，一切都很好。
但這就是它變得奇怪的地方。將本機位址新增至 iplisten 清單後，透過 Powershell 的遠端命令（invoke-command --> winrm）將停止運作。在裝置上，針對其測試 winrm民眾IP 位址現在失效了。 “winrm Quickconfig”表示設備已配置為遠端並且工作正常。但不遠端命令有效，所有命令都報告“無法到達目的地”。查詢目標裝置上的偵聽器會顯示 RM 定義的所有適當端點和設定符合預期 - 一切看起來都像這樣應該工作。沒有防火牆阻止存取。
解決方案？從目標裝置上的 iplisten 清單中刪除 127.0.0.1 可以立即消除問題，並且 powershell/remote 命令開始工作。但接下來我們又回到了最初的問題；瀏覽器中的“localhost”失敗。作為解決方法，我可以在指向 127.0.0.1 的主機中建立一個虛假的 DNS“別名”，但如果可能的話，我真的不想打擾主機。
在我看來，這實際上是目標設備上最低網路解析度的一個小問題/錯誤；將 127.0.0.1 位址新增至顯式 iplisten 清單中不應中斷完全不同位址上的遠端 WinRM 連線。看起來這就是不經意間的路由全部到 IIS 的 HTTP 流量，當向其發送遠端命令時，IIS 顯然「首先」獲取它，沒有對其進行綁定（透過連接埠 5985），不知道如何處理它，並丟棄它，導致遠端命令失敗。事實上，在我看來，IIS 根本不應該看到它；但是將環回位址新增至 iplisten 清單中可以精確地以這種方式路由此類流量。
我是否遺漏或不了解流量如何路由，或者我只是忽略了此設定的某些方面？如果我錯過了一些額外的步驟，我希望得到解決它的指導。