IIS Manager 远程管理：先检查 WMSVC 自己的地址

你的站点通过隧道在 443 上响应，IIS Manager 却仍然连不上服务器。这两个结果并不矛盾，因为网站和远程管理端点其实是两个监听器，各自有不同的配置和不同的访问规则。管理端属于 Web Management Service，也就是 WMSVC，它有自己的地址、端口、证书和 IPv4 限制。在动任何一条路由之前，先检查这个端点。

两个监听器，两类不同的问题

发往站点的请求会到达该站点的 HTTP.sys 绑定，这个绑定在 applicationHost 配置中按站点和协议分别定义。来自 IIS Manager 的请求则到达 WMSVC，它默认在 TCP 8172 上响应 HTTPS，并在服务器级别配置。站点绑定不会改变 WMSVC 监听的位置，WMSVC 也不会改变站点响应的地址。它们共享同一台机器和同一个证书存储，相似之处到此为止。

所以，对 443 端口执行 Test-NetConnection 成功，只能说明站点监听器可达，对管理端一无所知。

找出 WMSVC 实际绑定的地址

要问服务器现在监听什么，而不是多年前配置了什么。Get-NetTCPConnection -LocalPort 8172 -State Listen 会打印本地地址：值为 0.0.0.0 或 :: 表示所有地址，而具体地址则只表示那一个。如果服务器改过地址，仍固定在废弃地址上的监听器正是这项检查能抓到的故障。

配置值位于服务器节点上 IIS Manager 的 Management Service 页面，背后则是 inetsrv 配置目录里的 administration.config。把两者对比：文件写的是什么，套接字实际绑定的是什么。

然后从受影响的 VPN 客户端运行 Test-NetConnection -ComputerName iis-admin.example.com -Port 8172 -InformationLevel Detailed，读取解析出的地址和选定的源地址。VPN 上出现不同的 DNS 应答很常见，值得尽早排除。把那个确切的主机名和端口留在工单里，因为日后换一个名字做比较，证明不了你所做的改动。

读取服务器看到的源地址

WMSVC 的 IPv4 限制是针对到达服务器的地址来评估的，而这个地址并不总是你的笔记本自认为拥有的地址。如果 VPN 地址池在路径某处被转换，服务器看到的就是转换后的地址，用客户端内部地址构建的允许列表会拒绝它。这种拒绝在客户端看来像连接失败，所以常被误诊为路由问题。

在修改限制列表之前，用 TCP 测试的详细输出加上服务器自己的连接表，看清究竟是哪个源地址到达了。

把绑定变更当作服务变更来做

编辑 WMSVC 配置前必须先停止该服务，所以要把它规划成一次变更，并准备好另一条管理通道，例如控制台访问或不依赖 IIS Manager 的远程会话。停止服务、应用地址、端口或证书变更，然后启动并确认监听器已经移动。在此期间，其他使用远程 IIS 管理的人会丢失会话。在窗口打开前通知其他管理员；变更中途才发现，正是两个人同时编辑同一个监听器的由来。

选择所有地址是合法的选项，但要把它当作访问决策而不是捷径。在限制列表仍然开放时扩大监听器，正是管理端点暴露在没人打算开放的网络上的一种方式。如果服务器有多块网卡，就把监听器限制在管理接口，不要动数据路径，并确认站点仍在自己地址上响应。

WMSVC 出示的证书与站点证书是分开选择的。如果改了地址，要确认证书仍与客户端使用的主机名匹配，否则连接稍后会在 TLS 阶段失败，而报错与路由毫无关系。

把可达性与信任、权限分开看

TCP 打通之后，剩下的失败是有顺序的：管理证书的 TLS 信任，然后是 Windows 身份验证，再然后是授予该账户的 IIS Manager 权限。每一种都会产生不同的错误，而且没有一个能靠路由或防火墙规则解决。与其再次重启服务，不如照字面读错误文本。

按这个顺序做四项检查，端点、监听器、源地址、信任，通常你会在找到网络问题之前先找到过期的绑定。