单服务器环境下，IIS运行时应用能否通过80端口建立WebSocket连接？

可以完全实现80端口同时承载IIS发布的观众浏览网站、以及VR系统的WebSocket中转流量，全程不需要新增服务器、不需要开放额外端口，所有调整都在现有网络管控规则范围内完成。

问题根因 #

这个报错的本质可以完全定位，不存在模糊猜测：

• Windows系统的所有HTTP/HTTPS流量都是由内核级的http.sys驱动统一调度，用户态程序不能无权限直接抢占端口。IIS安装时会自动注册通配符的80端口访问权限，没有对应权限的进程直接绑定80端口时，就会触发“无权访问套接字”的报错。
• 开发环境下大概率是用管理员权限手动启动的主机应用，即便没装IIS也能正常绑80端口；但生产环境中主机应用一般是作为后台服务用普通权限账号运行，哪怕IIS完全停掉，也会因为权限不足绑不上80端口。
• 解决思路的核心不是让主机应用和IIS抢80端口的监听权，而是让IIS作为80端口的唯一对外入口，按路径分流不同类型的流量。

可落地方案（完全匹配现有约束） #

方案1：IIS ARR反向代理（首选） #

• 所有操作不涉及对外端口变更，完全在现有80端口的管控范围内完成：
  1. 在服务器的IIS中安装ARR（应用程序请求路由）官方扩展、开启IIS原生WebSocket支持组件，两个组件都是微软官方提供的，不需要修改系统防火墙规则。
  2. 配置IIS的路由规则：把所有URL路径匹配/ws/*的请求，反向代理转发到主机应用本地监听的回环端口——比如让主机应用绑定127.0.0.1:8081，这个端口只接收本机回环的流量，不对外开放，完全不需要防火墙放行。
  3. 调整两端的连接地址：
     • VR演示端的WebSocket连接地址，统一指向IIS的对外80地址，比如ws://<服务器IP>/ws/link
     • 浏览器观众的访问地址完全沿用现有IIS发布的网站地址，不需要做任何修改。
• 该方案对外暴露的网络入口只有80端口，没有新增任何可被外部访问的端口，完全符合客户的安全策略要求。

方案2：http.sys路径级权限预留（备选） #

如果不想用反向代理转发流量，可以直接通过系统层的URL权限配置，让主机应用合法获得80端口特定路径的监听权，和IIS的站点路径完全隔离：

1. 先查询当前系统80端口的URL预留规则，执行命令netsh http show urlacl，确认IIS的预留范围。
2. 给主机应用需要使用的WebSocket路径新增专属权限，授权给运行主机服务的系统账号，执行示例命令：
   netsh http add urlacl url=http://+:80/vrws/ user="NT AUTHORITY\NETWORK SERVICE" listen=yes
3. 主机应用的监听逻辑不要绑定80端口的所有路径，只监听刚才配置的专属路径即可，和IIS托管的网站路径完全不重叠，不会产生冲突。

• 注意：这个方案依然需要IIS做同路径的流量分发，本质上和反向代理的效果一致，性能损耗更低，但配置排查的复杂度更高。

避坑提醒 #

• 不要为了运行主机应用直接停掉IIS，会直接切断观众端的网站访问链路，完全背离需求。
• 不要通过修改IIS的端口绑定范围来腾退部分端口，Windows Server 2016的http.sys原生支持路径级的端口隔离，这种硬改的方式容易触发IIS运行异常。
• 主机应用绑定本地端口时，一定要严格绑定127.0.0.1地址，不要监听0.0.0.0，避免把本地回环端口暴露到公网，违反客户的网络安全管控要求。

内容的提问来源于stack exchange，提问作者TDC