服务器加 CDN 完整指南：从源站准备到缓存策略落地
给服务器加 CDN，听起来只是「在 DNS 里加一条 CNAME」的事。但真正做过的人都知道，这条 CNAME 后面牵扯的是缓存规则、回源压力、证书管理、日志与告警的一整套调整。同样一台源站服务器，配置得当时，加 CDN 之后回源带宽能降到原来的几分之一；配置不当时，用户看到的可能是一堆陈旧的页面，源站反而因为缓存频繁失效而更忙。这篇文章把「服务器加 CDN」这件事拆开讲，从原理到接入顺序，再到上线后的验证，尽量把容易踩的坑提前说清楚。
为什么要在服务器前面加一层 CDN
网站访问慢，很多人的第一反应是「服务器配置不够」，于是升级 CPU、加内存、换更高带宽的机器。结果发现页面加载速度提升有限，因为瓶颈往往不在计算能力，而在物理距离和网络链路。用户在北京访问一台放在香港或者美西的机器，即使服务器负载只有一成，首字节时间也可能长达几百毫秒。CDN 的作用就是把内容提前搬到离用户更近的节点，让这段跨地域的链路不再出现在每一次请求里。
服务器加 CDN 真正解决的是「重复传输」
一个页面里，图片、样式表、脚本、字体往往占到总请求数的八成以上，而这些文件在短时间内对绝大多数用户是完全一样的。如果每个用户都要回源站取一遍，服务器就要为同一份内容重复付出带宽和连接开销。CDN 的边缘节点把这些内容缓存下来，第一个用户回源，后面的用户直接在边缘命中。命中率做得好，源站的出流量可能只剩原来的十分之一。
源站压力从哪里来
除了带宽，源站还承受并发连接、TLS 握手、慢速攻击等压力。把这些交给边缘节点之后，源站只面对来自 CDN 回源节点的有限连接，抗并发能力会明显提升。这也是为什么一些对外活动页面、促销页在临时加上 CDN 之后，原本要扩容几台机器的需求就消失了。反过来说，如果你的站点本身接口调用密集、几乎全是动态内容，那么加 CDN 的收益会集中在链路优化和连接复用上，而不是「省带宽」。
动手之前要想清楚的两件事
内容是静态还是动态
静态资源，比如图片、视频、下载包、前端构建产物，是 CDN 的主场，缓存时间可以设得很长，带 hash 文件名的资源几乎可以永久缓存。动态请求，比如登录、下单、实时查询，不能靠缓存解决，需要走动态加速或者干脆直连源站。接入前先把请求按类型分清楚，后面的缓存规则才有依据，而不是凭感觉给所有路径都设一个「缓存一小时」。
域名与证书怎么规划
建议把静态资源单独放到一个子域，比如 static 或 cdn 前缀，这样缓存策略、证书、防盗链都能独立配置，出问题也不会牵连主站。证书方面，现在主流 CDN 都支持在边缘托管证书，源站可以只保留一张源站证书，甚至使用 HTTP 回源，安全性要求高的场景仍建议 HTTPS 回源。要特别留意证书的自动续期，边缘证书过期导致的整站不可用，是接入之后最常见的低级事故之一。
服务器加 CDN 的接入顺序
第一步：先把源站收拾干净
加 CDN 之前，源站该做的优化不能省。开启 gzip 或 brotli 压缩、给静态资源加版本号或内容 hash、把不必要的大图压一压、合并零碎的小文件。CDN 只是把内容搬近，它不会让一个 3MB 的首屏图片变小，也不会替你修掉后端的慢查询。
第二步：添加加速域名并配置 CNAME
在 CDN 控制台添加加速域名，填写源站地址（IP 或源站域名），系统会给出一条 CNAME 记录。回到 DNS 服务商把原来的 A 记录替换成这条 CNAME，等待解析生效。这里有一个容易忽略的点：如果源站域名本身也解析在同一个 DNS 上，要确保回源解析不会绕回 CDN 形成环路，否则会出现请求自我循环、返回 508 或者直接超时。
第三步：缓存规则是核心
缓存规则决定了哪些请求在边缘停留、停留多久。常见的做法是按后缀和目录分层：图片、字体、带 hash 的 JS 与 CSS 设置较长缓存；HTML 设置较短缓存或者不缓存；接口路径直接配置为不缓存。同时要正确设置 Cache-Control 与 Expires 响应头，边缘节点和浏览器都会参考它们，两边设置冲突时以更严格的一方为准。
第四步：回源配置与源站保护
回源协议、回源 Host、回源端口、超时时间都要和源站实际配置对齐。回源 Host 配错会导致源站虚拟主机匹配不上，返回 404 或者落到默认站点。回源超时太短，在源站处理慢的时候会频繁触发重试，反而放大源站压力。另外建议在源站侧配置只允许 CDN 回源节点的 IP 段访问，避免有人绕过 CDN 直接打源站，让前面所有的防护都白做。
第五步：HTTPS 与协议优化
边缘证书配置好之后，可以顺手开启 HTTP/2、HTTP/3、TLS 1.3、OCSP 装订等选项，这些对首屏时间的改善通常比换一台更好的服务器更明显。如果站点有 HSTS 需求，注意先确认所有子域都能正常走 HTTPS，再开启，否则回滚会很麻烦。
缓存策略里的几个细节
带参数的 URL 怎么处理
很多统计代码会在资源地址后面加随机参数，比如 ?v=123 或者 ?_=timestamp。如果 CDN 默认把完整 URL 当作缓存键，这些参数会让缓存碎片化，命中率断崖式下跌。解决办法是在缓存键配置里忽略指定的查询参数，或者干脆让前端不要给静态资源加随机参数，改用文件名 hash 做版本控制。
刷新与预热
内容更新时，可以通过 URL 刷新或目录刷新让边缘缓存失效。但刷新是有成本的，全站目录刷新会让大量请求同时回源，形成回源风暴。更稳妥的做法是给文件名加 hash，内容变了 URL 就变，根本不需要刷新；确实需要刷新的场景，分批执行并放在流量低峰期操作。预热则是反过来，把即将发布的内容提前推到边缘，避免上线瞬间用户全部回源。
动态内容：CDN 也不是只能缓存
现在的 CDN 早就不只是缓存静态文件。动态加速通过优化回源链路、复用长连接、选择更优路由，让登录、查询这类不能缓存的请求也能快一些。部分服务商还提供边缘计算能力，把鉴权、重定向、AB 测试之类的逻辑放到边缘执行，减少一次回源往返。对于 API 类服务，边缘的连接复用往往比缓存更有效，因为接口的响应本来就因人而异。
边缘规则：把一部分逻辑前移
很多 CDN 支持在边缘执行简单规则：URL 重写、301 跳转、按 UA 或地区返回不同内容、给响应补充安全头。把这类逻辑放到边缘，可以少一次回源，也能在不改源站代码的前提下做紧急处置。但要记住规则是在边缘执行的，配置错了影响的是全站，改动前最好先在测试域名上验证一遍。
图片与视频的适配
图片往往是带宽消耗的大头。支持图片处理的 CDN 可以按 URL 参数实时裁剪、压缩、转 WebP 或 AVIF，配合 Accept 头自动选择格式。视频则通常走切片加边缘缓存，或者直接采用对象存储加 CDN 的标准组合。这些能力用好了，比单纯压缩源站图片省事得多，也更容易做多端适配。类似的方案在 Cloudflare、Akamai、Fastly 以及国内的 又拍云、七牛云 等平台上都能找到，选型时重点比较节点分布、功能完整度和计费方式。
安全：加 CDN 顺带得到的能力
把流量收拢到 CDN 之后，源站不再直接暴露在公网，抗 DDoS 的能力天然提升。多数 CDN 还提供 WAF、CC 防护、Bot 管理、防盗链（Referer 白名单、时间戳签名）等能力。这些功能不必全部打开，但要按业务需要配置：下载站需要防盗链，登录接口需要频次限制，后台路径最好直接拒绝公网访问。功能开着却没人看告警，和没开区别不大。
多 CDN 与容灾
单一 CDN 出故障时，整站都会受影响。有一定规模的站点会同时接入两家或多家服务商，通过 DNS 调度或者专门的流量调度服务做主备切换。海外服务商与国内厂商在节点分布、备案合规要求上差别很大，选择时要结合用户分布来定。常见的组合是把主要流量放在一家，另一家配置同样的规则作为备份，并定期演练切换，否则真出事时才发现备份域名根本没生效。
上线之后怎么判断加对了没有
看几个指标就够了：缓存命中率、回源带宽占比、首字节时间、5xx 比例。命中率长期低于八成，说明缓存规则或者缓存键有问题；回源带宽没有明显下降，说明大量请求根本没被缓存；首字节时间没有改善，可能是回源链路或者 DNS 调度的问题。日志方面，CDN 提供的访问日志和源站日志要能对得上，否则排查线上问题时会非常痛苦。
几个常见的误区
一是以为加了 CDN 就不用管源站，结果源站磁盘 IO 打满，CDN 再快也没用；二是把 HTML 缓存很久，用户看到的是几天前的页面；三是回源带宽没做限速，缓存穿透时源站被瞬间打满；四是忘记给 CDN 回源 IP 放行，防火墙把正常回源也拦了。这些问题都不复杂，但在不同的团队里反复出现。
成本怎么算
CDN 一般按流量或带宽计费，回源流量单独计价，HTTPS 请求数在部分服务商那里也会单独收费。加 CDN 之后总成本是升是降，取决于源站带宽单价与 CDN 流量单价的对比，以及缓存命中率。命中率高的时候，省下来的源站带宽费用往往能覆盖 CDN 的成本；命中率低的时候，等于付了两次钱。所以谈成本之前，先把命中率这一件事做好。
给服务器加 CDN，本质上是一次流量架构的调整，而不是装一个插件。把内容分类、缓存规则、回源策略、证书和监控这几件事按顺序做好，CDN 带来的收益会非常直接；反过来，如果只改一条 DNS 记录就撒手不管，问题迟早会在流量高峰时暴露出来。
