启动SignalR Hub提示“未找到可用传输”，但协商返回三种可用传输

我之前在ASP.NET Core 2.1 Preview2版本中也碰到过一模一样的问题，结合你给出的协商返回结果，这里给你几个实用的排查和解决方向：

1. 严格匹配客户端与服务端的SignalR版本 #

ASP.NET Core 2.1 Preview2对应的SignalR客户端版本必须完全对齐，绝对不能混用不同版本的客户端包。如果你用的是npm包@aspnet/signalr，一定要安装1.0.0-preview2-final这个特定版本：

npm install @aspnet/signalr@1.0.0-preview2-final --save

版本不兼容是这个预览版里最常见的导致传输协商失败的原因。

2. 确认服务端传输配置无遗漏 #

虽然协商返回了可用传输列表，但服务端的中间件配置可能存在隐性问题。检查Startup.cs的Configure方法，确保SignalR路由在正确的位置配置，且没有手动禁用所需传输：

// Configure方法中确保SignalR中间件正确注册
app.UseSignalR(routes =>
{
    routes.MapHub<YourHub>("/yourHubEndpoint");
});

// 如果手动配置了SignalR选项，不要禁用默认传输
services.AddSignalR(options =>
{
    // 不要在这里添加禁用WebSockets、ServerSentEvents或LongPolling的配置
});

另外，注意CORS、认证这类中间件的顺序，确保SignalR的路由配置在这些中间件之后，避免请求被提前拦截。

3. 检查客户端初始化代码 #

有时候客户端代码会不小心限制了传输类型，或者没有正确加载所有传输实现。创建Hub连接时，尽量让客户端自动协商传输，不要手动限制：

import * as signalR from '@aspnet/signalr';

const connection = new signalR.HubConnectionBuilder()
    .withUrl("/yourHubEndpoint")
    // 不要手动指定有限的传输列表，让框架自动匹配服务端返回的选项
    .build();

如果怀疑是浏览器环境限制（比如某些旧浏览器对WebSockets的支持问题），可以尝试强制指定LongPolling来测试是否能正常连接：

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

4. 排查网络与代理干扰 #

如果应用部署在反向代理（比如Nginx、IIS）之后，需要确保代理支持WebSocket协议：

• IIS环境下要开启WebSockets功能；
• Nginx需要配置转发规则，确保Upgrade和Connection头被正确传递。

同时打开浏览器控制台的网络面板，查看协商请求之后的传输请求是否有404、500这类错误，这能帮你快速定位具体是哪个传输环节出了问题。

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