Angular请求IIS托管ASP.NET Core API偶发CORS跨域报错排查

现有配置的硬性问题 #

• 策略语法冲突：当前定义的AllowEverything策略同时使用了AllowAnyOrigin()和AllowCredentials()，这在ASP.NET Core 2.2版本是框架明确禁止的组合，运行时CORS中间件会直接抛出配置异常，拒绝执行跨域头注入逻辑。因为这个异常会被你的全局异常处理中间件直接捕获，返回不带跨域头的错误响应，你在生产环境根本看不到后端抛出的配置异常，只能看到浏览器侧的跨域报错。两种修正方案二选一：
• 不需要跨域携带凭证时，直接删除.AllowCredentials()配置
• 需要跨域携带凭证时，把.AllowAnyOrigin()替换为.SetIsOriginAllowed(_ => true)
• 中间件顺序错误：当前管道里存在两次重复调用app.UseCors()，且顺序排布完全不符合ASP.NET Core的管道执行规则。受洋葱模型的执行逻辑影响：正常请求走完全链路时能靠第二次UseCors注入跨域头，但一旦接口抛出未捕获异常，会直接走全局异常处理分支返回响应，根本不会经过位于异常处理之后的那个UseCors中间件，最终返回不带任何跨域头的错误响应，这就是问题呈现“偶发”特征的核心原因。正确的管道顺序应该严格按照：

1. 全局异常处理中间件
2. CORS中间件（仅调用一次，指定正确策略）
3. 认证授权中间件
4. MVC路由中间件

• 冗余代码清理：删除重复出现的services.AddMvc()配置，避免服务注册混乱。

IIS托管场景的特有排查方向 #

• IIS层响应拦截：检查站点的URL Rewrite规则、原生响应头模块，是否存在规则会拦截4xx/5xx状态的错误响应，直接由IIS生成默认错误页返回。这类响应完全不会经过ASP.NET Core应用管道，自然不会带跨域头。临时把IIS的错误响应模式切为“详细错误”，即可区分是应用层返回的响应还是IIS层返回的响应。
• 应用池冷启动问题：IIS托管ASP.NET Core时，应用池回收、闲置超时触发冷启动的阶段，第一个进来的请求还没等到Kestrel完成中间件管道初始化，就会直接返回不含跨域头的默认响应。可以将对应应用池的“空闲超时”、“固定时间回收”设置为0，开启站点预加载预热，消除冷启动导致的偶发丢头。
• OPTIONS预检请求拦截：如果站点开启了Windows集成认证，IIS会优先拦截跨域的OPTIONS预检请求，直接返回401认证要求，这类响应同样不会经过应用代码，也会触发跨域报错。需要在IIS中配置对OPTIONS请求的匿名访问规则，避免认证拦截。

快速定位调试方法 #

• 打开浏览器F12网络面板，把报错的请求右键复制为cURL命令，直接在生产服务器本地的命令行执行，查看返回的响应头内容：如果本地执行的响应就缺跨域头，问题出在应用配置；如果本地响应头正常，远程浏览器访问缺头，问题出在IIS层拦截。
• 在CORS中间件之后添加日志记录，对所有未携带Access-Control-Allow-Origin头的响应，记录对应的请求路径、返回状态码、异常堆栈，运行1-2天即可定位触发丢头的固定场景。

注：zone.js中的报错位置是Angular框架内置的XHR发送逻辑，本身和CORS问题无关，只是作为跨域报错的触发载体，不需要调整这部分代码。

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