Server 2012上.NET Core 2 API在Kestrel正常，IIS 7报400疑CORS问题

这种IIS部署后卡CORS 400错误的情况真的闹心，尤其是Kestrel直接跑dotnet XXXXX.dll完全正常，说明你的代码逻辑没问题，百分百是IIS的配置细节没踩对。结合你的描述，我帮你梳理几个最可能的问题点，按步骤排查应该能解决：

1. 清理全局与web.config的OPTIONS Handler冲突 #

你在IIS全局Handler Mappings里配置了OPTIONSVerbHandler并移到首位，但同时又在web.config里写了<remove name="OPTIONSVerbHandler"/>——这会让IIS处理OPTIONS请求时出现歧义。

解决方法：

• 直接删除IIS全局的OPTIONSVerbHandler配置，让AspNetCoreModule全权处理所有请求（包括OPTIONS）。毕竟你的API是.NET Core应用，不需要用传统的aspnet_isapi.dll来处理跨域预检请求。

2. 确认ASP.NET Core Module (ANCM) 版本匹配 #

.NET Core 2.x在IIS7上运行必须依赖ASP.NET Core Windows Server Hosting Bundle，如果你的Server 2012没装对应版本的组件，请求根本无法正确转发到Kestrel，进而引发400错误。

检查方法：

• 打开服务器的「程序和功能」，查看是否有「Microsoft ASP.NET Core 2.x Runtime - Windows Server Hosting」（x是你的具体版本，比如2.2）。如果没有，下载对应版本的Hosting Bundle安装，安装后重启IIS。

3. 调整应用池的32位兼容设置 #

默认情况下，.NET Core应用是64位的，如果你的应用池开启了「启用32位应用程序」，会导致进程启动异常，间接引发400错误。

解决方法：

• 打开应用池的「高级设置」，找到「启用32位应用程序」，设置为False，然后重启应用池。

4. 移除web.config中重复的CORS头配置 #

你已经在Startup.cs里通过代码配置了完整的CORS策略（AllowAnyOrigin、AllowAnyMethod、AllowCredentials），同时又在web.config的<customHeaders>里加了CORS相关头——这会导致响应头重复，浏览器会因为头规则冲突抛出400错误。

解决方法：

• 删除web.config中<httpProtocol>下的所有CORS自定义头，让代码里的CORS中间件来统一处理跨域响应头。修改后的web.config这部分应该是：

<httpProtocol>
</httpProtocol>

5. 修正网站的主机头绑定 #

你设置的主机头是localhost:55564，但前端部署在同一服务器的80端口，当前端发起跨域请求时，请求的Host头大概率是服务器的IP/域名，而非localhost，这会导致IIS因为主机头不匹配直接拒绝请求。

解决方法：

• 编辑网站的绑定设置，要么清空主机头，绑定到*:55564（允许所有IP的55564端口请求）；要么添加前端所在的域名/IP作为主机头，确保请求的Host头能匹配到这个网站。

6. 彻底禁用WebDAV模块 #

虽然你在web.config里remove了WebDAVModule，但有时候IIS全局的WebDAV还会偷偷生效，干扰OPTIONS请求处理。

额外验证：

• 打开网站的「模块」功能，确认WebDAVModule已经被移除；如果没移除，手动删除它。也可以在web.config的<modules>里加上<add name="WebDAVModule" lockItem="true" />来强制锁定禁用（不过先优先用remove的方式）。

最后验证步骤 #

做完以上配置后，重启IIS和应用池，然后：

• 用Postman/curl发起OPTIONS请求到你的API接口，看是否返回200状态码；
• 暂时把web.config里的stdoutLogEnabled设为true，查看logs目录下的stdout日志，看有没有启动或请求处理的错误信息——这能帮你快速定位剩余问题。

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