.NET Core 2.2.7+SignalR 2.4.1 IIS部署连接失败问题咨询

我之前处理过不少类似的部署问题，结合你的环境（.NET Core 2.2.7 + SignalR 2.4.1 + Windows Server 2016 IIS），这个握手失败+WebSocket无法启用的问题，大概率是IIS配置或服务器组件缺失导致的，下面给你一步步排查的方向：

1. 确认Windows Server 2016是否安装了WebSocket组件 #

Windows Server 2016默认没有安装WebSocket协议，这是SignalR使用WebSocket传输的核心前提：

• 打开服务器管理器 → 添加角色和功能 → 选择「Web服务器（IIS）」→ 展开「Web服务器」→ 「应用程序开发」→ 勾选WebSocket协议 → 完成安装后重启IIS。

2. 检查IIS站点的WebSocket启用状态 #

• 打开IIS管理器，找到你的目标站点 → 切换到「功能视图」→ 双击WebSocket → 确认「启用WebSocket」处于勾选状态，请求限制保持默认即可。

3. 验证.NET Core托管组件版本匹配且正确安装 #

.NET Core 2.2需要对应版本的.NET Core Hosting Bundle才能在IIS上正常托管，务必确保版本和你的项目一致（2.2.7对应的托管包）：

• 安装对应版本的托管包后，重启IIS和服务器；
• 检查站点的应用程序池，确认**.NET CLR版本设置为无托管代码**（因为.NET Core是自托管模式，IIS仅作为反向代理）。

4. 排查SignalR传输配置与IIS请求拦截 #

• 先尝试在客户端强制指定WebSocket传输，排除自动降级的干扰，代码示例：

  const connection = new signalR.HubConnectionBuilder()
    .withUrl("/yourHubPath", {
      transport: signalR.HttpTransportType.WebSockets
    })
    .build();
  

  如果此时报错更明确，能快速定位WebSocket本身的问题；
• 检查IIS的请求筛选功能，确保没有阻止WebSocket握手必需的请求头（比如Upgrade、Connection: Upgrade）；
• 若站点配置了URL重写规则，确认SignalR的默认路径（/hubs/xxx）没有被错误重写，避免破坏握手请求。

5. 查看日志获取详细错误信息 #

• 查看IIS站点日志（默认路径C:\inetpub\logs\LogFiles\W3SVCxxxx），找到包含/hubs的请求记录，查看返回的状态码和错误详情（比如404、500），能帮你定位是路径问题还是服务器内部错误；
• 打开Windows事件查看器 → 「应用程序日志」，查找.NET Core相关的错误条目，里面通常会有握手失败的具体原因。

6. 确认防火墙与代理的WebSocket支持 #

• 如果服务器处于防火墙后方，确保80/443端口开放，且防火墙没有拦截Upgrade请求头；
• 若使用了反向代理（比如ARR），需要配置代理支持WebSocket，确保Connection和Upgrade头能完整传递到后端的.NET Core应用。

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