CDN 配置完全指南：从入门扫盲到缓存规则实战验证

作为运维新手，面对 CDN 控制台里密密麻麻的配置项，你是否一脸茫然？

好不容易配好了缓存规则，测试时又被 TCP_HIT、TCP_MISS、Age: 0 搞得晕头转向？

本文分为上下两篇：上篇 带你快速理清 CDN 各配置模块是干什么的；下篇通过完整的实验，手把手验证缓存规则的优先级、强制缓存覆盖源站、以及多级缓存带来的现象。读完这篇，你也能成为 CDN 配置与排障小能手。

上篇：CDN 配置扫盲 ------ 快速理清这些配置到底是来干嘛的

一、初识 CDN 配置面板：这东西到底在配什么？

刚接触 CDN 时，打开控制台，满屏的"源站管理"、"回源协议"、"缓存配置"、"访问控制"......每个字都认识，连在一起就不知道从何下手。

其实，这些配置可以看作是一套交通规则，指挥着用户请求和源站内容如何在 CDN 这个大网络上高效、安全地流动。

要快速理清它们，需要先抓住 CDN 工作的核心流程：

text

用户访问 → CDN 节点（缓存/安全/优化）→ 回源（到源站获取）

二、一个比喻：CDN 就是全球超级快递网络

可以把 CDN 想象成一个遍布全球的超级快递网络：

• CDN 本身不生产"包裹"（内容），而是从"发货地"（你的源站服务器）取货

• 取到的货存储到遍布全球的"仓库"（CDN 节点）里

• 用户下单时，从最近的仓库发货，速度飞快

工作流程如下：

1. 用户下单：用户访问你的网站，向 CDN 发起请求

2. 就近发货：CDN 的智能系统把用户引导到离他最近的"仓库"（CDN 边缘节点）

3. 检查库存：

   • 如果"仓库"有货（缓存命中），直接发货给用户，速度飞快

   • 如果"仓库"没货（缓存未命中 ），就需要去"发货地"（源站）取货，这个过程就叫 "回源"

4. 取货与补货："仓库"从源站拿到"包裹"后，一边发给用户，一边自己存一份，方便下次快速发货

理解了"就近缓存 "和"回源 "这两个核心概念，下面的配置就很好懂了。所有配置都可以分为两大类：一是让"仓库"运作得更好（缓存、安全、优化），二是管理"仓库"如何从"发货地"取货（源站、回源配置） 。

三、各配置模块详解

下面我们把常见的 CDN 配置项，对应到"仓库"工作的各个环节。

3.1 源站管理：设置"发货地"

这是最基础的配置，告诉 CDN 你的源站服务器在哪里。

配置项	一句话理解	说明
源站清单	告诉 CDN"货从哪里来"	设置源站的地址（可以是 IP、域名或对象存储服务等）。可以配置多个以实现负载均衡或主备切换
回源协议	规定取货时走哪条路	规定 CDN 节点去源站取货时，使用 HTTP、HTTPS 还是"协议跟随"（用户用啥协议，回源就用啥）
IPv6 回源	允许走 IPv6 通道取货	允许 CDN 节点通过 IPv6 协议访问你的源站
回源 Host	告诉源站要找哪个"货架"	当你的源站服务器上托管了多个网站时，用这个配置告诉 CDN 它要访问的是哪个具体站点
HTTPS 配置/证书配置	给"仓库"装防盗门	在你的加速域名上部署 SSL 证书，让用户能通过 HTTPS 安全地访问你的网站

3.2 访问控制：设置"安保系统"

管理哪些"顾客"（客户端）可以进"仓库"。

配置项	一句话理解	说明
IP 黑白名单	最简单的门禁系统	黑名单内的 IP 禁止入内，白名单则只允许名单内的 IP 访问。用于防御恶意攻击或盗刷

3.3 缓存配置：管理"仓库"里的货

这是 CDN 加速的核心，决定了内容在 CDN 节点上如何存储和更新。

配置项	一句话理解	说明
缓存键值（Cache Key）	决定如何给"包裹"贴标签	例如，可以设置忽略 URL 中的 ? 后的查询参数（如 ?version=1），让不同参数的同一资源共用一个缓存，提高命中率
节点缓存规则	设置"包裹"的保质期	设置不同类型文件（如图片、CSS、JS）在 CDN 节点上的缓存时间。合理的规则能大幅减少回源，提升速度
状态码缓存规则	给"坏包裹"也设个保质期	当源站返回错误状态码（如 404、502）时，CDN 节点可以缓存这个结果一小段时间，避免短时间内反复回源请求一个注定失败的内容，以保护源站
浏览器缓存规则	告诉用户"你自己也存一份"	这个规则是写给用户浏览器的，告诉它应该在本地缓存多久，这样用户再次访问时，甚至不用请求 CDN，直接从本地读取，速度最快
HTTP 响应头设置	在"包裹"上贴附加标签	可以自定义 CDN 返回给用户时的 HTTP 头部信息，用于实现跨域资源共享（CORS）等特定目的
离线缓存	发货地失联时，仓库还能发货	开启后，即使源站故障或网络不通，只要 CDN 节点上有缓存，也能把内容返回给用户，提高了可用性

