CDN还是A记录，解析该走哪条路

解析那一栏填什么，很多人是在域名后台点开添加记录时才开始纠结——一条 A 记录指到源站 IP，还是把 CDN 递过来的 CNAME 填进去。我的态度是先别急着选，先问三个问题：这站是什么类型、域名备案在不在、以后换服务器勤不勤。这三问答完，cdn还是a记录解析该走哪条路基本就有谱了，剩下都是操作层面的细节，没什么神秘的。

A记录和CDN，在解析层面差在哪

A 记录是本本分分地把域名翻译成一台机器的 IP，结果稳，查一次能记很久。CDN 一般给你一个 CNAME，形如 something.cdn.example.com，访客解析时先落到 CDN 的调度 DNS，再按线路和地域被领到某个边缘节点。打个比方，A 记录是直接告诉你门牌号，CNAME 是先找前台、前台再带你上楼，中间多了道手续。

这层差别带来的后果挺实在。A 记录把源站 IP 明晃晃摆在外面，有人盯着打的时候一点遮挡都没有；CNAME 多一跳，出问题排查的链条更长，本地 DNS 缓存的影响也更明显，你这边改完了，那边访客还在连旧地址。还有个硬限制得知道：根域名那条 @ 记录在标准 DNS 里不能挂 CNAME，会跟 SOA、NS 记录打架。不少域名商提供 ALIAS、ANAME 这类伪 CNAME 来补缺，但各家支持程度不一样，别想当然，以服务商控制台说明为准。

cdn还是a记录解析该走哪条路，先看站点这几种情况

图片多、静态资源多、访客天南海北的内容站、博客、企业展示站，上 CDN 的收益看得见：静态文件让就近节点兜住，源站只处理少量回源请求，带宽账单也好看一些。反过来，站小、访客基本在一个城市、一天没多少请求的，老老实实 A 记录更省心，配置少、排查快，账也算得明白。

带登录后台、支付回调、实时接口的站要留个心，别一股脑全推进 CDN。常见做法是主域走 CDN，后台单独开个子域比如 admin.example.com 用 A 记录直连源站，或者把接口拆到子域上避开缓存。提醒一句，避开缓存不等于避开防护，这两件事别混着理解。

还有个反常识的点——CDN 不是『网站一定变快』的按钮。第一次请求没命中缓存时它得回源，链路反而比直连多绕一下，真正决定体感的是缓存命中率，不是你买的那份套餐叫什么名字。

备案这关，别等配完了才发现

国内节点基本都要求域名先完成 ICP 备案，有些场景还涉及公安联网备案，备案主体、域名、接入商三者得对得上。没备案只能走境外节点，延迟和稳定性都要打折扣，也可能被服务商限制，具体口径以服务商和官方页面说明为准。还有一层容易忽略：备案是跟着接入走的，今天接这家 CDN、明天换那家，可能要做接入变更，别以为备案号在手上就一劳永逸。这块各接入商流程不一样，动手前去控制台看流程，比瞎猜靠谱。

切换时最容易翻车的几个地方

TTL。换之前先把 TTL 调小，常见做法是提前一天降到几分钟到几十分钟这一档，具体下限看套餐允许，稳定几天再调回来。不然旧记录黏在别人的本地缓存里，你这边改完了，那边访客连的还是老 IP，还以为是 CDN 没生效。

根域和邮箱也是重灾区。CNAME 那条记录所在的名字上不能同时存在别的记录，跟 MX 撞上了邮件就出问题，企业邮箱突然收不到信，很多就是换解析时手快。证书别只配一半，CDN 侧一张、源站侧一张，两边都要能握手。回源 HOST 填错的话，CDN 会一直回源失败、报各种错误码，看着像 CDN 挂了，其实是配置写歪了。缓存规则更要小心，动态页面被缓存住，登录状态串号，这个坑老经典了。

有些场景我会直接劝人别上CDN

只有几个固定访客的内网系统、调试阶段的站、纯 API 且用户全在同城的小程序后端、源站本身就跑得慢的站，还有大文件下载和直播这种流量包没算明白的，这些情况我一般不推 CDN。CDN 是加速，不是治病。后端一条烂 SQL 卡在那儿，套几层节点照样慢，只是把慢往后挪了一截。调试阶段尤其别上，本地改完看不到效果，缓存一层层清，时间全花在怀疑人生上。

配完怎么验证走对了没

几招够用。dig example.com +short 看解析结果，看它是不是给出 CNAME 链；再指定一个公共 DNS 查一次做对比，像 dig @8.8.8.8 example.com，两边不一致多半是缓存还没退。curl -I https://example.com 看响应头里有没有 CDN 的痕迹，各家标识字段不一样，Via、X-Cache、Server 这几类都见过，认哪家看服务商文档。

再到不同地区测一测，或者让外地的朋友 ping 一下，看落点是不是分散到不同节点。最实在的是翻源站访问日志：正常跑起来之后，回源 IP 应该是 CDN 节点的地址段，而不是满屏真实访客的 IP；如果满屏都是访客 IP，八成是解析没生效，或者流量压根绕过了 CDN。最后盯几天命中率报表，长期偏低一般不怪 CDN，是缓存规则和查询串没收拾干净。

顺序我一般是这么走的：先确认备案和接入，再定主域走不走 CDN，拿子域灰度、调小 TTL、配双份证书、设好回源 HOST 和缓存规则，最后用 dig 和响应头验一遍，盯几天命中率。顺序反过来，问题会互相盖住，查起来特别费劲。要是你连源站为什么慢都还没搞清楚，那就先挂 A 记录，把后端捋顺，再谈 CDN——顺序错，钱花了，人还懵着。