为S3和EC2配置CloudFront后，api.example.com无法访问求助

我来帮你捋捋这个问题——这种多源CloudFront配置踩坑太常见了，咱们一步步拆解可能的问题：

1. 核心误区：CloudFront行为的路径模式配置错误 #

你提到“添加路径匹配为api.example.com/*的行为”，这大概率是问题根源！CloudFront的路径模式是指请求的路径部分（不包含域名）。比如访问https://api.example.com/get-data，实际路径是/get-data，所以你需要把行为的路径模式设为/*，然后在该行为的「关联的备用域名」里选择api.example.com，这样所有指向api.example.com的请求才会匹配到这个EC2源的行为。

如果路径模式写成api.example.com/*，只有当请求路径是/api.example.com/xxx时才会触发这个行为，显然不是你想要的效果，导致所有api.example.com的请求还是走默认的S3源，自然报错。

2. 检查EC2源的基础连通性 #

先排除EC2本身的问题：

• 直接访问EC2的公网地址（比如http://ec2-IP.AWS_REGION.compute.amazonaws.com:3000，注意加上Node.js服务的端口），看能不能正常返回API响应。如果不行，先把EC2上的Node.js服务调试好，确保公网可访问。
• 检查EC2安全组：允许CloudFront的边缘节点访问对应端口（比如3000）。测试环境可以直接设置安全组入站规则允许0.0.0.0/0访问目标端口；生产环境推荐参考AWS文档添加CloudFront的官方IP段。
• 源配置的端口和协议：如果Node.js监听在非80/443端口（比如3000），一定要在CloudFront的EC2源配置里填写「自定义源端口」为3000，同时选择对应的「源协议策略」：如果Node.js用HTTP，选「仅HTTP」；如果配了SSL证书，选「仅HTTPS」。

3. 缓存行为的请求头传递设置 #

Node.js API通常需要接收请求头（比如Authorization、Cookie、Content-Type），如果CloudFront没有传递这些头，可能导致API无法正常处理请求：

• 在该EC2源对应的行为里，找到「缓存键和源请求」→「请求头」，选择「包含以下请求头」，然后添加API需要的所有头（比如Authorization、Cookie、Content-Type等）。
• 你已经把TTL设为0，这没问题，但要确保「缓存策略」是「自定义策略」且禁用了缓存，或者直接用「无缓存」的内置策略。

4. 验证CloudFront的备用域名和证书配置 #

• 确认CloudFront分发的「备用域名(CNAMEs)」里确实包含api.example.com和example.com，且使用的ACM证书覆盖了这两个域名。
• 重点：CloudFront只能使用us-east-1（弗吉尼亚北部）区域的ACM证书，哪怕你的EC2和S3在其他区域！如果你的证书是在其他区域申请的，需要重新在us-east-1申请一份。

5. 检查Route 53的别名记录 #

确保api.example.com的别名记录确实指向了正确的CloudFront分发，并且记录类型是A或AAAA（别名），而不是CNAME（虽然CNAME也能工作，但别名记录更推荐，因为CloudFront是全球分布式的，别名记录支持IPv6）。

6. 查看CloudFront的访问日志 #

如果以上都没问题，开启CloudFront的访问日志（存储到S3桶），查看api.example.com的请求日志，里面会包含错误码、请求路径、源响应等信息，能帮你定位具体是哪里出了问题。

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