Route53无法路由流量至CloudFront分发，请求排查配置问题

核心问题推测与验证点 #

• 裸域example.com的DNS记录未配置指向CloudFront
  你仅为www.example.com配置了A/AAAA记录，但example.com本身没有对应指向CloudFront的DNS记录。当前依赖S3桶重定向的方式存在问题：S3静态网站托管的裸域默认使用HTTP协议，且无法绑定你的自定义SSL证书，当用户访问https://example.com时，浏览器会因证书不匹配触发“连接不安全”提示，甚至因DNS解析未生效被ISP劫持跳转至其页面。
  解决：在Route 53中为example.com创建A/AAAA记录，同样映射到你的CloudFront分发ID，让裸域请求直接进入CloudFront链路。

• ACM证书验证记录需再次核对
  虽然证书显示“已颁发”，需确认手动添加的Route 53 CNAME记录完全符合要求：

  • 记录类型必须是CNAME
  • 记录名称必须完全匹配ACM提供的_longhash.example.com（包括开头的下划线）
  • 记录值必须完整复制ACM给出的目标CNAME，不能有字符遗漏或拼写错误

• CloudFront备用域名与证书绑定一致性检查
  确认CloudFront分发的**备用域名（CNAME）**列表中同时包含example.com和www.example.com，且选择的ACM证书确实覆盖这两个域名（你的证书包含example.com和*.example.com，理论上符合要求，但需确认分发配置中未选错证书）。

• S3重定向逻辑需迁移至CloudFront
  原有的S3裸域重定向建议改为在CloudFront中配置行为规则：

  1. 在CloudFront分发中添加针对example.com的行为
  2. 设置该行为的“重定向”规则，将请求重定向至https://www.example.com，保持HTTPS协议
     这样所有请求都通过CloudFront的SSL链路处理，避免S3 HTTP重定向带来的证书问题。

• DNS解析有效性验证
  使用dig example.com或nslookup example.com命令检查裸域的解析结果，确认返回的IP是CloudFront的边缘节点IP，而非S3或其他未知IP。若解析结果异常，需检查Route 53的记录配置是否正确，或确认域名的NS记录确实指向Route 53的服务器（你提到未修改NS/SOA，可再次核对注册商处的域名DNS服务器设置是否与Route 53提供的一致）。

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