CNAME 指向另一个名称
CNAME 记录声明一个 DNS 名称是另一个名称的别名。它的值是主机名，而不是 IP 地址或完整网页 URL。要了解浏览器可以连接到哪里，请检查别名以及目标名称的地址记录。
CNAME 不会指示浏览器替换地址栏中的 URL。HTTP 重定向是独立的应用行为。当品牌域名指向托管平台，但仍需正确的主机名路由和有效证书时，这一区别很重要。
查询别名并跟踪实际应答
nslookup -type=CNAME www.example.com
nslookup -type=A www.example.com
nslookup -type=AAAA www.example.com
这些命令使用公共示例名称展示查询形式；它们并不保证该名称当前具有 CNAME。对于你控制的域名，请使用服务设置说明中提供的确切别名。
如果 CNAME 应答标识出一个目标，请将返回的名称复制到地址查询中。保留链中的每一步。一些 DNS 服务商通过返回扁平化的 A 或 AAAA 应答来实现类似别名的功能，因此没有 CNAME 本身并不能证明服务映射已损坏。
读取一个简短的示例链
| 名称 | 类型 | 值 |
|---|---|---|
| shop.example.com. | CNAME | edge.example.net. |
| edge.example.net. | A | 192.0.2.20 |
| edge.example.net. | AAAA | 2001:db8::20 |
这些文档名称和地址描述了一条虚构的链。第一行是别名关系；后两行是地址目的地。如果目标更改了地址而别名保持不变，后续解析会遵循目标当前发布的数据，但仍受缓存影响。
记录每条相关应答的 TTL。别名及其目标可能有不同的缓存生命周期。某一行旁显示的单个 TTL 并不保证每个客户端和每一步都会在相同时间刷新。
找到链中失败的环节
| 结果 | 调查 |
|---|---|
| 别名存在；目标报告 NXDOMAIN | 检查目标拼写以及服务是否仍拥有该名称 |
| 两个名称互相指回 | 通过授权的 DNS 变更流程移除循环 |
| 目标可解析；HTTPS 失败 | 检查证书、主机名映射和服务可用性 |
| 没有 CNAME；存在 A 或 AAAA 应答 | 检查预期是直接映射还是服务商扁平化映射 |
不要反复创建新别名来绕过缺失的上游目标。请与服务商确认正确的服务目的地。不要仅因发现悬空记录就声称拥有未使用的第三方主机名；应将问题报告给获得授权的所有者。 如果缺失的目标返回 NXDOMAIN，请先阅读 NXDOMAIN 排查指南，再修改别名。
编辑前检查记录共存
传统 CNAME 不能与 A 或 MX 等普通记录共享其所有者名称。区域顶点还需要 SOA 和 NS 数据，因此普通 CNAME 通常不适合放在该名称上。当需要区域顶点别名时，请按照 DNS 服务商记录的 apex-alias 机制操作。
将服务商特定的 ALIAS、ANAME 或扁平化行为与标准 CNAME 结果分开。公共查询可能只显示地址。在修改看似缺失的记录之前，请同时检查服务商配置和公共应答。
在 DNS 之后验证用户路径
在了解 DNS 链后，从受影响的环境打开预期的 HTTPS 主机名。确认该证书覆盖此主机名，且页面属于预期的网站。即使别名正确，如果域名验证未完成，也可能进入平台错误。
使用 Arcvenza NSLookup 获取独立的公共观测，并保留节点、查询模式、时间戳和记录类型。当 DNS 成功但服务器返回应用错误时，请参考 HTTP 错误指南。这样可以将修复放在故障发生的层级。
常见问题与下一步
CNAME 会创建 301 重定向吗？不会。请在 HTTP 层配置永久重定向。
为什么 DNS 控制面板显示别名，但查询显示地址？服务商可能会对答案进行扁平化。请核对其记录的行为和最终服务。从一个确切名称开始，跟踪每个返回的目标，然后再进行变更。
技术参考
RFC 1034: Domain names · RFC 1035: DNS records · Microsoft: nslookup
RFC 1034：域名 · RFC 1035：DNS 记录 · Microsoft：nslookup