部署在IIS虚拟机上的Azure Functions CORS问题求助

针对你遇到的Preflight MissingAllowedOriginHeader和后续的PreflightInvalidStatus问题，核心原因是OPTIONS预检请求未被Azure Functions运行时正确处理，结合IIS的特性，按以下步骤排查修复：

一、修正host.json的CORS配置格式 #

本地开发的local.settings.json只在本地生效，部署后必须用host.json配置CORS，且注意格式不能直接写"cors": "*"，需用嵌套结构：

{
  "version": "2.0",
  "cors": {
    "allowedOrigins": ["*"],
    "supportCredentials": false
  }
}

supportCredentials设为false对应通配符*的场景，避免冲突。

二、让IIS允许OPTIONS请求被Functions运行时处理 #

IIS默认会拦截OPTIONS请求，需在web.config的<system.webServer>节点下添加配置，让OPTIONS请求流转到Functions运行时：

<handlers>
  <!-- 移除默认的OPTIONS处理器 -->
  <remove name="OPTIONSVerbHandler" />
  <!-- 添加允许OPTIONS的处理器，让Functions运行时处理 -->
  <add name="OPTIONSVerbHandler" path="*" verb="OPTIONS" modules="IsapiModule" scriptProcessor="%windir%\Microsoft.NET\Framework\v4.0.30319\aspnet_isapi.dll" resourceType="Unspecified" requireAccess="None" />
</handlers>

三、移除重复的CORS头配置 #

你之前添加的IIS自定义响应头、web.config中<httpProtocol>下的自定义头，会和Functions运行时生成的CORS头重复，导致浏览器报错。需：

• 删除IIS站点的Access-Control-Allow-Origin自定义响应头
• 删除web.config中<httpProtocol>下的CORS相关配置
• 删除web.config里的<cors>节点配置

四、排除OPTIONS请求的URL重写干扰 #

如果你的web.config有URL重写规则，需确保OPTIONS请求不被重写，添加排除条件：

<rewrite>
  <rules>
    <rule name="FunctionAppProxy" stopProcessing="true">
      <match url="(.*)" />
      <conditions>
        <!-- 排除OPTIONS请求被重写 -->
        <add input="{REQUEST_METHOD}" pattern="OPTIONS" negate="true" />
      </conditions>
      <action type="Rewrite" url="api/{R:1}" />
    </rule>
  </rules>
</rewrite>

（如果你的函数没有api前缀，调整url部分即可）

五、验证预检请求 #

用Postman手动发送OPTIONS请求到你的函数URL，检查响应：

• 状态码应为200或204
• 响应头需包含Access-Control-Allow-Origin: *、Access-Control-Allow-Methods、Access-Control-Allow-Headers

如果返回404/500，说明OPTIONS请求未正确路由到Functions运行时，检查web.config的handler配置和路由规则。

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