Azure托管REST API部署后POST报CORS错误 本地正常策略已失效

你提到的POST请求报错截图如下：

你碰到的“GET请求正常、POST请求跨域报错”是Azure托管API场景下最典型的多层CORS配置冲突问题，核心是跨域处理的逻辑在多个层重复配置、拦截顺序不对，导致预检请求没被正确处理，可按以下步骤逐项排查修复：

1. 优先解决双重CORS头的核心冲突 #

浏览器对CORS的校验非常严格：只要响应里出现多组重复的Access-Control-Allow-Origin头，不管头的值是否合规，都会直接判定跨域失败。
你目前的架构里同时在两个位置做了跨域配置：

• 后端ASP.NET Core应用的Startup.cs里配置了CORS策略
• Azure API Management（APIM）的全局策略里也写了CORS规则
  两者对同一次请求的响应都会追加CORS头，最终就会出现头重复的问题。因为GET属于“简单跨域请求”，不会触发预检流程，就算有重复头部分场景下浏览器可能不会拦截，但POST请求只要带了非text/plain的Content-Type、自定义请求头，就会先发OPTIONS预检请求，这时候重复头的问题就会直接暴露。

修复方式二选一，不要两边同时开：

• 如果所有请求都经过APIM网关转发到后端：直接删掉后端Startup.cs里所有CORS相关代码，包括services.AddCors(...)的注册逻辑、app.UseCors(...)的管道调用，完全交给APIM层统一处理跨域。这种方式的好处是APIM会直接拦截并处理所有OPTIONS预检请求，不会把预检请求转发到后端造成404/405错误。
• 如果是直接把后端部署在App Service、没有用APIM网关：那就删掉所有APIM层的CORS策略，只保留后端的CORS配置，同时确保app.UseCors("CorsPolicy")的管道位置在app.UseRouting()之后、app.UseAuthorization()之前，位置错了中间件是不会生效的。

2. 修正APIM层CORS策略的配置缺陷 #

你目前贴的全局CORS策略漏了最关键的一个配置，这也是POST请求报错的直接原因：
在<cors>标签上没有显式打开handle-preflight-Requests="true"参数。这个参数默认不会自动拦截处理OPTIONS预检请求，所有OPTIONS请求会直接被转发到后端，后端如果没有专门处理OPTIONS的接口，就会返回方法不允许的错误，触发浏览器CORS报错。

修正后的全局入站CORS策略示例：

<policies>
    <inbound>
        <base />
        <cors handle-preflight-Requests="true">
            <allowed-origins>
                <origin>*</origin>
            </allowed-origins>
            <allowed-methods preflight-result-max-age="300">
                <method>GET</method>
                <method>POST</method>
                <method>PUT</method>
                <method>DELETE</method>
                <method>HEAD</method>
                <method>OPTIONS</method>
                <method>PATCH</method>
            </allowed-methods>
            <allowed-headers>
                <header>*</header>
            </allowed-headers>
            <expose-headers>
                <header>*</header>
            </expose-headers>
        </cors>
    </inbound>
    <backend>
        <forward-request />
    </backend>
    <outbound />
    <on-error />
</policies>

配置时要注意两个细节：

• 入站规则开头一定要加上<base />，不然会覆盖掉上层继承的所有策略，这也是之前你在单个API上配CORS不生效的常见原因——全局策略没有留继承入口，下层的配置根本不会被执行。
• 如果你在CORS配置里加了allow-credentials="true"（允许携带Cookie的跨域请求），就不能用通配符*作为允许的源，必须把交互式控制台的具体域名写进<allowed-origins>里，否则浏览器会直接报错。

3. 排查App Service内置CORS的干扰 #

如果你的后端API是直接部署在Azure App Service上的，哪怕你用了APIM做网关，App Service本身也有一层内置的CORS配置（在App Service侧边栏的「CORS」设置页）：

• 如果这里之前配置过跨域规则，会和其他层的CORS配置冲突，给响应额外追加重复的头。
• 建议直接把App Service内置CORS页的所有规则清空，跨域逻辑全部交给APIM层处理，避免多层重复配置。

4. 配置完的验证方法 #

改完所有配置后，不需要打开浏览器测试，可以直接用curl发模拟预检请求验证响应头：

curl -i -X OPTIONS "https://你的API域名/api/pets" \
  -H "Origin: https://你的交互式控制台域名" \
  -H "Access-Control-Request-Method: POST" \
  -H "Access-Control-Request-Headers: content-type"

只要返回结果里没有重复的Access-Control-Allow-*头、对应的方法和源都在允许列表里，浏览器端的CORS报错就会消失。

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