同一个网站，北京用户打开要2秒，广州用户打开却要5秒，这种差异往往不是代码写得不好，而是源服务器位置太远造成的。CDN（内容分发网络）的核心思路很简单：与其让所有用户都千里迢迢去源站取数据，不如把数据提前复制到离用户最近的节点上。本文通过图解的方式拆解CDN的完整工作流程，并给出实际接入和调优的落地方案。
CDN到底是怎么工作的：一次完整请求的旅程
先看没有CDN时的情况。用户在浏览器输入域名，DNS解析得到源站IP，浏览器直接向源站发起HTTP请求。如果源站在杭州，而用户在乌鲁木齐，数据要跨越几千公里的物理链路，每一次TCP握手、每一个数据包的往返都要承受链路延迟。更糟的是，跨运营商访问（比如电信用户访问部署在联通机房的服务器）还要经过运营商之间的互联节点，这些节点往往是最拥堵的瓶颈。
接入CDN后，流程发生了关键变化。用户发起请求时，DNS解析会返回一个离用户最近的边缘节点IP，而不是源站IP。这个调度过程通常依赖智能DNS（基于GeoIP库判断用户位置）或者HTTP 302重定向。用户随后向边缘节点请求资源，如果节点缓存了该资源，直接返回，整个链路可能只有几十毫秒；如果没缓存，边缘节点代替用户向源站回源取数据，返回给用户的同时自己存一份，供后续请求使用。
用一个简单的时间线来对比：无CDN时，DNS解析（20ms）+ TCP握手（80ms）+ SSL握手（120ms）+ 内容传输（200ms），总计约420ms；接入CDN后，DNS解析命中就近节点（15ms）+ TCP握手（10ms）+ SSL握手（15ms）+ 缓存直接返回（5ms），总计约45ms。对于静态资源占比高的页面，整体首屏时间压缩到原来的三分之一甚至更低，这就是"提升300%"这个数字的来源。
缓存策略是CDN的灵魂：命中率决定加速效果
很多团队接入了CDN，性能却没有明显改善，问题十有八九出在缓存命中率上。命中率的计算方式很简单：缓存命中请求数除以总请求数。如果命中率只有60%，意味着四成请求仍然要回源，加速效果大打折扣。影响命中率的首要因素是缓存键（Cache Key）的设计，最常见的问题是URL中带上了变化的查询参数。
<!-- 不推荐：每个用户带不同参数，缓存全部失效 --> <img src="https://cdn.ipipp.com/logo.png?v=1699999999&uid=12345"> <!-- 推荐：静态资源使用干净的URL，由构建工具统一生成版本号文件名 --> <img src="https://cdn.ipipp.com/logo.a3f8c2.png">
上面两种写法的区别在于：前者把用户相关的参数拼进了URL，导致每个用户请求的缓存键都不同，边缘节点几乎无法复用缓存；后者采用文件名指纹的方式，内容变化时文件名改变，URL本身保持纯净，可以设置极长的缓存时间。
其次要正确配置源站的缓存响应头。很多开发者只依赖CDN控制台的默认规则，却忽略了源站返回的Cache-Control头才是CDN判断缓存时长的核心依据。
# Nginx 源站针对静态资源设置一年强缓存
location ~* \.(jpg|png|css|js|woff2)$ {
expires 1y;
add_header Cache-Control "public, immutable";
}
# HTML文件禁止长缓存，避免更新后用户看到旧页面
location ~* \.html$ {
add_header Cache-Control "no-cache";
}这段配置里，immutable告诉浏览器和CDN该资源在有效期内不会变化，连条件请求都不必发起；而HTML文件使用no-cache，每次都会校验新鲜度。配合文件名指纹方案，就形成了"HTML短缓存、静态资源长缓存"的经典组合，命中率轻松做到95%以上。
动态内容怎么办：回源优化与边缘计算
CDN擅长缓存静态资源，但接口请求、个性化页面这类动态内容无法直接缓存。这不代表CDN对它们无能为力。首先是连接优化：边缘节点到源站之间通常维护着长连接池，用户请求到达边缘节点后，省去了用户到源站的TCP和SSL握手开销，仅这一项就能为跨地域请求节省200ms以上。
其次是协议优化。现代CDN普遍支持HTTP/2和HTTP/3（基于QUIC），用户到边缘节点之间可以用多路复用避免队头阻塞，QUIC甚至在弱网环境下能显著减少重传等待。同时开启Broti压缩，相比Gzip对文本类资源还能再压缩15%到20%的体积。
更进一步的是边缘计算能力。以常见的鉴权场景为例，原本每个接口请求都要回源校验Token，如果把鉴权逻辑下发到边缘节点执行，只有校验通过的请求才回源，回源量能直接减少一大截。
// 边缘函数示例：在节点上校验签名，未通过直接拒绝，不回源
async function handleRequest(request) {
const token = request.headers.get('X-Token');
if (!token || !verifySign(token, SECRET_KEY)) {
return new Response(JSON.stringify({code: 401, msg: 'unauthorized'}), {
status: 401,
headers: {'Content-Type': 'application/json'}
});
}
// 校验通过，放行回源
return fetch(request);
}这种模式把安全校验、请求改写、A/B测试分流等逻辑前移到离用户最近的位置，既降低了源站压力，也缩短了响应链路。对于电商大促、秒杀这类突发流量场景，边缘节点还能充当流量削峰的第一道防线。
接入CDN后的常见坑与排查思路
第一类坑是缓存不一致。用户反馈页面更新了但看到的还是旧版本，通常是HTML或入口文件被边缘节点缓存导致的。排查方法是检查该URL的响应头，重点关注X-Cache（HIT表示命中缓存）和Age字段（资源已在节点存放的秒数），确认缓存行为后再针对性调整规则。
第二类坑是回源风暴。某个热门资源缓存突然失效，海量请求同时回源，把源站打挂。解决办法是设置缓存刷新时的请求合并（部分CDN称为回源合并或秒级回源保护），同一资源在失效瞬间的多个请求会被合并为一次回源。此外，源站也要做好限流和兜底。
第三类坑是安全暴露。接入CDN后如果源站IP泄露，攻击者可以绕过CDN直接打源站。务必在源站防火墙上只允许CDN回源网段访问80和443端口，同时开启CDN的防盗链和频率限制功能，避免被恶意刷流量产生高额账单。配置完成后，用curl -I检查直接访问源站IP是否被拒绝，确认防护生效。
总的来说，CDN不是简单地"套一层加速"，而是一套包含智能调度、缓存体系、协议优化和边缘计算的整体方案。把缓存策略设计好、把回源链路优化好、把安全防护配置好，静态资源加载速度提升300%是完全可实现的目标。