为API Gateway与Lambda代理集成的5XX响应添加CORS头部

嘿，这个问题我之前在项目里也碰到过！当Lambda执行出错崩溃、或者返回了不符合代理集成规范的响应时，API Gateway会直接返回自己生成的502 Bad Gateway错误，这时候你的Lambda里的CORS处理逻辑根本没机会运行，自然就缺失了Access-Control-Allow-Origin头，导致客户端跨域报错。下面给你几个靠谱的解决思路：

1. 在API Gateway层面配置兜底CORS（最省心的方案） #

既然Lambda挂了的时候没法返回CORS头，那就让API Gateway来兜底。这个配置不会影响正常请求的CORS头（因为代理集成下，Lambda返回的头优先级更高），只会在API Gateway自己生成错误响应时生效：

• 打开API Gateway控制台，找到你的目标API
• 选中根资源（/）或者需要覆盖的具体资源，点击顶部的Actions → Enable CORS
• 在配置界面填写：
  • 允许的Origin：可以填你的授权域名列表（用逗号分隔），开发环境临时用*也可以，但生产环境务必指定具体域名
  • 允许的Methods：勾选你需要的HTTP方法（比如GET/POST等）
  • 允许的Headers：填Content-Type等必要的请求头
  • 勾选Enable CORS and replace existing CORS headers
• 部署API到对应的阶段，之后API Gateway返回的所有错误响应（比如502、403、404）都会自动带上你配置的CORS头

2. 给Lambda加全局异常捕获（最可控的方案） #

确保Lambda哪怕抛出异常，也能返回符合规范的带CORS头的响应。以Node.js为例，用try/catch覆盖所有业务逻辑：

exports.handler = async (event) => {
  // 从请求头获取Origin，用于校验授权列表
  const requestOrigin = event.headers.origin || "";
  // 你的授权域名列表
  const allowedOrigins = ["https://your-domain-1.com", "https://your-domain-2.com"];
  // 匹配允许的Origin
  const corsOrigin = allowedOrigins.includes(requestOrigin) ? requestOrigin : "";

  try {
    // 这里放你的核心业务逻辑
    const result = await yourBusinessLogic(event);
    
    return {
      statusCode: 200,
      headers: {
        "Access-Control-Allow-Origin": corsOrigin,
        "Content-Type": "application/json"
      },
      body: JSON.stringify({ data: result })
    };
  } catch (error) {
    // 全局捕获所有异常，返回带CORS头的错误响应
    console.error("Lambda执行出错:", error);
    return {
      statusCode: 500,
      headers: {
        "Access-Control-Allow-Origin": corsOrigin,
        "Content-Type": "application/json"
      },
      body: JSON.stringify({ message: "服务内部出现错误，请稍后重试" })
    };
  }
};

注意：如果用的是其他语言（比如Python、Java），也要对应实现全局异常捕获逻辑，确保任何情况下都返回包含CORS头的响应。

3. 自定义API Gateway错误响应（最精细的方案） #

如果需要针对不同错误码（比如502、401）配置不同的CORS头或者错误信息，可以用API Gateway的自定义网关响应：

• 进入API Gateway控制台，找到你的API → 左侧菜单的Gateway Responses
• 找到对应的错误类型，比如DEFAULT_5XX（覆盖所有5XX系列错误，包括502）
• 点击Edit，在Response Headers里添加Access-Control-Allow-Origin，值可以填固定域名，或者用$context.request.origin动态获取请求的Origin（需要确保这个Origin在你的授权列表里，或者配合WAF等做校验）
• 保存后重新部署API，这样特定错误类型的响应就会自动带上配置的CORS头

额外注意点 #

• 生产环境不要用*作为Access-Control-Allow-Origin，最好动态匹配请求的Origin并校验授权列表，避免跨域安全风险
• 每次修改API Gateway配置后，一定要重新部署到对应的阶段，否则配置不会生效
• 如果Lambda返回的响应不符合代理集成规范（比如没有statusCode字段），API Gateway也会返回502错误，所以要确保Lambda的响应格式正确

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