Curl调用GraphQL正常，Insomnia/Postman请求返回403错误排查
Let's break down the likely issues here and walk through how to troubleshoot and fix them:
1. 请求方法不匹配（最常见）
你的curl命令用了-G参数，这意味着发送的是GET请求，并把query参数编码进了URL的查询字符串里。但Insomnia、Postman这类GraphQL客户端默认会发送POST请求，把查询内容放在请求体中。
如果你的AWS API Gateway端点只配置了接受GET请求（没开启POST支持），那么所有POST尝试都会被拦截，返回403错误。
验证方法：
在Insomnia/Postman里把请求方法切换为GET，然后像curl那样把query参数加到URL的查询字符串里：
- URL：
https://example.execute-api.us-east-1.amazonaws.com/dev/query - 查询参数：键为
query，值为{greeting(firstName: "Jeremy")}
如果这样能成功，那问题肯定就是请求方法不匹配了。
解决方法：
二选一即可：
- 去API Gateway配置里给
/query资源添加POST方法，确保它能正确集成你的Lambda函数； - 配置Insomnia/Postman对这个端点使用GET请求（和curl保持一致）。
2. CORS配置缺失
curl不会强制执行跨域资源共享（CORS）规则，但Insomnia/Postman这类工具经常会模拟浏览器的行为，包括发送预检OPTIONS请求来检查CORS权限。
如果你的API Gateway没有配置允许客户端来源的CORS规则，预检OPTIONS请求会失败并返回403，进而阻止后续的查询请求。
验证方法：
检查API Gateway中/query资源的CORS设置：
- 打开AWS控制台 > API Gateway > 你的API > Resources >
/query> Actions > Enable CORS - 确认设置里允许你使用的HTTP方法（GET/POST），并且包含正确的来源（测试阶段可以用
*）。
解决方法：
给API Gateway资源启用并配置CORS：
- 允许合适的方法（GET、POST、OPTIONS）；
- 设置允许的来源为客户端的具体域名，或者用
*（仅用于开发/测试环境）； - 别忘了把配置部署到你的阶段（不部署的话，修改不会生效）。
3. POST请求体格式错误
如果你在Insomnia/Postman里用POST请求，GraphQL要求请求体是一个包含query字段的合法JSON对象。常见错误包括：
- 没把
Content-Type头设置为application/json； - 直接把查询内容以纯文本形式发送，没有包裹成JSON对象。
验证方法：
在Postman/Insomnia中：
- 把请求方法设为POST；
- 设置
Content-Type头为application/json； - 请求体用原始JSON格式：
{"query": "{greeting(firstName: \"Jeremy\")}"}
发送请求后如果成功，说明问题就是POST格式不正确。
解决方法：
确保所有发送到GraphQL端点的POST请求都遵循正确的JSON格式，并且包含application/json的Content-Type头。
4. API Gateway授权/密钥配置
可能性较低，但值得排查：如果你的API Gateway阶段开启了API密钥认证，或者需要IAM权限，你的curl命令可能隐式使用了本地AWS配置里的凭证，但Insomnia/Postman没有携带这些凭证。
验证方法：
检查API Gateway阶段设置：
- 打开AWS控制台 > API Gateway > 你的API > Stages > dev > Settings
- 查看"API Key Required"选项——如果开启了，你需要在Insomnia/Postman的请求头里添加
x-api-key，值为有效的API密钥。
解决方法：
如果需要API密钥，在API Gateway里生成一个有效的密钥，把它关联到你的使用计划，然后在客户端工具的请求头里添加x-api-key: 你的密钥。
内容的提问来源于stack exchange，提问作者Nicolai Lissau
