Azure 预发环境报 No 'Access-Control-Allow-Origin' 跨域问题排查求助

你观察到的CORS报错是结果，核心问题出在预发环境的OPTIONS预检请求返回了503 Service Unavailable，该响应由nginx层直接返回，请求根本没有传递到后端Express服务，所以你在Express代码、Azure应用服务层面配置的CORS规则都没有生效，响应头自然缺少Access-Control-Allow-Origin字段，触发浏览器跨域拦截。

可能的具体根因如下：

• Azure应用服务的Staging预发部署槽配置独立，你配置的CORS规则仅生效到生产槽，没有同步到预发槽
• 预发环境的应用服务没有正常启动，nginx反向代理找不到可用的上游服务，直接返回503
• 预发环境的nginx配置未放行OPTIONS类型的预检请求，直接拦截返回异常
• 预发环境配置的WAF、网络访问限制等规则拦截了OPTIONS预检请求

按以下优先级逐步排查：

1. 验证预发服务基础可用性
   用curl/postman直接调用预发接口的GET请求（跳过预检逻辑）：
   curl https://<webapp>-api-staging.azurewebsites.net/api/getstarted/plans?fetchExcluded=true
   如果返回异常，先进入Azure门户的预发部署槽页面，查看「日志流」「进程资源管理器」，确认Express服务进程正常运行，无启动报错、资源不足问题。

2. 核对预发槽CORS配置
   Azure应用服务的不同部署槽配置完全独立，生产槽的CORS规则不会自动同步到预发槽：切换到Staging预发槽的「CORS」配置页，确认规则和你截图的生产配置一致。
   注意：Azure应用服务层面配置CORS后，会自动覆盖代码中Express的cors()配置，二者保留一处即可，建议统一在Azure层面配置，避免代码环境差异导致的问题。

3. 修复nginx OPTIONS请求配置
   如果GET请求正常返回，仅OPTIONS请求返回503，说明nginx层拦截了预检请求：

• 如果是容器部署，修改镜像内的nginx配置，添加OPTIONS请求处理规则，示例如下：

if ($request_method = OPTIONS ) {
    add_header Access-Control-Allow-Origin *;
    add_header Access-Control-Allow-Methods 'GET, POST, OPTIONS, PUT, DELETE, PATCH';
    add_header Access-Control-Allow-Headers 'Authorization, Content-Type';
    return 204;
}

• 如果是用Azure App Service内置的Linux Node.js运行时，在项目根目录新建default.d文件夹，放入自定义nginx配置文件，部署时会自动覆盖默认规则。

4. 排查额外安全规则
   检查预发环境是否配置了Azure Front Door、WAF、IP白名单、VNet集成等网络规则，确认是否放行OPTIONS请求、是否允许前端静态站点的访问来源。

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