API Gateway+Lambda请求含%的用户名时触发CORS跨域头缺失错误

核心问题在于：当路径中出现单独的%时，API Gateway会将其判定为无效的URL编码（合法的URL编码要求%后必须跟两位十六进制字符），直接返回400错误，但这个错误响应没有携带你配置的CORS头，导致前端报PreflightMissionAllowOriginHeader。本地环境因为没有严格的URL编码校验，所以能正常处理。

下面是具体解决步骤：

1. 关闭API Gateway的严格URL编码校验 #

进入API Gateway控制台，找到你的API：

• 进入对应**阶段（Stage）**的设置页面
• 找到API请求设置，关闭“URL编码验证”（不同版本控制台可能叫“Enable strict URL encoding”或类似选项）
• 保存后重新部署API，这样API Gateway就不会因为单独的%返回400错误了

2. 完善API Gateway的CORS配置 #

确保CORS配置覆盖所有请求场景，包括错误响应：

• 在对应的/api/user/{username}资源上，重新配置CORS：
  • 勾选“启用CORS”
  • 设置Access-Control-Allow-Origin为你的前端域名（测试阶段可以用*）
  • 勾选“Access-Control-Allow-Credentials”（因为你的请求带了自定义头user_id）
  • 在Access-Control-Allow-Headers里明确添加user_id（预飞请求会校验这个自定义头）
  • 确保Access-Control-Allow-Methods包含GET和OPTIONS
  • 部署API到对应阶段

3. 在Express代码中添加兜底CORS处理 #

即使API Gateway配置了CORS，Lambda里的Express也要确保所有响应（包括错误）都带CORS头：

// 在所有路由之前添加这个中间件
app.use((req, res, next) => {
  res.setHeader('Access-Control-Allow-Origin', '你的前端域名');
  res.setHeader('Access-Control-Allow-Headers', 'Origin, Content-Type, Accept, user_id');
  res.setHeader('Access-Control-Allow-Methods', 'GET, OPTIONS');
  res.setHeader('Access-Control-Allow-Credentials', 'true');
  
  // 直接响应OPTIONS预飞请求
  if (req.method === 'OPTIONS') {
    return res.sendStatus(200);
  }
  next();
});

4. 可选：前端对%进行合法编码 #

如果不想修改API Gateway的校验规则，可以让前端把路径中的%编码成%25（%的标准URL编码），这样请求路径变成xxx.com/api/user/userA%25，API Gateway会自动解析为userA%传递给Lambda，既符合URL规范，也不会触发错误。

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