ASP.NET Core MVC中web.config<cors>标签与自定义Header配置CORS的区别

• 依赖组件不同
  <cors>标签配置依赖IIS官方的CORS模块，该模块不属于IIS默认预装组件，需要手动在服务器角色功能中安装才会生效。如果目标服务器未安装该模块，<cors>段的配置会直接失效，部分场景下还会触发IIS配置解析错误。
  <httpProtocol>下的customHeaders是IIS原生HTTP协议模块的自带功能，所有标准IIS部署环境默认支持，不需要额外安装任何组件，兼容性更强。

• CORS规范适配逻辑不同
  IIS的CORS模块完整实现了W3C CORS规范，会自动处理跨域预检（OPTIONS）请求，自动校验请求Origin、请求方法、请求头是否符合配置规则，仅在符合跨域规则的响应中添加对应的CORS头，不会出现冗余头字段。
  customHeaders属于静态硬加头逻辑，不管请求是否符合跨域规则、是不是跨域请求，都会在所有响应中固定插入配置的头字段。如果是复杂跨域请求，仅加Access-Control-Allow-Origin头还会触发预检失败，需要额外手动配置OPTIONS请求的响应规则、补充允许方法/允许头等其他CORS头才能正常工作。

• 和应用层配置的冲突表现不同
  如果你的ASP.NET Core应用本身已经通过中间件配置了CORS规则，IIS CORS模块会默认处理头冲突，不会出现重复的CORS响应头。
  而customHeaders配置会强制追加头字段，很容易出现响应中存在两个Access-Control-Allow-Origin头的问题，直接导致浏览器判定跨域请求失败。

• 扩展能力不同
  <cors>标签原生支持多Origin配置、允许携带凭据、限制允许的请求方法/请求头等复杂CORS规则，配置逻辑符合规范。
  customHeaders要实现上述复杂规则，必须配合IIS重写模块做动态Origin判断，配置复杂度高，容易出错。

你猜测的「部分服务器未安装IIS Cors模块」是两种配置表现不一致的最常见原因，未安装CORS模块的环境下<cors>配置完全不生效，自然不会返回CORS头，换成customHeaders后就能正常返回头字段，客户端跨域就能成功。

内容的提问来源于stack exchange，提问作者App-Devon