CloudFront与API Gateway架构下带请求体的请求失败问题排查求助

我来帮你梳理下这个问题的排查方向和可能的解决方案，毕竟我之前也踩过CloudFront+API Gateway的类似坑😉

1. 先盯紧CloudFront行为的缓存策略——这大概率是核心问题 #

带请求体的PUT/POST请求默认属于不可缓存请求，如果你的CloudFront行为用了默认的缓存策略，CloudFront会直接拦截这类请求，返回“不支持该方法”的错误，哪怕你已经勾选了允许所有HTTP方法。

解决要点：

• 打开CloudFront分发的/api路径行为配置，把缓存策略改成Managed-CachingDisabled（CloudFront官方提供的禁用缓存策略），或者自定义一个缓存策略，设置“不缓存任何内容”。
• 同时确认“允许的HTTP方法”确实选了GET, HEAD, OPTIONS, PUT, POST, PATCH, DELETE（直接选“所有方法”更省心）。

2. 确认Origin Request Policy（请求策略）配置 #

CloudFront默认不会把请求体转发给Origin（也就是你的API Gateway），如果API Gateway需要读取请求体里的内容，必须配置对应的请求策略：

• 在CloudFront行为的“源请求策略”里，选择Managed-AllViewer策略，这个策略会转发所有请求头和请求体到Origin；
• 或者自定义一个策略，确保勾选了“转发请求体（适用于POST/PUT等方法）”的选项。

3. 验证API Gateway本身是否正常（绕开CloudFront测试） #

先排除API Gateway或者Lambda的问题：用curl或者Postman直接调用API Gateway的原生端点（比如https://xxx.execute-api.us-east-1.amazonaws.com/prod/api/something），发送带请求体的PUT请求：

curl -X PUT https://your-api-gateway-endpoint/api/something \
  -d '{"test": "payload"}' \
  -H "Content-Type: application/json"

如果这个请求能正常返回结果，那问题100%出在CloudFront配置上；如果也失败，再去检查API Gateway的路由集成、Lambda代码或者权限配置。

4. 检查API Gateway的日志（确认请求是否到达） #

如果绕开CloudFront测试正常，但通过CloudFront就失败，去API Gateway的阶段设置里开启CloudWatch日志，然后再发一次带请求体的PUT请求：

• 如果CloudWatch里没有这条请求的记录，说明CloudFront根本没把请求转发过来；
• 如果有记录，再看Lambda的日志，排查是不是Lambda处理请求体时出了问题。

5. 暂时禁用CloudFront的自定义错误页 #

你之前提到删除自定义错误页后得到了更明确的错误信息，建议排查期间暂时禁用所有自定义错误响应配置，避免错误提示被掩盖，方便看到真实的错误代码和原因。

6. 开启CloudFront实时日志（终极排查手段） #

如果前面的步骤都没找到问题，开启CloudFront的实时日志功能，它会记录每个请求的详细处理流程：包括请求方法、请求体大小、是否被缓存、Origin的响应状态、错误原因等。通过实时日志，你能精准定位到请求是在哪个环节被拦截的。

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