3.2 域名与解析：从apa到自定义域

站点传上去当晚，我把平台给的默认域名发给合伙人预览。域名长这样：cp-3f2a1b09.apa.tencent.com，一串随机字符加 apa 字样。能打开，但谁也记不住；更要命的是发到群里，有人以为是钓鱼链接。第二天我们就决定换正式域名——这事成本比想象中低，但坑比想象中多。

本节按实际顺序讲：域名拿到手、加解析记录、接入 CDN 验证、www 与根域名处理。如果走的是轻量服务器路线，反向代理那一层不同，但 DNS 解析配置可以对照 轻量应用服务器建站实战 看，DNS 这层两边是通的。

3.2.1 默认域名为什么不能凑合

apa 默认域名有三个实际问题：一是不可记忆，品牌层面零分；二是搜索引擎把它当临时站收录，日后换域名等于权重清零；三是分享到微信等平台时，未备案的随机子域有时会被拦截转码。所以组里把规则写死：腾讯云网站托管 分配的默认域名只用于内部预览验收，一切对外入口必须走自有域名。这条规则同时保护了 SEO——专属域名收录的内容，权重算在自己的站上。

选域名本身也有两条经验。其一，com 优先，实在被占了再考虑 co、io 之类，理由不是技术性的，而是用户默认输入习惯——你跟客户说域名，他脑子里第一反应就是点 com。其二，续费提醒和域名锁一并打开。域名忘续费被抢注的惨案每年都在发生，一年几十块钱的东西，不值得赌。我们注册时顺手关掉了自动转移权限，省得日后某天钓鱼邮件点错链接把域名转走。

3.2.2 解析记录：加一条 CNAME

域名在 DNSPod 解析（腾讯云域名服务，文档入口 cloud.tencent.com/document/product/232），控制台加一条记录：

为什么是 CNAME 而不是 A 记录？因为接入的是 CDN，节点 IP 由 CDN 动态调度，A 记录写死 IP 就失去了调度的意义。CNAME 相当于把域名指向 CDN 的域名，由它返回当时的最优节点。几种常见记录类型对照如下，加记录前先想清楚自己到底在配哪一类：

这张表后来贴在了我们 DNS 控制台的收藏夹里，新人加记录先看一眼，至少不会再把证书验证的 TXT 记录当成解析记录加错位置。

验证解析用命令行，三条各有分工：

nslookup www.example.com
dig www.example.com CNAME
ping www.example.com

nslookup 看记录是否生效，dig 看 CNAME 链是否完整指到了加速域名，ping 确认落点是 CDN 节点 IP 而不是源站。解析生效通常是分钟级，但个别本地 DNS 缓存久，调试期 TTL 调小就是为了等得起。

排错时口诀就一句：别信本机，信公共 DNS。我们后来统一用云厂商公共解析（223.5.5.5 或 119.29.29.29）做基准，命令也固定成一行：

nslookup www.example.com 223.5.5.5
dig @223.5.5.5 www.example.com

指定 DNS 服务器参数后，查到的就是全网视图，再没有本地缓存干扰这一说。刚加完记录那几分钟可能还是旧的，等 TTL 过了再查，准。

3.2.3 备案：绕不过去的一周

域名解析配好了，但国内站点还有一道手续：备案。腾讯云有备案系统，提交主体资料、域名信息、人脸核验，整个过程材料齐全的话一到两周。这里说两个我们经历的真实情况，供排期参考。

一是备案期间站点能不能开。规则上，未备案的域名不能解析到国内 CDN 节点对外提供服务，但可以解析到境外节点，或者干脆等备案下来再切。我们的排期是备案审核期间继续用 apa 默认域名做内部验收，备案通过号下来当天才把 CNAME 记录切过去——反正 TTL 调小了，切换当天就是几分钟的事。

