Cloudfront含Authorization头的预检请求缺失CORS响应头求助

• 检查CloudFront响应头策略的适用范围

  • 确认响应头策略是否关联到了OPTIONS请求的缓存行为，很多时候容易只给GET/POST等业务请求配置，漏掉预检用的OPTIONS方法，导致这类请求触发不了头策略。
  • 核对缓存行为的路径模式，确保预检请求的路径能匹配到配置了该响应头策略的规则。

• 验证API Gateway自身的CORS配置

  • 绕开CloudFront直接调用API Gateway的OPTIONS端点，查看返回的响应头是否包含Access-Control-Allow-Headers: *或者明确列出authorization。如果API Gateway自身没允许这个头，可能会导致CloudFront的头策略无法生效（源站响应的优先级或覆盖逻辑问题）。

• 排查CloudFront缓存策略的影响

  • 你当前使用的AllViewerExceptHostHeader缓存策略，即便禁用了缓存，其请求头包含规则也会影响CloudFront是否转发特定头到源站。要确认该策略是否允许Access-Control-Request-Headers被转发到API Gateway——如果CloudFront没转发这个头，API Gateway无法识别预检请求需要处理Authorization，自然不会返回正确的CORS响应头。

• 检查CloudFront的Origin Request Policy（若已配置）

  • 如果用了自定义的Origin Request Policy，必须确保它包含Access-Control-Request-Headers、Access-Control-Request-Method这些预检请求的核心头。源站收不到这些头，就没法生成符合要求的CORS响应。

• 查看CloudFront日志定位问题

  • 开启CloudFront实时日志或访问日志，重点看带Authorization的预检请求对应的源站响应头：如果API Gateway本身就没返回CORS头，要先排查源站配置；如果源站返回了但CloudFront没添加自定义头，检查策略的匹配逻辑。
  • 日志里可以确认CloudFront是否应用了预期的响应头策略，有没有匹配失败的记录。

• 确认CORS响应头策略的配置细节

  • 检查Access-Control-Allow-Origin的<list>是否准确包含了前端请求的域名，有没有格式错误（比如多了斜杠、域名拼写错误）。
  • 确认响应头策略是强制添加自定义头的类型，而非仅修改源站已有头的策略，确保CloudFront会主动注入配置的CORS头。

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