配置关联Lambda的边缘优化自定义域名API Gateway返回Bad Request求助

我之前也碰到过几乎一模一样的问题，当时折腾了好一会儿才找到根源，给你列几个最可能的排查方向，按顺序试应该能解决：

1. 检查API Gateway自定义域名的基础路径映射 #

• 登录AWS控制台，进入API Gateway，找到你的边缘优化类型自定义域名配置。
• 务必确认已经添加了基础路径映射，把自定义域名的根路径（或你需要的路径）关联到正确的API和prod阶段。
• 这里最容易踩坑：如果没配置映射，CloudFront转发请求到API Gateway时，API Gateway找不到对应的服务阶段，直接就会返回Bad Request。

2. 验证CloudFront缓存行为的Host头转发设置 #

• 打开CloudFront控制台，找到对应的分发，进入行为标签页，编辑默认行为（或你配置的对应路径行为）。
• 重点看缓存键和源请求部分：
  • 确保没有手动添加Host自定义标头；如果确实需要添加，值必须是API Gateway的原始执行域名（****.execute-api.****.amazonaws.com）。
  • 另外检查源请求策略，确认策略包含了Host头的转发，或者自定义策略里正确把请求的Host头（或API Gateway的原始域名）转发给源服务。
• 这是最常见的故障点：当用自定义域名访问时，如果CloudFront把api.****.com作为Host头发给API Gateway，但API Gateway并没有把这个自定义域名配置为它的有效域名，就会触发“伪造Host头”的错误。

3. 确认API Gateway自定义域名的证书配置 #

• 检查你在API Gateway自定义域名中使用的ACM证书：
  • 必须覆盖你的自定义域名api.****.com；
  • 证书必须部署在**us-east-1（弗吉尼亚北部）**区域（因为边缘优化域名依赖CloudFront，而CloudFront只能使用us-east-1区域的ACM证书）。
• 证书不匹配或区域错误，会导致请求转发过程中出现头部异常，间接引发Bad Request。

4. 验证DNS解析和CloudFront分发状态 #

• 虽然你说DNS的CNAME看起来正常，还是可以用命令行确认解析是否正确：

  dig api.****.com
  

  确保返回的是CloudFront分发的域名****.cloudfront.net。
• 同时确认CloudFront分发的状态是已部署（Deployed），如果显示“正在部署”，需要等待10-15分钟让配置全局生效。

5. 排查WAF或其他拦截规则 #

• 如果你给CloudFront或API Gateway配置了WAF，检查是否有规则拦截了Host头不符合预期的请求。
• 可以临时禁用WAF测试：如果禁用后请求正常，那就是WAF规则的问题，需要调整规则允许自定义域名的Host头。

快速定位的小技巧 #

• 用curl命令带上-v参数，查看详细的请求和响应头：

  curl -v https://api.****.com/prod
  curl -v https://****.cloudfront.net/prod
  

  对比原始API URL的请求头，看看Host头的差异，这能快速帮你定位问题核心。

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