二是备案主体和域名所有者要一致。我们又加了一个备用域名，所有者是另一个合伙人的名字，结果备案被打回来要求先做过户。后来所有正式域名统一走公司主体，个人名义注册的域名要么过户要么不用，前期的麻烦换来后面省心。这块的流程细节，腾讯云实践案例集 里有更完整的备案踩坑记录，值得一看。

3.2.4 根域名怎么办

www 能解析了，客户习惯直接输 example.com（裸域名）。裸域加 CNAME 在 DNSPod 是允许的，但会与 MX 邮件记录冲突——我们的域名不收发邮件，权衡后直接给根域也加了 CNAME 指向同一个加速域名。如果这个域名以后还要跑企业邮箱，更稳妥的做法是根域 A 记录指向一个跳转资源，再 301 到 www。选哪种，看域名还干不干别的事：

我们选第一种，全站最终统一 301 到 www，HTTPS 跳转那部分放在 3.3 SSL 证书 里配，避免出现解析能到、协议却是 HTTP 的半吊子状态。

补充一个性能向的细节：解析记录的 TTL 在域名稳定后可以调大。TTL 越大，各级 DNS 缓存越久，用户第一次解析的延迟越低，同时解析服务器压力也小。我们的策略是上线前 600 秒方便调试，运行稳定一个月后调到 3600 秒。这个数字不必纠结，它对体感速度的影响远小于 CDN 缓存，属于顺手做的优化。CDN 缓存策略的影响大得多，详见第四篇 4.1 CDN 接入。

3.2.5 踩过的四个坑

坑一：解析没生效就提交。CDN 控制台接入自定义域名时会校验解析，有同事记录还没生效就点了提交，平台报域名未解析，之后解析生效了也不会自动重试，得手动回来点。流程咬死：先 dig 通，再提交。

坑二：本地缓存骗自己。公司网络的 DNS 缓存特别久，明明解析已经生效，同事电脑就是打不开。让他刷本地缓存：Windows 执行 ipconfig /flushdns，手机直接切移动网络。判断依据永远是公共 DNS（比如 223.5.5.5）的查询结果，而不是本机。这条经验后来也写进了新人文档，省了无数次无谓的对线。

坑三：CNAME 冲突。同一主机记录先加了 A 又加 CNAME，解析轮询随机命中，现象是网站时好时坏，监控曲线像心电图。DNSPod 保存时会报冲突提示，别无视那个红色警告，删掉旧 A 记录再保存。

坑四：HTTPS 跳转循环。证书还没部署好就开了强制 HTTPS，结果浏览器反复 301 死循环，ERR_TOO_MANY_REDIRECTS 直接拍脸。原因是 CDN 的回源协议和证书部署状态没对齐：跳转开了，回源却还是明文握手，来回踢皮球。顺序记住：解析通了、证书部署完了（见 3.3 SSL 证书），最后再开强制跳转开关。

排查这类循环有个办法：用 curl 分别指定协议逐段试，浏览器看不出中间过程，curl -I 一层一层跟 Location，环在哪一步断开一目了然。这个排查习惯后来进了团队的排障手册，第四篇接入云函数后，调试 4.2 表单与留言后端 时也是同样的分段排查思路。

小结

域名接入的顺序是死的：拿域名、备案、加 CNAME、dig 验证、提交 CDN、最后再管 HTTPS。TTL 调小方便调试，稳定后调大省解析；根域方案按域名要不要跑邮件选；一切以公共 DNS 的查询结果为准，不跟本地缓存较劲。这一节还有件事没做：站点走的是 HTTP 明文，解析再快也还是裸奔。下一节 3.3 SSL 证书 给域名挂上免费证书，让浏览器地址栏的小锁亮起来。

延伸阅读

• Node.js 网站托管实战：本书目录，本篇第三节讲免费 DV 证书申请。
• 轻量应用服务器建站实战：服务器路线的域名与反向代理对照。
• 腾讯云实践案例集：云上域名与 CDN 接入的更多实战记录。