AWS CDK配置API Gateway CORS后仍遇跨域错误，如何排查解决

数据老陈

2026-8-19

AWS CDK配置API Gateway CORS后仍出现跨域错误

我正尝试通过AWS CDK创建API Gateway REST API，代码如下：

const api = new RestApi(scope, "MyProjectBackendAPI", {
  restApiName: "my-project-backend-api",
  deployOptions: {
    stageName: stage
  },
  defaultCorsPreflightOptions: {
    allowMethods: ['OPTIONS', 'POST'],
    allowOrigins: ['https://myproject.app', 'http://localhost:8080'],
  },
  domainName: {
    domainName: 'api.myproject.app',
    certificate: cert,
    basePath: stage == 'prod' ? '' : stage
  },
  disableExecuteApiEndpoint: true
});

我已按照相关指引启用了CORS，但从http://localhost:8080或myproject.app发起POST请求时，浏览器控制台仍出现如下CORS错误：

Access to fetch at 'https://api.myproject.app/beta/oauth' from origin 'http://localhost:8080' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource. If an opaque response serves your needs, set the request's mode to 'no-cors' to fetch the resource with CORS disabled.
VM6:1

POST https://api.myproject.app/beta/oauth net::ERR_FAILED 200

我看到部分回答指出需在Lambda中返回CORS头，但也有说法称仅CDK配置OPTIONS方法即可，对此我感到困惑。我还尝试过使用

allowMethods: Cors.ALL_METHODS,
allowOrigins: Cors.ALL_ORIGINS

甚至移除defaultCorsPreflightOptions属性，但仍出现跨域错误。请问我遗漏了什么？

核心原因：CORS预检与实际请求的区别

你遇到的问题核心在于API Gateway的defaultCorsPreflightOptions仅处理OPTIONS预检请求，而实际的POST请求（以及其他非OPTIONS请求）的CORS响应头，必须由后端（比如你的Lambda函数）返回。

具体解释：

OPTIONS预检请求：浏览器在发送跨域POST/PUT等非简单请求前，会先发送OPTIONS请求验证跨域权限。defaultCorsPreflightOptions用于配置API Gateway自动处理这个OPTIONS请求的响应头，确保预检通过。
实际业务请求（POST）：预检通过后，浏览器发送实际的POST请求，此时API Gateway不会自动添加Access-Control-Allow-Origin等CORS头，必须由后端Lambda函数在返回结果时主动包含这些头信息。

解决方案：

1. 让Lambda返回正确的CORS头

在你的Lambda处理函数中，返回的响应必须包含CORS相关头：

exports.handler = async (event) => {
  // 可以根据请求的origin动态返回，更灵活
  const allowedOrigins = ['https://myproject.app', 'http://localhost:8080'];
  const requestOrigin = event.headers.origin || '';
  const allowOrigin = allowedOrigins.includes(requestOrigin) ? requestOrigin : allowedOrigins[0];

  const response = {
    statusCode: 200,
    headers: {
      "Access-Control-Allow-Origin": allowOrigin,
      "Access-Control-Allow-Methods": "OPTIONS, POST",
      "Access-Control-Allow-Headers": "Content-Type" // 根据实际请求头需求调整
    },
    body: JSON.stringify("请求处理成功")
  };
  return response;
};

2. 检查API Gateway集成配置

确保你的API资源（如/beta/oauth）使用了Lambda代理集成，这种模式下API Gateway会直接传递Lambda返回的响应头，无需额外配置。如果是非代理集成，需要在集成响应中手动配置CORS头（代理集成更常用且简洁）。

3. 验证CDK配置的有效性

你的defaultCorsPreflightOptions配置本身没问题，但要注意：

该配置会自动为所有通过CDKaddResource/addMethod创建的资源添加OPTIONS方法处理，但不会影响其他方法的响应头。
如果是手动创建的API资源，需要确保它们继承了默认的CORS配置。

常见误区澄清

说法“仅CDK配置OPTIONS方法即可”仅针对预检请求的处理，实际业务请求仍需要后端返回CORS头，两者缺一不可。
即使设置Cors.ALL_ORIGINS，如果后端不返回Access-Control-Allow-Origin头，实际请求依然会报错——这个头是浏览器验证跨域的核心依据。

内容的提问来源于stack exchange，提问作者Nolan B.

AWS CDK配置API Gateway CORS后仍遇跨域错误，如何排查解决

核心原因：CORS预检与实际请求的区别 #

具体解释： #

解决方案： #