外贸站 CDN 怎么验收：
节点覆盖、回源压力与缓存规则？

先做一件事：打开 Cloudflare 后台的「缓存」→「分析」，看一眼你网站的缓存命中率。如果那一栏长期低于 60%，或者你根本不知道它在哪、代表什么，这篇就是写给你的——不是让你换更贵的套餐，是让你看清 CDN 到底有没有在给海外客户加速，以及配置错了会在哪一步出事。

一、海外客户访问慢，CDN 到底能解决哪一段？

先说 CDN 是什么。最权威的定义来自 Cloudflare 自己的文档：

“A content delivery network (CDN) is a geographically distributed group of servers that caches content close to end users.”

CDN 是一组地理上分散的服务器，把内容缓存到离终端用户更近的地方。它改善的是「运输距离」这一段延迟，而不是「源站生成页面」那一段。

Cloudflare · What is a CDN?

这一点要先钉死，因为它决定了 CDN 能治什么病。一个海外客户打开你的站，时间花在三处：浏览器到最近 CDN 节点的网络、CDN 节点到源站的回源、以及源站生成页面的时间（TTFB）。CDN 只接管第一处——让客户连到离他更近的节点，而不是连到你那台放在某个机房的服务器。

所以如果你的慢是源站本身就慢（比如首页要查数据库、跑脚本、等第三方接口），CDN 帮不上忙，你得先去治源站。验收 CDN 的第一个问题不是「快了没有」，而是「慢的那一段到底在哪」。先把延迟拆开，再判断 CDN 是不是用对了地方。

二、CDN 把我的网站存在了哪里，客户取的是哪一份？

CDN 不是把你的整站复制到它的服务器上，而是按「URL」一份一份地缓存。客户第一次访问某个资源，就近节点没有，就回源取一份存下来，之后同地区的其他客户直接拿缓存。关键问题是：哪些文件会被默认缓存？

“The Cloudflare CDN does not cache HTML or JSON by default. Cloudflare only caches based on file extension and not by MIME type.”

Cloudflare 默认不缓存 HTML 或 JSON，而且它只按文件后缀（扩展名）判断要不要缓存，不看 MIME 类型。也就是说，图片、CSS、JS、字体这类静态资源默认进缓存，而你的页面 HTML 默认每次都回源。

Cloudflare · Default cache behavior

这条默认规则其实是安全的：页面每次回源，保证客户看到的是最新的价格和库存；静态资源进缓存，保证重复访问飞快。问题几乎都出在「有人觉得缓存不够多，于是用 Cache Rule 把 HTML 也缓存了」——这正是下一节要讲的旧版事故。

三、为什么改了价格，海外客户还看到旧版？

场景很典型：你在后台改了报价，国内打开是新价，海外客户发来截图还是旧价。先别急着怪 CDN——默认情况下它不缓存 HTML，所以这种「旧版」通常来自两处：浏览器自己的缓存，或者你（或建站方）写的一条把 HTML 也长缓存的 Cache Rule。后者就是典型的「缓存规则写反了」。

验收时要把「该长缓存」和「不该长缓存」分清楚。下面这张表是给外贸站用的底线：

记住一句话：静态资源缓存越久越省，HTML 缓存越久越危险。验收时让服务商把这条边界写进 Cache Rule，并演示一次「改完价格 → 海外节点多久能看到」。如果对方说「我们都缓存一天」，那不是性能方案，是埋雷。

四、缓存命中率太低，回源被打爆是谁的问题？

命中率是 CDN 的命门：它衡量「客户请求里有百分之几是 CDN 直接回答了，没去烦你的源站」。命中率 90% 意味着源站只扛了十分之一流量；命中率 30% 意味着 CDN 几乎白挂，源站照旧裸奔。

命中率低常见三个原因：一是根本没缓存东西，所有响应都回源；二是缓存规则太短或带 no-cache，每份都要求回源验证；三是 URL 带了随机查询参数（如 ?v=123、追踪参数），把同一份资源拆成无数份，缓存互相不命中。

