Azure应用网关下Springboot API报PreflightInvalidstatus跨域错误如何解决

PreflightInvalidStatus错误的本质是浏览器要求CORS预检OPTIONS请求必须返回2xx范围内的成功状态码，你当前只配置了CORS响应头的重写规则，没有处理后端宕机场景下OPTIONS请求的响应状态码，Azure应用网关默认会给无响应的后端返回502/503状态码，不符合浏览器要求，因此即使CORS头配置正确也会触发报错。

• 第一步：确认预检请求的实际返回状态
  用curl工具或者浏览器开发者工具的网络面板，抓取后端宕机时OPTIONS请求的完整响应：

  curl -v -X OPTIONS <你的API接口地址> \
  -H "Origin: <你的前端域名地址>" \
  -H "Access-Control-Request-Method: POST"
  

  如果返回状态码为502/503，即可证实是状态码不符合要求导致的问题。
• 第二步：新增OPTIONS请求的直接响应规则
  在Azure应用网关中新增优先级最高的路由规则，专门处理所有OPTIONS请求：
  1. 路由规则的匹配条件设为请求方法等于OPTIONS，匹配所有API路径
  2. 规则不需要转发到后端服务池，直接配置为自定义响应，返回状态码204（无内容）或者200
  3. 将你之前配置的所有CORS响应头绑定到这个自定义响应上
     注意：该规则优先级必须高于普通业务请求的转发规则，确保所有OPTIONS请求不会被转发到已经宕机的后端服务
• 第三步：校验CORS头配置有效性
  1. 确认Access-Control-Allow-Origin的取值正确：如果前端域名固定，建议直接写死允许的域名列表，比用{http_req_Origin}变量更稳定，避免异常场景下变量取值为空
  2. 确认Access-Control-Allow-Headers包含了前端实际请求会携带的所有自定义头，避免遗漏
• 第四步：验证全场景CORS逻辑
  主动停止后端Spring Boot服务，分别测试OPTIONS预检请求和普通业务请求的返回：

  预期结果：OPTIONS请求返回200/204状态码，所有CORS响应头完整；普通业务请求返回5xx状态码时也携带完整的CORS响应头，前端可以正常捕获到服务异常的信息。

• 如果开启了应用网关的WAF防护，需要检查WAF规则是否拦截了OPTIONS请求，拦截会返回非2xx状态码同样会触发该错误
• 不要将Access-Control-Allow-Origin设为通配符*，因为你配置了Access-Control-Allow-Credentials: true，该场景下通配符会被浏览器直接拒绝，必须返回具体的请求Origin值

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