CloudFront与Elastic Beanstalk间SSL配置问题求助（爱尔兰区域）

兄弟，我太懂你在这套架构上折腾的痛苦了——CloudFront、Elastic Beanstalk（EB）加Route 53搭HTTPS链路，细节多到让人崩溃。结合你已经完成的操作，我给你列几个最容易卡壳的坑和对应的解决办法：

一、CloudFront源配置的核心细节 #

• 源协议策略必须选「HTTPS only」：你的EB已经启用了HTTPS，CloudFront和EB之间必须用纯HTTPS通信，别选「HTTP and HTTPS」，不然很容易出现混合内容错误或者证书不匹配的问题。
• 确认源域名能正常HTTPS访问：你填的xxxxxxxx.eu-west-1.elasticbeanstalk.com是对的，但先手动用浏览器打开这个地址，确保没有证书警告或访问错误——如果EB本身的HTTPS就有问题，CloudFront肯定也跑不通。
• 自定义Origin ID尽量清晰命名：比如叫EB-EU-WEST-1-Origin，后续配置行为时能快速关联，避免搞混。

二、CloudFront行为（Behavior）必改配置 #

• Viewer Protocol Policy设为「Redirect HTTP to HTTPS」：强制所有用户走HTTPS，彻底杜绝HTTP请求带来的安全和兼容问题。
• Allowed HTTP Methods要包含OPTIONS：如果你的EB应用有前端API请求，跨域预检会用到OPTIONS方法，默认配置可能没开，这会直接导致前端请求失败。
• 动态应用别用默认缓存策略：如果是PHP、Node.js这类动态应用，建议选「Managed-CachingDisabled」或者自定义缓存策略，只缓存CSS、JS这类静态资源，不然动态内容会被CloudFront缓存，导致更新不及时。

三、ACM证书的致命区域坑！ #

你在eu-west-1创建的证书只能给EB用！CloudFront有个硬性要求：它只认us-east-1（弗吉尼亚）区域创建的ACM证书，哪怕你的所有资源都在爱尔兰。所以你必须去us-east-1区域再创建一份包含xyz.com和*.xyz.com的SSL证书，然后在CloudFront分发的「自定义SSL证书」选项里选这份新证书——这是90%的人都会踩的大坑！

四、Route 53 DNS记录的正确姿势 #

• 别直接指向EB地址：必须把域名指向CloudFront的分发域名（比如d123456abcdef.cloudfront.net）。
• 用Alias记录而非CNAME：Route 53的Alias记录会自动关联CloudFront，不仅支持根域名（xyz.com）解析（CNAME做不到），还能自动更新CloudFront的IP变化，比CNAME稳定得多。记录类型选A（IPv4）或AAAA（IPv6），然后开启「Alias」选项，目标选你的CloudFront分发。
• TTL设为300秒：默认值就行，后续修改DNS时能快速生效，减少等待时间。

五、EB安全组与负载均衡的收尾检查 #

• EB负载安全组要允许HTTPS流量：CloudFront的IP范围很大，你可以直接允许所有443端口的入站流量，或者用AWS的服务前缀cloudfront.amazonaws.com来配置安全组规则（需要在安全组里用条件语句指定源为这个服务）。
• 确认EB负载均衡监听器配置正确：检查443端口是否已经关联了你在eu-west-1创建的ACM证书，并且正确转发到EB实例的80或443端口（如果实例本身也配置了证书的话）。

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