3.4 回源配置：优化"取货"过程

管理 CDN 节点从源站取货的细节，确保能高效、准确地拿到内容。

配置项	一句话理解	说明
回源重定向跟随	取货地址变了，自动跟着去	如果源站返回了 301/302 重定向指令，CDN 节点会直接跟随这个指令去新的地址取货，而不是把这个指令转发给用户。这能避免一次重定向带来的额外延迟
回源 URL 改写	取货单地址写错了，改一下	如果用户请求的 URL 和源站实际的资源路径不一致，可以在回源时进行改写，让 CDN 能正确地找到资源
回源参数设置	取货时要不要带附加信息	可以控制在回源时，是否携带、删除或添加特定的查询参数（如 ?token=xxx），以满足源站的鉴权或其他业务需求

3.5 内容优化：给"包裹"减负

让传输的数据更小、更快。

配置项	一句话理解	说明
智能压缩	把"包裹"压缩了再送	CDN 在返回内容给用户时，自动对文本类文件（如 HTML、CSS、JS）进行 Gzip 或 Brotli 压缩。文件体积变小，传输就更快，也能节省流量
页面优化	去掉"包裹"里多余的填充物	自动压缩 HTML、CSS、JS 等文件中的冗余注释和空白符，进一步减小文件体积

四、快速记忆口诀

配置模块	核心作用	一句话记忆
源站管理	告诉 CDN"货从哪里来"	设置源站地址和回源时的"交通规则"
访问控制	决定"谁能进来拿货"	设置 IP 黑白名单等，防止恶意访问
缓存配置	管理"货在仓库怎么存"	控制缓存方式、时长，是 CDN 加速的核心
回源配置	优化"去进货的路线"	处理重定向、URL 改写等，确保高效取货
内容优化	给"包裹瘦身"	通过压缩等技术，让传输更快

五、给新手的配置建议

建议你从 "源站管理" 和 "缓存配置" 入手，这是最基础的配置：

1. 先把源站信息配对

2. 再设置好缓存规则

3. CDN 就能跑起来了

其他的 "访问控制" 、 "回源配置" 和 "内容优化" ，等业务有具体需求时（比如需要防盗链、源站有重定向、想节省流量），再有针对性地去研究。

---

光说不练假把式。理解了各个配置模块是干什么的之后，节点缓存规则 作为 CDN 加速的核心配置，到底怎么配、怎么测、怎么排障？

下面进入 下篇，通过一个完整的实验，带你亲手验证 CDN 缓存规则的方方面面。

下篇：节点缓存规则深度测试 ------ 从实战中彻底搞懂缓存命中与过期

六、为什么要深度测试缓存规则？

在实际生产环境中，我们通常需要为不同路径配置不同的缓存策略：

• 静态资源（/static/）希望长时间缓存，加速访问

• API 接口（/api/）希望完全不缓存，保证数据实时性

• 首页或其他页面（/）设置一个兜底缓存，防止源站压力过大

同时，CDN 的缓存规则应当优先于源站 的 Cache-Control 头部，且规则之间要有明确的优先级（具体规则优先于宽泛规则）。

七、测试环境与前置准备

7.1 测试目的

