很多人第一次听说 CDN，是在买服务器的时候被销售提醒"你这台机器带宽不够，加个 CDN 吧"；也有人是在网站被访问卡到崩溃之后，才回头去找 CDN。但真正说得清 CDN 是怎么工作的、为什么能加速、什么样的业务该用、什么业务用了也白搭，其实并不多。
这篇文章从最基础的问题讲起：CDN 到底是什么，它替你把内容放在哪里，一次用户请求从发出到拿到内容中间经历了哪些环节，节点是怎么分布和分层的，命中率这个指标为什么重要。看完之后，你应该能判断自己的网站值不值得上 CDN，以及上了之后该关注哪些数字。
一、CDN 到底在解决什么问题
CDN 的英文是 Content Delivery Network，中文叫内容分发网络。名字里已经点明了它的本质：它不是一台服务器，也不是一种软件，而是一张由很多台服务器组成的网络，专门用来"分发内容"。
要理解它为什么有用，先要明白没有 CDN 时的问题。假设你的网站服务器放在某个机房，用户在物理距离很远的另一个城市访问。用户发起一个请求，数据包要从用户所在的城市跨越上千公里到达机房，再原路返回。光在光纤里跑的时间（也就是往返延迟）可能就是几十毫秒；如果中间还要跨运营商、跨国，延迟轻松上百甚至几百毫秒。一个网页通常包含几十个资源（HTML、CSS、JS、图片），每个资源都要走这样一个来回，累积起来就是几秒的等待。带宽也不够用：所有用户的流量都压在同一台服务器的出口带宽上，人一多就排队。
CDN 的思路很直接：与其让所有人千里迢迢来你这一台服务器取内容，不如把内容提前复制到离用户很近的服务器上。用户访问时，就近的服务器直接把内容给他。距离缩短了，延迟自然降下来；流量被分散到很多台服务器上，单台源站的带宽压力也卸掉了。
这里有一个关键点容易被忽略：CDN 加速的从来不只是"速度"，它同时解决了三件事——降低延迟（离用户更近）、分担带宽（流量分散到边缘）、提升可用性（源站故障时边缘还能扛一段时间）。后面讲适用场景时，这三条会反复出现。
二、一次请求在 CDN 里经历了什么
理解了目的，再来看过程。用户访问 https://www.example.com/logo.png 这个图片，浏览器会先做域名解析。这一步就是 CDN 的第一个机关。
如果没有 CDN，域名直接解析到你的源站 IP，请求就奔着源站去了。接入 CDN 之后，域名解析的结果不再是你的源站 IP，而是 CDN 调度系统根据用户位置算出来的"最合适的边缘节点 IP"。也就是说，同一个域名，北京的用户解析到北京的节点，广州的用户解析到广州的节点，海外的用户解析到海外的节点。这套解析由智能 DNS 负责，业内也常叫 GSLB（全局负载均衡）。
智能 DNS 判断"哪个节点最合适"的依据通常有几类：用户解析请求的来源 IP 归属地、节点当前的健康状态、节点的负载和带宽余量、以及配置的调度策略（比如按地理位置就近、按运营商就近）。它返回的不是随机结果，而是一个经过计算的最优或次优选择。
用户拿到边缘节点 IP 后，向这个节点发起请求。边缘节点收到请求后先看本地有没有这个内容：
- 有，并且还在有效期内，直接返回，用户几乎感觉不到等待；
- 没有，或者已经过期，边缘节点就代替用户去源站取。这一步叫回源。
回源拿到内容后，边缘节点一方面把内容返回给用户，另一方面按缓存规则把内容存下来，供后面其他用户复用。从用户视角看，他只需要和就近的节点打交道；从源站视角看，大量重复的请求都被边缘节点吃掉了，只有没缓存的内容才会真正打到它这里。
# 查看域名解析到了哪里：看 CNAME 是否指向 CDN
dig www.example.com +short
# 典型输出会是 CDN 服务商提供的 CNAME 记录域名，而不是源站 IP
# 例如 www.example.com.cdn-provider.net 再解析出一批边缘节点 IP
# 查具体用了哪条 CNAME
dig www.example.com CNAME +short
# Windows 或不方便装 dig 时用 nslookup（交互式）
nslookup -type=CNAME www.example.com
如果 dig 返回的直接是你的源站 IP，说明 CNAME 还没生效或者配错了，这时候用户根本没走 CDN。这个命令是排查"CDN 到底生效没有"的第一招，后面的排障文章里还会反复用到。
三、内容缓存与有效期
CDN 能加速的前提是"重复访问的内容可以被复用"。而判断能不能复用、能复用多久，靠的是 HTTP 的缓存头。
源站在响应里通过 Cache-Control、Expires 等字段告诉边缘节点：这个内容可以缓存多久。比如一张带版本号的图片可以缓存一年，一个 HTML 页面可能只缓存一分钟甚至不缓存。CDN 节点严格按这些规则决定是否缓存、缓存多久。
这里要建立一个重要认知：CDN 缓存的是"内容"，而不是"请求"。只要两个请求的 URL、请求方法等关键信息一致，且内容还在缓存有效期内，后一个请求就能直接命中缓存。反过来，如果 URL 里带了每次都变的参数，比如 logo.png?time=1712345678，那么每次请求在 CDN 看来都是一个全新的 URL，永远命不中缓存，全部回源，CDN 等于白上。
缓存的有效期到了之后，内容并不会立刻从节点消失，而是进入"过期"状态，下一次有人请求时触发回源刷新。有些场景需要强制刷新，比如你更新了网站的某个静态文件但文件名的版本号没变，这时需要在 CDN 控制台手动刷新缓存，或者调用刷新接口。
# 手动触发缓存刷新（各主流 CDN 服务商都提供 API，下面是通用思路）
# 刷新单个 URL
curl -X POST 'https://cdn-api.example.com/refresh' \
-H 'Authorization: Bearer <你的API密钥>' \
-d '{"urls":["https://www.example.com/logo.png"]}'
# 按目录刷新，适合整站更新
curl -X POST 'https://cdn-api.example.com/refresh' \
-H 'Authorization: Bearer <你的API密钥>' \
-d '{"dirs":["https://www.example.com/assets/"]}'
调用刷新接口前要清楚代价：全站刷新会让所有节点的缓存同时失效，短时间内大量请求涌向源站，源站可能被打挂。所以更稳妥的做法是给静态资源文件名加版本或哈希指纹，更新时换个文件名，让新旧文件共存，缓存自然失效，不依赖手动刷新。
四、节点分布与层级架构
CDN 的节点不是随便撒的。主流 CDN 服务商的节点通常按城市和运营商两个维度布点，一线城市、主要省会城市、重点运营商几乎都有覆盖，海外节点则分布在各主要国际互联网枢纽。节点越多、离用户越近，加速效果越好，这也是不同服务商之间的核心差异之一。
node 的层级上，一般分三层：
| 层级 | 位置 | 作用 |
|---|---|---|
| 边缘节点 | 离用户最近，各城市各运营商 | 直接服务用户，命中就是最快的一层 |
| 中间源（中层节点） | 区域中心，数量少 | 汇聚下层的回源请求，减少对源站的直接冲击 |
| 源站 | 你自己的服务器 | 内容的最终来源，只在多层都未命中时才被访问 |
这套结构的意义在于"收敛回源"。假如有 200 个边缘节点，每个节点都要独立回源，源站就要承受 200 份重复请求。有了中间源，边缘节点没命中时可以先去中间源取，中间源命中后再分发给各个边缘，源站只需面对少数几个中间源。边缘节点越多、用户越分散，中间源的价值越明显。
层级越多，理论延迟也越高（每多一层就多一次查询），所以好的调度会尽量让用户在边缘节点就命中，只有确实没有的内容才逐层向上。这也是为什么"命中率"是衡量 CDN 质量的核心指标——命中率高意味着绝大多数请求在一两层内就解决了。
五、命中率：CDN 效果的晴雨表
命中率指的是在所有请求中，由边缘节点直接命中缓存、不需要回源的比例。它是判断 CDN 有没有真正发挥作用的最直接指标。
一个粗略的经验参考：静态资源（图片、CSS、JS）正常命中率应该在九成以上；如果只有六七成甚至更低，通常说明缓存规则配置有问题，或者 URL 里带了随机参数，或者缓存时间设得太短。命中率低的直接后果是回源量大、源站压力大、用户等待时间长，CDN 花的钱却没换来应有的效果。
命中率上不去的原因和优化方法在后面的文章里会专门展开，这里先记住一个结论：CDN 的加速效果，很大程度上就是命中率的函数。上 CDN 不等于自动变快，配好缓存规则才是关键。
六、哪些场景适合用 CDN
不是所有网站都适合上 CDN。判断标准是"内容是否可缓存、是否重复访问、用户是否分散"。
| 场景 | 适合程度 | 说明 |
|---|---|---|
| 图片、CSS、JS 等静态资源 | 非常适合 | 内容不变、可长期缓存、命中率高，收益最直接 |
| 软件包、安装包下载 | 非常适合 | 大文件、重复下载多，能大幅省源站带宽 |
| 视频、直播分发 | 适合 | 流量大且分散，CDN 是标配；点播和直播配置略有差异 |
| 企业官网、资讯站 | 适合 | 以静态内容为主，用户地域分散，加速明显 |
| 电商的商品图、活动页 | 适合 | 图片量大，但要注意活动页的缓存时间不能设太长 |
| 纯动态接口、登录态页面 | 作用有限 | 内容因人而异，默认不缓存，只能靠动态加速优化回源链路 |
| 内网系统、单一地区低访问量 | 不建议 | 用户集中、内容私有，CDN 起不到作用还可能引入问题 |
一句话总结选择逻辑：能被很多用户重复访问、且内容本身不千人千面的东西，才值得放 CDN。静态资源、下载、视频、图片是四大典型适用场景。反过来，一个需要登录的后台系统、或者用户都在同一个办公室的内部工具，上 CDN 基本没有意义。
在实操上，最常见的做法是"动静分离"：把静态资源放到一个独立域名（比如 static.example.com）上并接入 CDN，让它享受长期缓存；动态请求留在主域名的源站上。这样静态部分可以放心大胆地设长缓存，动态部分也不受缓存规则干扰。
常见问题
Q：CDN 是必须的吗？小网站也需要吗？
不是必须。用户集中、访问量小的站点，直接上源站体验可能也没问题。但如果用户分布广、或者有大量图片和下载，CDN 的收益通常很明显，而且静态资源走 CDN 往往比单纯加大源站带宽更划算。
Q：CDN 和"加速器"是一回事吗？
不是。加速器通常说的是给个人加速某个应用的客户端工具，而 CDN 是内容分发网络，服务的是网站和内容的托管方，两者面向的对象完全不同。
Q：CDN 上的内容和源站不一致怎么办？
通常是缓存没及时刷新。给静态资源加文件名版本号是最省心的办法；确有需要时可以在 CDN 控制台手动刷新缓存。要点是刷新后验证，用 curl -I 看响应头里的缓存命中标识和日期。
Q：CDN 节点那么多，我怎么知道用户命中了哪个节点？
多数 CDN 会在响应头里返回节点信息（如 X-Cache、Via 等字段），用 curl -I 就能看到。也可以用第三方的多地拨测工具，从不同城市看解析结果和响应时间。
Q：接入 CDN 后源站还要不要优化？
要。CDN 只解决"分发"这一段，回源的那部分链路仍然取决于源站质量。源站响应慢，边缘节点回源也跟着慢，未命中的用户照样等。
总结
CDN 的本质是一张靠近用户的服务器网络，通过"就近服务"降低延迟、通过"分担流量"减轻源站带宽、通过"多层节点"提升可用性，解决的是内容分发的距离和带宽问题。
一次请求的走向是：域名经智能 DNS 解析到最近的边缘节点，节点命中缓存就直接返回，未命中才回源取内容并缓存下来。命中率越高，CDN 越有效，静态资源正常应在九成以上。
节点按边缘、中间源、源站分层，边缘节点在城市和运营商维度尽量贴近用户，中间源负责收敛回源、减少源站压力。层级不是越多越好，关键是在边缘就命中。
CDN 最适合可缓存、重复访问多、用户分散的场景：静态资源、软件下载、视频、图片是四大典型。纯动态、私有、用户集中的系统不适合。最常见的落地方式是动静分离，静态资源走 CDN 独立域名并设长缓存。
上 CDN 不等于自动变快，配置好缓存规则、盯住命中率，才是让这笔投入真正产生效果的关键。
企业QQ咨询
