AWS API Gateway与Lambda函数的CORS预检响应错误排查

1. 核对MOCK集成的响应模板配置 #

自动生成的OPTIONS MOCK方法，经常会出现响应头配置不全或模板缺失的问题：

• 必须确保Access-Control-Allow-Origin设为*（或你指定的源）
• 明确配置Access-Control-Allow-Methods，至少包含你的POST方法
• Access-Control-Allow-Headers要覆盖客户端实际发送的请求头（比如Content-Type、自定义头）
  控制台测试时API Gateway会用默认逻辑返回200，但部署后如果模板配置错误，直接触发500。

2. 务必重新部署API到对应阶段 #

这是最容易忽略的步骤：修改CORS或OPTIONS配置后，必须重新部署API到你的使用阶段（比如prod）。控制台测试是直接调用集成逻辑，不经过部署后的端点，所以能返回200，但客户端访问的是部署后的版本，没部署的话新配置完全不生效。

3. 查看CloudWatch日志定位具体错误 #

API Gateway的500错误有明确的日志记录：

• 进入API Gateway控制台，找到目标API，点击「监控」→「日志/跟踪」
• 开启日志记录（未开启的话先配置），然后重新触发客户端的OPTIONS请求
• 到CloudWatch对应日志组里找错误详情，比如模板解析失败、权限缺失等，直接定位问题根源

4. 手动重建OPTIONS方法（替代自动生成） #

自动生成的OPTIONS偶尔会有隐藏的配置冲突，手动创建更可靠：

• 删除自动生成的OPTIONS方法
• 手动添加OPTIONS方法，选择MOCK集成
• 在「集成响应」中添加以下响应头：
  • Access-Control-Allow-Origin: *
  • Access-Control-Allow-Methods: POST, OPTIONS
  • Access-Control-Allow-Headers: Content-Type, X-Amz-Date, Authorization, X-Api-Key
• 设置状态码为200，给常见的Content-Type（比如application/json）添加空的响应模板
• 重新部署API

5. 检查阶段变量或权限冲突 #

如果你的API使用了阶段变量，确认它没有干扰OPTIONS方法的响应逻辑；另外，虽然MOCK集成一般不需要特殊权限，但可以检查执行角色是否有apigateway:Invoke的基础权限，避免权限导致的隐性错误。

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