.NET6 SignalR Core协商阶段JavaScript客户端触发CORS错误

问题场景 #

在.NET 6环境使用最新版本SignalR，通过MVC 4项目的JavaScript客户端调用Hub服务，服务发布至Azure后，协商握手阶段出现CORS错误；将客户端配置的skipNegotiation设为true关闭协商功能后，CORS错误完全消失。

报错截图 #

现有配置 #

服务端CORS策略配置：

builder.Services.AddCors(options => options.AddPolicy("CorsPolicy",
builder =>
{
    builder.AllowAnyMethod().AllowAnyHeader().WithOrigins
    (
        //省略具体域名配置
    ).AllowCredentials().SetIsOriginAllowed(o => true).WithMethods("GET", "POST");
}));

客户端连接构建代码：

var connection = new signalR.HubConnectionBuilder()
    .withUrl(connectionUrl,
        {
            accessTokenFactory: () => {
                if (typeof bearerToken !== 'undefined') {
                    return bearerToken.getToken;
                }
            },
            skipNegotiation: true, // 改为false时触发CORS错误
            transport: signalR.HttpTransportType.WebSockets,
        })
    .withAutomaticReconnect()
    .configureLogging(signalR.LogLevel.Information)
    .build();

问题1：协商请求未应用已配置CORS策略的核心原因 #

三个常见触发点，按出现概率排序：

• 中间件顺序错误：.NET 6管线对中间件顺序强依赖，app.UseCors("CorsPolicy")必须放在app.UseRouting()之后、app.MapHub()/app.MapControllers()等端点映射逻辑之前。如果顺序写反，CORS中间件还没执行，SignalR的/negotiate端点就已经返回响应，自然不会带上正确的CORS响应头。而WebSocket直连走的是协议升级流程，不经过普通HTTP端点的响应处理链路，所以关闭协商直连WS不会触发该问题。
• CORS配置存在冲突：当前策略同时调用了WithOrigins()、SetIsOriginAllowed(_ => true)，又先写了AllowAnyMethod()再重复写WithMethods("GET","POST")，这类冲突配置在Azure App Service的IIS/ARR前置代理环境下，会出现规则覆盖，导致/negotiate端点的OPTIONS预检请求返回的CORS头不符合浏览器校验规则。另外AllowCredentials()模式下禁止返回Access-Control-Allow-Origin: *，如果WithOrigins()里的域名和实际请求来源不匹配，即使开了全来源放行也会被拦截。
• Azure侧CORS规则覆盖：如果在Azure App Service门户开启了平台级CORS配置，平台规则优先级高于应用内的.NET CORS策略，而平台默认CORS配置不会对SignalR协商端点放行带凭据的跨域请求，直接触发CORS报错。

问题2：开启/关闭协商功能的优劣势对比 #

SignalR默认协商流程是客户端先向/negotiate端点发HTTP请求，服务端返回支持的传输类型、连接ID、路由信息后，客户端再选择合适协议建立长连接。两种模式的优劣势如下：

开启协商（skipNegotiation: false） #

• 优势
  • 自动支持WebSocket、Server-Sent Events、长轮询三种传输方式的降级适配，遇到客户端网络封禁WS协议、老旧浏览器不支持WS等场景时，会自动切换到可用传输协议，连接成功率更高
  • 原生支持多实例横向扩展场景下的粘性会话分配、Redis底板/Azure SignalR Service的连接路由，适合生产环境集群部署
  • 不需要客户端强制指定传输类型，跨环境适配性更强
• 劣势
  • 连接建立阶段多一次HTTP往返，首连延迟稍高
  • 协商阶段包含OPTIONS预检、POST请求两个普通HTTP交互，更容易被CORS策略、反向代理规则拦截
  • 多节点部署时如果路由配置错误，容易出现连不上、消息丢包等问题

关闭协商（skipNegotiation: true） #

• 优势
  • 少一次HTTP请求交互，连接建立速度更快
  • 直接走指定传输协议直连，不会触发额外的HTTP协商请求，可直接规避协商端点的CORS配置问题
  • 连接链路短，问题排查成本更低
• 劣势
  • 必须强制指定单一传输方式，无自动降级能力，比如当前代码写死了WebSocket，一旦客户端网络不支持WS协议，连接会直接失败
  • 不支持Azure SignalR Service无服务器模式，多实例部署时如果没有配置粘性会话，直连WS会出现连接随机失败的问题
  • 企业内网、老旧浏览器场景下连接失败率明显升高

快速修复方案 #

1. 调整中间件顺序，严格按照UseRouting -> UseCors -> UseAuthorization -> MapHub/MapControllers的顺序注册管线
2. 清理冲突的CORS配置，删除重复的WithMethods、冗余的WithOrigins配置，保留SetIsOriginAllowed(_ => true).AllowAnyMethod().AllowAnyHeader().AllowCredentials()即可
3. 检查Azure门户的App Service CORS配置，如果应用内已经自定义CORS策略，直接关闭平台级CORS功能，避免规则覆盖

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