.NET Core发布后CORS跨域报错 预检请求未通过访问控制检查

核心问题定位 #

你遇到的Access-Control-Allow-Origin响应头缺失问题，本地localhost正常、生产环境报错，核心原因集中在3个配置错误：

• SetIsOriginAllowedToAllowWildcardSubdomains() 方法仅对配置中包含*通配符的源规则生效，当前WithOrigins中配置的是固定域名http://web.******.ikanbi.com，未使用通配符格式，所有web.任意子域.ikanbi.com的请求都无法匹配CORS规则，自然不会返回合法的跨域响应头。
• 中间件管道顺序错误是这类问题最高发的诱因：app.UseCors()必须放在固定的管道位置才能拦截OPTIONS预检请求，位置偏移会直接导致策略不生效，本地开发环境因为Kestrel调试模式的宽松配置不会触发问题，发布到生产环境就会暴露。
• 你访问的/appHub/negotiate是SignalR协商端点，对CORS策略执行顺序要求更严格，端点映射如果放在CORS中间件之前，预检请求会直接被端点路由拦截，不会走到CORS逻辑。

分步修复操作 #

1. 修正CORS策略配置 #

将通配子域名的规则改成正确的通配符格式，调整后代码如下：

services.AddCors(options =>
{
    options.AddPolicy("AllowAll",
        builder => builder
            .AllowAnyMethod()
            .AllowAnyHeader()
            // 替换为带*的通配源格式，配合通配子域名方法生效
            .WithOrigins("http://localhost:4200", "http://web.*.ikanbi.com")
            .SetIsOriginAllowedToAllowWildcardSubdomains()
            .AllowCredentials()
    );
});

注意：配置AllowCredentials()时禁止同时使用AllowAnyOrigin()，否则运行时会抛出配置异常，上述指定通配源的写法符合规范。

2. 严格调整中间件管道顺序 #

CORS中间件的位置必须严格遵循以下顺序，任意顺序错乱都会导致策略失效：

// 管道顺序参考
app.UseRouting();

// CORS必须放在UseRouting之后，授权、端点映射之前
app.UseCors("AllowAll");

app.UseAuthorization();

// 所有端点映射（控制器、SignalR Hub）必须放在CORS中间件之后
app.MapControllers();
app.MapHub<AppHub>("/appHub"); // 你的SignalR Hub映射

常见错误写法：将app.UseCors()放在UseRouting()之前，或是放在MapControllers/MapHub之后，这种情况下OPTIONS预检请求不会被CORS中间件处理，直接返回404/405或者不带跨域头的响应。

3. 生产环境额外排查项 #

• 如果服务前面挂了Nginx、IIS、CDN等反向代理，检查代理配置是否拦截了OPTIONS请求，是否过滤掉了后端返回的Access-Control-*系列响应头，反向代理默认配置经常会覆盖或删除这类自定义头。
• 检查生产前端实际请求源：CORS源匹配是协议、域名、端口三者完全精确匹配，确认前端没有误用HTTPS协议、非80端口，否则即使域名匹配也会被拦截。
• 不要在Controller、Action上额外添加其他策略名的[EnableCors]特性，避免全局策略被局部覆盖。

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