Lambda返回合规CORS策略，客户端仍触发Access-Control-Allow-Origin错误

问题描述 #

我尝试用以下jQuery AJAX代码调用一个配置了GET和OPTIONS响应的Lambda API端点：

$.ajax({ 
  url: 'https://3yphvgt4dc.execute-api.us-west-2.amazonaws.com/test-cors/get-courses', 
  type: "GET", 
  headers: { 
    'iSCourse': 'False', 
    'Name': 'Ruth Anderson' 
  }, 
  success: function(result) { 
    console.log(result); 
  } 
});

但每次从http://127.0.0.1:8080发起请求时，都会收到CORS错误：

Access to XMLHttpRequest at 'https://3yphvgt4dc.execute-api.us-west-2.amazonaws.com/test-cors/get-courses' from origin 'http://127.0.0.1:8080' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource.

奇怪的是，Chrome网络调试器显示OPTIONS预请求已经返回了access-control-allow-origin: *，但GET请求还是报错，实在找不到原因，求排查思路。

排查与解决思路 #

我之前也碰到过类似的坑，给你几个具体的排查方向：

• 重点检查GET请求的响应头：
  很多人会忽略一点：OPTIONS预请求的头没问题不代表实际GET请求的头也正确。你需要在Chrome网络面板里找到GET请求的响应头，确认是否存在Access-Control-Allow-Origin字段。如果没有，那问题就出在这儿——你可能只配置了OPTIONS方法的CORS头，忘了给GET方法也加上。

• 处理自定义请求头的CORS配置：
  你的请求里带了iSCourse和Name这两个自定义头，这会触发浏览器的复杂CORS请求。这种情况下，API Gateway的OPTIONS响应里不仅要有Access-Control-Allow-Origin: *，还必须添加Access-Control-Allow-Headers头，值要包含你用到的所有自定义头（比如iSCourse,Name）。如果OPTIONS响应缺了这个字段，浏览器会直接拒绝后续的GET请求。

• 用API Gateway的一键CORS配置：
  手动配置单个方法的CORS很容易遗漏细节，建议直接在API Gateway的对应资源（比如/get-courses）上点击Enable CORS按钮，它会自动帮你配置好OPTIONS方法的集成响应、设置正确的响应头，同时也会给其他方法（比如GET）添加上必要的CORS头，避免手动配置的疏漏。

• 确认Lambda函数的响应头：
  如果你的Lambda函数直接返回响应内容，记得在返回结果里显式包含CORS相关的头。比如Node.js的Lambda可以这么写：

  exports.handler = async (event) => {
    const response = {
      statusCode: 200,
      headers: {
        'Access-Control-Allow-Origin': '*',
        'Access-Control-Allow-Headers': 'iSCourse,Name'
      },
      body: JSON.stringify({ courses: [] })
    };
    return response;
  };
  

  要是用了API Gateway的集成响应模板，也要确保在GET方法的集成响应里添加了这些头。

• 清除浏览器缓存测试：
  有时候浏览器会缓存旧的CORS响应，导致新的配置不生效。可以试试用无痕模式打开页面测试，或者手动清除浏览器缓存后再发起请求。

内容的提问来源于stack exchange，提问作者J.Doe