如果你能控制源站的响应头，针对 CDN 这个「共享缓存」有一条专用指令：

“The s-maxage response directive indicates how long the response remains fresh in a shared cache. The s-maxage directive is ignored by private caches, and overrides the value specified by the max-age directive or the Expires header for shared caches, if they are present.”

s-maxage 专门规定响应在「共享缓存」（也就是 CDN）里保持新鲜的时长，私有缓存（浏览器）会忽略它，且它会覆盖 max-age 对共享缓存的作用。换句话说，你可以用 max-age 管浏览器、用 s-maxage 管 CDN，两份时长分开定。

MDN · Cache-Control

Cloudflare 还有一个省心的机制：同一数据中心里，多个相同请求同时打到没缓存的资源时，它会用缓存锁只回源一次，其余排队等这一份。所以即便命中率暂时低，源站也不会被瞬间冲垮——前提是缓存规则别写得太离谱。验收时除了看命中率，也要看「节省的带宽」这一项，它直接对应你的源站成本。

五、选 CDN 时，节点覆盖和回源方式该怎么验收？

对外贸站来说，客户散在世界各地，CDN 的价值大小直接取决于它有没有节点落在你主要客户所在的地区。美国、欧洲、中东、东南亚的客户，应该各自连到就近的节点；如果某个地区你的客户很多，却离最近节点还差半个球，那一处的加速就名不副实。

验收节点覆盖有两个动作。第一，让服务商列出它在该地区的实际接入点（PoP），别只信「全球加速」四个字。第二，用多地区测速工具从几个客户所在地各跑一次，对比「走 CDN」和「直连源站」的延迟与首屏，把数字留档。如果某地区前后没差，要么节点太远，要么回源链路没优化，得追问。

回源方式也有讲究。绝大多数外贸站用的是「拉取式」：客户第一次来，CDN 回源取一份缓存，之后复用。它的风险是上线瞬间、或缓存集体过期的那一刹，所有地区同时回源，源站可能被一波打满。缓解办法就是上一节的缓存锁和合理的 TTL 阶梯。验收时问清楚：缓存过期是错峰的还是齐刷刷的？有没有「先用旧缓存顶着、后台悄悄回源刷新」的行为？

六、一次缓存配置失误，会不会让全站短暂打不开？

会，而且比你想的常见。最常见的几种：用一条「缓存一切」的 Rule 把 HTML 也长缓存，结果你改了内容海外还看旧版（第三节）；把错误页也缓存了，导致一次故障被固化；或者误设 no-store 到所有资源，CDN 形同虚设，源站裸奔。

还有一个容易忽略的点：CDN 默认会缓存部分状态码。Cloudflare 对 200/206/301 默认缓存 120 分钟，302/303 默认 20 分钟，404/410 默认 3 分钟。也就是说，如果你的源站短暂返回了一个 302 或错误页，而这条响应被缓存了，接下来二十分钟进来的客户拿到的都会是那个错误——你源站修好了也没用，得手动清除。

所以验收必须包含「出事后怎么收」：一是有没有一键清除缓存的入口，谁有权限；二是有没有「开发模式 / 绕过缓存」的开关，能立刻让客户直连源站；三是 CDN 自身故障时，DNS 能不能快速切回源站或切到备用服务商。这三样不全，等于把网站的「急停按钮」交给了别人。

七、给老板的一张验收清单：上线 CDN 后该盯哪几个数？

落到可执行，验收 CDN 不用懂每个指令，盯下面这几项就够了：

这张表不需要你懂 s-maxage 怎么写，但需要你在上线前让服务商逐项演示。CDN 本身不贵，贵的是「以为上了就万事大吉，结果旧价卖了三个月」或者「配置错了没人会收」。把这几项钉死，它才是真的在给海外客户加速。

最后提醒一句：CDN 是加速层，不是保险层。它掩盖不了源站慢，也替不了内容准。验收通过之后，真正的功课是持续盯着命中率和多地区首屏，而不是付完钱就把后台关掉。