从Railway托管API调用AWS Lambda触发CloudFront 403错误

核心矛盾：Postman直连Lambda API正常，但WebSocket应用发起的请求触发CloudFront 403，说明问题出在请求经过CloudFront时的配置，或WebSocket环境与Postman的请求差异。

第一步：确认API_URL的实际指向 #

检查API_URL配置值：

• 如果是CloudFront分发域名（格式类似https://dxxxxxx.cloudfront.net）：说明请求确实走了CloudFront，问题出在CloudFront配置。
• 如果是API Gateway原生域名（格式类似https://xxxx.execute-api.<region>.amazonaws.com）：大概率是API Gateway的边缘优化端点自带了CloudFront，此CloudFront为AWS默认配置。

CloudFront配置修复方案 #

1. 源配置检查 #

• 确保CloudFront的源指向正确的API Gateway端点，无域名或路径错误。
• 若使用Origin Access Control（OAC）：验证OAC已授权CloudFront访问API Gateway，否则会因CloudFront无法拉取源内容返回403。

2. 请求头传递配置 #

WebSocket应用的请求需传递Authorization等自定义头，但CloudFront默认不会传递所有头：

• 进入CloudFront分发的缓存策略，将Authorization头添加到「包含的请求头」列表，确保CloudFront将其传递给API Gateway。
• 若无需缓存该GET请求，可设置缓存策略为「不缓存」，避免头被过滤。

3. WAF拦截规则检查 #

• 查看CloudFront关联的WAF Web ACL，确认无规则拦截WebSocket应用的请求IP或特征（如特定User-Agent）。
• 查看WAF日志，确认是否有匹配的拦截记录。

4. 跳过CloudFront（可选） #

若不需要CloudFront的加速/防护功能，直接使用API Gateway的区域端点（创建API时选择区域类型而非边缘优化），请求将不经过CloudFront，可绕过当前403问题。

API Gateway与请求本身修复方案 #

1. 验证CORS配置 #

• 确保API Gateway的CORS配置中，允许的Origin包含WebSocket应用的完整域名（如Railway分配的https://<your-app>.railway.app），不要使用通配符*（带Authorization头时通配符失效）。
• 确认CORS允许GET方法和Authorization头。

2. 检查请求头格式 #

代码中Authorization直接使用user.token，确认token是否需要带Bearer前缀：

Authorization: `Bearer ${user.token}`,

Postman可能自动添加了前缀，但代码中缺失会导致API授权失败，最终通过CloudFront返回403。

3. 调试请求差异 #

• 在Railway的WebSocket应用容器中，用curl模拟axios调用：

curl -H "Content-Type: application/json" -H "Authorization: <your-token>" <API_URL>/rooms

排查是否为代码封装导致的问题。

• 开启API Gateway执行日志，查看请求是否到达API Gateway，以及授权阶段的具体错误信息。

补充：CloudFront的作用 #

CloudFront是AWS的CDN服务，核心功能包括：

• 加速全球用户请求访问速度
• 提供缓存减少源站压力
• 集成WAF实现Web防护
• 统一管理HTTPS证书

若不需要这些功能，直接使用API Gateway的区域端点即可，无需配置CloudFront。

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