这里需要考虑两个独立但相互依赖的间接级别。第一个是 DNS 名称最终解析为的 IP 地址。第二个是该 IP 地址上的服务器所做的事情。
请记住，当您在浏览器中输入 URL 时，首先发生的事情是 DNS 查找。通常，这是由操作系统处理的，而不是浏览器本身。
所以你的浏览器会询问操作系统，“地址是什么？example.com？”操作系统将查找记录，如果得到CNAME, 会查找that记录，直到找到A记录。然后操作系统用答案响应浏览器。
然后，您的浏览器打开到该 IP 地址的 TCP 连接：
- 如果是 http:// URL，它将连接到端口 80，然后发出 HTTP 请求。
- 如果一个https:// URL，它连接到端口443，建立 TLS/SSL 连接（这意味着验证证书），then通过安全通道发出 HTTP 请求。
只有此时，HTTP 重定向才会发生。浏览器发送请求（GET /，服务器可以用 301 响应任何其他 URL。
了解注册商提供的“子域重定向”服务只不过是发出 301 的常规 HTTP 服务器。当您选择注册商的重定向选项时，他们只需设置A将您的域的顶点记录到他们控制的服务器，并且该服务器告诉浏览器转到www.example.com.
由于大多数注册商不允许您将 SSL 证书上传到他们的重定向服务器，因此浏览器无法与服务器建立必要的安全连接，因此它们从不发出 HTTP 请求。因此，请求https://example.com fail.
那么你为什么不能CNAME顶点？这是被禁止的。 http://www.ietf.org/rfc/rfc1034.txt
域系统使用规范名称提供了这样的功能
（CNAME) RR [记录资源]。 ACNAMERR 将其所有者名称标识为别名，并且
指定相应的规范名称RDATA的部分
RR。If a CNAMERR 存在于节点上，不应有其他数据
展示;这确保了规范名称及其别名的数据
不可能不同。该规则还确保缓存CNAME可
使用时无需与其他 RR 类型的权威服务器进行检查。
该规范要求CNAME记录是给定（子）域的唯一记录。这与拥有一个的要求不一致SOA记录在顶点。 （有一些努力来改变规格以允许CNAME and SOA共存，但仍然有许多损坏的 SMTP 实现会被CNAME在域上。）
您可以通过以下选项让 SSL 在 apex 上运行：
- 在重定向服务器上使用支持 SSL 的第三方服务。你可能会为此付出代价。这是一项服务。 http://wwwizer.com/ I 不会推荐此路线，因为它使您无法控制可靠性，并要求您将 SSL 证书的密钥移交给可能可信或不可信的人。
- 运行您自己的重定向服务器。由于顶点需要
A记录，您将需要一个静态 IP，而 Heroku 和 AWS 的 ELB 等服务不提供该静态 IP。因此，如果您处于云环境中，那么保证可靠性将非常困难（如果不是不可能的话）。从好的方面来说，您可以保留对 SSL 密钥的控制。
- 使用允许您设置 DNS 主机alias。将别名指向您的 Heroku 域/ELB/其他内容。这很可能是最好的选择。
An alias从技术上讲，它不是一种 DNS 记录。相反，它是 DNS 主机端的一个特殊配置，返回一个A记录来自另一次查找的结果。换句话说：
- 您的操作系统发出 DNS 请求example.com到您的 DNS 主机。
- 您的 DNS 主机读取内部别名配置，并向该域发出 DNS 请求。因此，如果您设置了别名example.herokuapp.com，它会查找
A该域的记录。
- DNS 主机返回一个简单的
A记录从别名查找中获得的 IP。
使用别名记录，您可以将您的顶点指向与您的顶点相同的云负载均衡器。www域是CNAMEd 至。假设您已在www域，裸域就可以正常工作。此时，您可以选择您的应用程序是否发出重定向，或者直接通过裸域提供您的内容。
