CNAME 解析详解：生效时间、TTL 与常见坑

CNAME 是什么？

CNAME（Canonical Name）是 DNS 中的"别名记录"：它不直接指向 IP，而是指向另一个域名。 接入 CDN 时，你把自己的域名 CNAME 到平台分配的接入点（如xxxxxxxx.ap.qedge.top），之后解析的控制权就交给了 CDN 的调度系统—— 不同地区的用户查询同一个域名，会拿到不同的、离自己最近的节点 IP。

这也是 CDN 不让你直接填 A 记录的原因：A 记录是静态的一个 IP，无法做智能调度与节点切换。

一次 CNAME 解析的完整链路

1. 用户浏览器询问 Local DNS：www.example.com 的 IP 是什么？
2. Local DNS 查询你的权威 DNS，得到答案："它是 xxxxxxxx.ap.qedge.top 的别名"；
3. Local DNS 继续查询 xxxxxxxx.ap.qedge.top，到达 CDN 的调度系统；
4. 调度系统根据 Local DNS 的位置（及 ECS 信息）返回最优边缘节点的 IP。

TTL 与生效时间

TTL（Time To Live）决定一条 DNS 记录在各级缓存中的存活时间。修改 CNAME 后并不是立即全网生效—— 各地 Local DNS 会等自己缓存的旧记录过期后才重新查询。实践建议：

• 切换前：提前把旧记录的 TTL 调低（如 300 秒），等旧 TTL 过期后再做切换，缩小影响窗口；
• 切换后：确认无误再把 TTL 调回正常值（如 600～3600 秒），减少解析查询量；
• 大多数场景下，CNAME 修改会在几分钟到几十分钟内生效，极端情况（旧 TTL 很长）最长可达 48 小时。

如何验证是否生效

用 nslookup 或 dig 查看当前解析结果：

# Windows / macOS / Linux 通用
nslookup www.example.com

# macOS / Linux，能看到完整的 CNAME 链
dig www.example.com +noall +answer

如果返回结果中出现了平台分配的接入点域名（如 xxxxxxxx.ap.qedge.top）， 说明 CNAME 已生效；随后可以访问平台测速地址确认节点连通性。

常见坑

1. 根域名不能设 CNAME

RFC 标准规定根域名（@）上不允许与其他记录共存 CNAME。部分服务商用 CNAME Flattening 绕过限制，但可能引发调度误判——详见《根域名用 Cloudflare 解析，为什么会被调度到海外节点？》。推荐做法是业务放在 www 子域名上。

2. CNAME 与其他记录冲突

同一主机记录下，CNAME 不能与 A、MX、TXT 等记录共存。如果域名同时用于收发邮件， 注意不要把带有 MX 记录的主机名设置成 CNAME。

3. 忘了删除旧的 A 记录

添加 CNAME 前如果存在同名 A 记录，部分 DNS 面板会静默保留两条记录，导致解析结果时对时错。 切换时务必先删旧 A 记录，再加 CNAME。

4. 开着第三方代理再 CNAME

在 Cloudflare 等平台上，如果记录处于"代理"（橙色云朵）状态，实际解析到的是 Cloudflare 的 IP 而不是你填写的目标。接入 QEdgeCDN 时应将该记录切换为"仅 DNS"（灰色云朵）。

准备好接入了？跟着《QEdgeCDN 接入教程》走一遍， 从创建站点到 CNAME 生效只需要十几分钟。