配置CORS策略后React项目Fetch POST请求失败排查

在ASP.NET Core 6 Web API（部署于IIS 8.5内部环境）中配置CORS策略后，React项目的Fetch POST请求失败；仅当配置允许任意源、任意方法、任意请求头的策略时，POST请求才能正常执行。

经排查：

• 浏览器发送OPTIONS预请求，请求的referrer为myapp.mycompany.com
• Web API的CORS策略配置包含http://*.mycompanydomain.com和https://*.mycompanydomain.com
• 服务器返回204无内容，但未携带Access-Control-Allow-Origin响应头，这是核心问题

当前CORS策略代码：

builder.Services.AddCors(option =>
{
    option.AddPolicy(name: "CorsPolicy",
    policy =>
    {
        policy.WithOrigins(
            "http://localhost:3000",
            "https://localhost:3000",
            "http://*.mycompanydomain.com",
            "https://*.mycompanydomain.com")
                .AllowAnyHeader()
                .AllowAnyMethod();
    });
});

OPTIONS预请求响应头：

Date: Fri, 14 Apr 2023 12:17:34 GMT
Server: Microsoft-IIS/8.5
X-Powered-By: ASP.NET

• 域名拼写匹配问题：请求源是myapp.mycompany.com，但配置里的后缀是mycompanydomain.com，两者域名后缀不一致，直接导致CORS策略不匹配，优先检查域名拼写是否正确。另外WithOrigins的通配符仅支持二级域名匹配（如*.mycompany.com匹配a.mycompany.com），需确认请求源符合该规则。
• CORS中间件顺序问题：检查Program.cs中是否在app.UseRouting()之后、app.UseAuthorization()之前添加app.UseCors("CorsPolicy")，中间件顺序错误会导致策略不生效，正确顺序示例：

  app.UseRouting();
  app.UseCors("CorsPolicy");
  app.UseAuthorization();
  

• IIS配置干扰：
  • 打开IIS管理器，进入站点的HTTP响应头，检查是否手动添加过Access-Control-Allow-Origin头，若有则删除避免冲突。
  • 若安装了IIS的CORS模块，可能会和ASP.NET Core的CORS中间件冲突，建议禁用IIS自带的CORS模块，仅使用ASP.NET Core的配置。
• 协议匹配问题：通过浏览器开发者工具的网络面板查看请求的Origin头（CORS基于Origin而非referrer判断），确认请求实际使用的协议（HTTP/HTTPS）和配置中的域名协议一致，比如React用HTTPS但配置里只加了HTTP的域名，会导致匹配失败。
• 中间件拦截OPTIONS请求：部分认证中间件或自定义中间件可能提前处理OPTIONS请求，导致CORS中间件无法生效。可添加日志或调试代码，确认OPTIONS请求是否到达CORS中间件；也可尝试显式指定允许的方法，比如.WithMethods("OPTIONS", "POST", "GET")。
• 验证策略加载情况：在Program.cs中添加日志输出，确认CORS策略是否正确加载：

  var corsPolicy = builder.Services.BuildServiceProvider().GetRequiredService<ICorsPolicyProvider>().GetPolicyAsync(null, "CorsPolicy").Result;
  Console.WriteLine("Allowed origins: " + string.Join(", ", corsPolicy.Origins));
  

  运行时查看输出，确认配置的域名是否正确被加载。

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