本地测试AWS API Gateway时遭遇CORS跨域问题

Access to fetch at 'invoke url' from origin 'http://localhost:3000' has been blocked by CORS policy: Response to preflight request doesn't pass access control check: It does not have HTTP ok status.

问题背景 #

我最近在测试前端通过AWS API Gateway调用Lambda上传文件到S3的流程时，碰到了上面这个CORS报错。我已经做了以下配置，但问题仍未解决，想问问有没有其他排查方向：

• 确认API Gateway的每个方法请求和集成请求里都配置了正确的URL路径参数
• 在前端和后端代码里都配置了CORS相关内容

排查建议 #

兄弟，这个报错的核心是预检OPTIONS请求没有返回成功状态码，这和常规的CORS头配置不全还不太一样，大概率是预检请求本身就没正常走通。给你几个我踩过坑的排查点：

1. 重点检查OPTIONS方法的配置
   很多人只在POST这类业务方法里加CORS头，但完全忽略了预检用的OPTIONS方法。你得确保：

   • 你的API Gateway路径下专门创建了OPTIONS方法
   • 这个方法的集成请求要设为MOCK模式（不需要走Lambda，直接返回成功响应）
   • 在方法响应里必须配置全这些头：
     • Access-Control-Allow-Origin：测试阶段可以设为http://localhost:3000，别直接用*（生产环境再按需调整）
     • Access-Control-Allow-Headers：要包含你前端请求里带的所有头，比如Content-Type、自定义头也得加上，别漏
     • Access-Control-Allow-Methods：要包含你实际使用的业务方法，比如POST、PUT等

2. 验证OPTIONS请求的实际响应
   你可以直接在API Gateway控制台的测试功能里，发起OPTIONS请求到你的目标路径，看返回的状态码是不是200，响应头里有没有正确带上上面说的CORS头。如果这里返回的是4xx/5xx，那前端肯定会报这个错。

3. 别漏了重新部署API
   这是最容易犯的低级错误！改完API Gateway的任何配置后，一定要重新部署到对应的阶段（比如dev），不然你的配置根本没生效，前端请求的还是旧的配置。

4. 检查Lambda的异常情况（如果OPTIONS走了Lambda）
   要是你不小心把OPTIONS方法也集成到Lambda了，那得检查Lambda代码是不是在处理OPTIONS时抛出了错误，或者返回了非200的状态码。比如Lambda权限不足、代码逻辑报错，都会导致预检请求失败。

5. 确认请求路径完全匹配
   你说已经配置了路径参数，那要仔细核对前端的请求路径和API Gateway里定义的路径是不是完全一致。比如API里是/upload/{fileKey}，你前端请求的是/upload，那会匹配不到对应的方法，返回404，预检自然失败。

备注：内容来源于stack exchange，提问作者CamBlue