所以我继续修补这个。这是一个带有IIS 8.5的新Windows Server。我从来没有遇到任何问题让CORS在IIS中“正常工作”，所以我从来没有真正需要关心服务器配置中的繁琐位。立即解决的问题是猎枪方法;我通过对applicationhost.config
的以下修改在服务器范围内启用了CORS <customHeaders>
<add name="Access-Control-Allow-Origin" value="*" />
</customHeaders>
但是删除此customHeader并在我的控制器中设置[EnableCors(origins: "*",headers: "*", methods: "*")]不会导致服务器发回Access-Control-Allow-Origin响应标头（是的，我确保在{{1}中调用config.EnableCors() }。
另一个复杂因素是使用这种方法，我必须允许所有来源，因为我需要几个来源才能访问此服务器。浏览器实现不允许在此标头中从服务器发回多个源。我总是可以在我的应用程序中编写自己的HttpConfiguration逻辑，但宁愿理解并修复服务器配置以保留在res上。
所以我试图在我们的服务器配置团队直接在新的Windows Server 2012 R2上部署到IIS 8.5的Web应用程序时遇到了一些问题。我的应用程序是一个启用了Cors的Web API（目前允许所有来源），但服务器没有向调用客户端返回Access-Control-Allow-Origin标头。我从来没有遇到过Web API Cors“只是工作”的问题。
我找到了this资源，但确认已在我的应用程序的web.config中删除了OPTIONSVerbHandler。
我尝试将一个customHeader添加到IIS，但每当我这样做时，服务器就开始返回500秒。
我可以做些什么来强制 IIS 8.5从ASP.NET发送Access-Control-Allow-Origin标头？
所以我显然在我的解决方案中安装了ASP.NET Cross Origin Resource Sharing NuGet包，而不是ASP.NET Web API 2.2跨源资源共享NuGet包。我把这些换掉了，我的CORS功能有限（但仍然是意外的）。我将描述我现在遇到的奇怪现象。
所以在我意识到我有错误的NuGet包之前，我已经进入了applicationHost.config并添加了
EnableCors试图让服务器手动推回标头。没有NuGet更新，这确实不设置了预检响应的标题，但此时我不太确定这是否是由于我忘记了iisreset;我试图快速移动。
无论如何，当我添加<customHeaders>
<add name="Access-Control-Allow-Origin" value="*" />
</customHeaders>
NuGet包时，我的服务器响应开始发出带有通配符源的Web API 2.2 Cors标头，而不是我在Web API中的EnableCors属性中设置的标头路线。因此，使用该值，我知道它是配置的customHeader而不是现在控制该值的Access-Control-Allow-Origin。
（这里是奇怪的地方） 所以我实际上更愿意直接在服务器级别直接控制CORS白名单，所以我继续将customHeader设置为
EnableCorsAttribute其中<customHeaders>
<add name="Access-Control-Allow-Origin" value="http://segment.mydomain.com" />
</customHeaders>
也匹配API路径中允许的原点之一。
我现在在PreFlight请求中从IIS发回了正确的http://segment.mydomain.com，但随后的POST返回500.如果我从Api Route中删除Access-Control-Allow-Origin属性，则POST成功（已确认）通过直接查询持久发布数据的数据库）
...重量*？
因此，有希望的方法（在IIS中的customHeader中静态定义的起源而不是允许开发人员直接在控制器中列出其起源）实际上不起作用。我需要将多个来源列入白名单，Chrome的实现只允许在ACAO标题中设置一个来源。它也不允许在原点中使用通配符段，所以......太糟糕了。