验证点	说明
① 不同路径不同缓存策略	/static/ 缓存 180 秒，/api/ 不缓存，首页兜底 120 秒
② 优先级生效	具体规则（文件后缀 .css;.js）优先于宽泛规则（全路径 /*）
③ 强制缓存覆盖源站	CDN 规则覆盖源站 Cache-Control: max-age=60，以 CDN 的 180 秒为准

7.2 源站（Nginx）配置

我们在源站上部署了一个 Nginx，并准备了一个测试文件 /usr/share/nginx/html/static/style.css：

阶段	内容	说明
初始	aaa	首次测试
修改后	bbb	用于验证缓存过期后是否回源拿到新内容

Nginx 配置修改如下：

nginx

# /etc/nginx/conf.d/default.conf 中 /static/ location

# 修改前
location /static/ {
    add_header Cache-Control "max-age=3600";
    add_header X-Cache-TTL "1h";
}

# 修改后（特意改为 60 秒，用来验证 CDN 能否覆盖）
location /static/ {
    add_header Cache-Control "max-age=60";
    add_header X-Cache-TTL "1min";
}

💡 为什么要改源站的 Cache-Control？

为了验证 CDN 的"强制缓存"能否覆盖源站头部。源站说缓存 60 秒，我们偏要让 CDN 缓存 180 秒，看最终谁说了算。

7.3 CDN 控制台配置

我们在 CDN 控制台配置了三条节点缓存规则（按优先级从上到下匹配，命中即停）：

优先级	规则类型	规则内容	缓存策略	缓存时长
1（最高）	文件后缀	css;js	强制缓存	180 秒
2	文件目录	/api/	不缓存	0 秒
99（最低）	全路径	/*	强制缓存	120 秒

同时添加了自定义响应头便于观察：

字段	值
头部名称	X-CDN-Max-Age
取值方式	常量
头部取值	180

八、测试用例与结果分析

8.1 规则 1：/static/style.css ------ 强制缓存 180 秒 ✅

序号	操作	结果	结论
1	首次访问（内容 aaa）	返回 aaa，TCP_MISS	CDN 回源正常
2	源站改为 bbb，3 分钟内访问	返回 aaa，TCP_HIT	缓存命中，未回源
3	3 分钟后再次访问	返回 bbb，TCP_MISS	缓存过期，回源拿到新内容

✅ 验证通过 ：CDN 按 180 秒缓存，且覆盖了源站的 max-age=60。

8.2 规则 2：/api/data ------ 不缓存 ✅

bash

for i in 1 2 3 4 5; do
  curl -sI http://test.com/api/data | grep -iE "x-bdcdn-cache-status"
done

请求次数	1	2	3	4	5
缓存状态	TCP_MISS	TCP_MISS	TCP_MISS	TCP_MISS	TCP_MISS

✅ 验证通过 ：次次回源，永不 HIT。

8.3 规则 3：首页 / ------ 兜底缓存 120 秒 ✅

序号	操作	结果	结论
1	首次访问	TCP_MISS	回源
2	几秒后再次访问	TCP_HIT	缓存命中
3	120 秒后再次访问	TCP_MISS	缓存过期，重新回源

8.4 辅助验证：自定义响应头

bash

curl -sI http://test.com/static/style.css | grep -i x-cdn-max-age
# 输出：X-CDN-Max-Age: 180

✅ 可直接看到 CDN 配的缓存时长，方便排障。

九、深入理解：多级缓存与 Age: 0 谜题

测试中可能遇到这样的响应头：

text

X-Bdcdn-Cache-Status: TCP_MISS, TCP_HIT
Age: 0

9.1 CDN 多层级架构

现代 CDN 采用边缘节点 → 中间层 → 源站的多级架构：

时间点	边缘节点	中间节点	回源	状态码
第 1 秒	MISS	MISS	✅ 回源	TCP_MISS, TCP_MISS
第 60 秒	HIT	---	❌ 未回源	TCP_HIT
第 120 秒	MISS（新节点）	HIT	❌ 未回源	TCP_MISS, TCP_HIT
更久后	MISS	MISS	✅ 回源	TCP_MISS, TCP_MISS

9.2 状态码速查表

响应头现象	真实含义
TCP_MISS, TCP_HIT	边缘过期，中间还活着
TCP_MISS, TCP_MISS + Age: 0	两段都过期，真正回源
TCP_HIT + Age 很大	边缘命中
TCP_HIT + Age: 0	边缘刚从中层拿来，没回源

不要只看 TCP_HIT 就认为是边缘缓存 ，要结合 Age 综合判断。

十、最终总结

10.1 核心结论

验证项	结果
不同路径不同缓存策略	✅ /static/ 缓存 180 秒，/api/ 不缓存，首页兜底 120 秒
规则优先级	✅ 文件后缀 > 文件目录 > 全路径兜底
强制缓存覆盖源站	✅ 源站 max-age=60，CDN 按 180 秒缓存
不缓存规则	✅ /api/ 次次回源，永不 HIT
自定义响应头	✅ X-CDN-Max-Age: 180 可直观看到 CDN 配的缓存时长

10.2 注意事项

1. 规则从上往下匹配，命中即停。宽泛规则放高了，具体规则永不生效。

2. 强制缓存只影响 CDN 内部行为 ，透传给用户的 Cache-Control 仍是源站的值。

3. 验证缓存过期最可靠的方法：改源站内容 + 等 TTL 到时 → 内容变化即回源。

4. 修改规则后务必刷新缓存，旧缓存不会自动失效。

5. 自定义响应头是排障利器，建议测试阶段开启。

10.3 全文一句话总结

上篇记住配置分类：源站、缓存、回源、安全、优化；下篇记住三个核心：配好优先级、想清楚强制缓存还是遵循源站、验证时改源站内容等 TTL 到时看变化。

搞懂了这些，CDN 对你来说就不再是玄学，而是一套清晰可控的系统。