.NET Core配置AllowAnyOrigin()后Azure部署仍出现CORS跨域问题求助

算力阿峰

2026-10-2

可能的故障原因排查

Azure应用服务层面CORS配置覆盖了代码规则
Azure App Service自带全局CORS处理模块，优先级高于你在.NET Core代码中写的CORS配置。请求到达应用进程之前，Azure前置网关就会处理CORS预检请求，如果Azure门户中你对应应用服务的「CORS」配置页没有允许你请求的源，或者开启了「启用访问控制凭据」和代码配置冲突，会直接返回跨域错误，不会走到你代码里的AllowAnyOrigin规则。你可以登录Azure门户查看应用服务的CORS配置，要么清空Azure层面的CORS规则让代码配置生效，要么在Azure层面配置允许的源。
CORS策略缺失请求方法、请求头允许配置
你当前的CORS配置只加了AllowAnyOrigin()，对于带自定义请求头、或者使用PUT/DELETE/PATCH等非简单请求的场景，浏览器会先发送OPTIONS预检请求，你需要额外补充允许方法和允许头的配置：

builder.AllowAnyOrigin()
       .AllowAnyMethod()
       .AllowAnyHeader();

认证凭据和允许任意源的配置冲突
如果你的请求带了身份凭据（比如前端请求设置了withCredentials: true、接口返回了Cookie），浏览器会禁止Access-Control-Allow-Origin为*的响应，即使你配置了AllowAnyOrigin()也会触发跨域错误。这种场景下你需要将AllowAnyOrigin()替换为WithOrigins("你的前端源地址")，同时追加AllowCredentials()配置。
非2xx响应未携带CORS头
如果你的接口返回了401/404/500等错误状态码，或者有全局异常中间件、授权中间件在CORS中间件执行完成前就短路返回了响应，会导致响应没有携带CORS相关头，浏览器也会判定为跨域错误。你可以检查是否有中间件顺序异常，或者在错误处理逻辑中手动补充CORS头。
HTTP/HTTPS协议混用问题
如果你的前端页面是HTTPS协议，直接请求的接口地址是HTTP协议，浏览器会触发混合内容拦截，表现和跨域错误类似，你需要确认前端和接口的协议统一。