Fastly CDN测评：内容频繁更新时，即时缓存控制有什么价值

一篇新闻改了标题，正文已经更新，首页卡片还显示旧标题；一件商品调整价格，详情页正确，分类页和公开接口却各有一个版本。网站没有宕机，测速也不一定变慢，但读者和运营人员看到的内容对不上。

这类问题，才是评估Fastly即时缓存控制时应该放到桌面上的真实场景。

Fastly值得关注的地方，是让符合共享缓存条件的内容保留较长缓存时间，同时在业务发生变化时，按URL或内容标签主动失效。这样有机会减少“为了更新及时，只能把所有TTL设得很短”的妥协。

不过，清理指令被接受、边缘不再复用旧对象、新内容重新进入缓存，以及浏览器真正展示新版本，是几件不同的事。

CDNChart对这类产品的判断是：如果缓存控制能降低旧内容的暴露时间，避免无关页面跟着失效，并让发布后的回源压力保持可控，它才产生了可验证的业务价值。仅仅看到一次刷新变成MISS，不能支持这样的结论。本文依据已核实的产品机制分析，不把官方能力介绍当作CDNChart的实测成绩。

Fastly CDN测评，先确认评估的是哪一种服务

Fastly的CDN内容交付服务把可编程控制、缓存清理和可观测性放在产品核心位置。对内容团队来说，这意味着发布动作有机会直接驱动缓存更新；对开发团队来说，缓存规则可以进入配置管理和发布流程，而不必每次依赖人工登录控制台处理。

本文主要讨论Full Site Delivery中的CDN服务及其VCL配置路径。VCL可以理解为处理请求、缓存和回源行为的规则语言。

Fastly也提供Compute边缘计算，但不同缓存接口与SDK的行为不能一概而论：一篇CDN接入教程里的配置，不应原样套到所有Compute应用中。采购或迁移前，应先确认实际服务类型。

还有一个范围要划清：快速清理缓存，不会自动缩短用户到边缘节点的网络距离，也不能修复源站数据库慢查询。若网站的瓶颈是中国大陆某些运营商连接不稳定，或登录接口每次都要长时间计算，就要分别验证入口链路和动态回源。缓存更新能力可以与网络性能同时重要，但不能互相代替。

更新频繁，并不意味着内容完全不能缓存

“动态生成”和“每个用户都不同”经常被混为一谈。新闻正文由程序生成，却可能对所有访客一致；商品分类页频繁变化，也可能在相同地区、币种和语言条件下共享。真正决定能否缓存的，是响应是否可以安全复用，以及业务允许多长的旧内容窗口，而不是文件后缀是不是HTML。

Fastly即时缓存控制的吸引力，主要落在后两种方案。但成熟网站通常会混合使用这些方法：静态资源采用版本化URL，固定地址的公共页面通过内容事件清理，个人账户与交易操作走明确的非共享路径。没有必要为了统一配置，把所有资源都交给同一种失效机制。

判断收益时，还应看单个对象，而非只看全站更新频率。一个不断发布新闻的网站，单篇文章可能几个小时都不修改，仍有充分复用空间；某个接口如果几乎每次请求前都已经发生变化，长TTL与频繁清理也不能凭空创造大量命中。

把更新次数分摊到具体对象，再与这些对象的请求量对照，比一句“我们网站更新很频繁”更有决策价值。

短TTL也不是落后的做法。如果内容更新事件暂时不可靠，保留合理TTL可以限制漏清理造成的影响。相反，直接给页面配置很长的TTL，却没有失败告警和补偿机制，会让一次漏发事件长期暴露。长TTL应该建立在更新链路可靠之后，而不是用来证明命中率好看。

把浏览器和Fastly的缓存时间分开设计

同一个公共页面，可以要求浏览器每次复用前验证，同时允许Fastly较长时间使用边缘副本。Fastly的Surrogate-Control缓存控制提供了这种区分：在相关缓存新鲜度处理上，Fastly优先考虑它，再考虑Cache-Control里的共享缓存与普通缓存期限。

下面是一组用于解释分层策略的源站响应头，前提是页面公开、请求变体已正确区分，且服务没有其他冲突规则。数字是配置示例，不是统一推荐值：

Cache-Control: public, no-cache
Surrogate-Control: max-age=3600
ETag: "article-42-v7"
Surrogate-Key: article-42 section-tech home-feed

这里的no-cache允许浏览器保存响应，但要求再次复用前验证；Surrogate-Control则给Fastly设置示例性的边缘新鲜期。

因此，浏览器发出的验证请求可能由仍然新鲜的CDN副本处理，不代表每次都访问企业源站。源站更新后，仍需让对应边缘对象失效，不能靠浏览器验证替代CDN清理。

Fastly在面向终端用户的交付中会移除Surrogate-Control；Surrogate-Key也通常不会直接展示给普通访客。因此，在浏览器里看不到这两个字段，不能立即推断源站没配置。要结合源站响应、受控调试请求及当前服务规则核对，而不是为了方便排查，把所有内部标签长期暴露到公网。

如果还分不清no-cache与no-store的语义，可以先对照浏览器与CDN缓存策略的区别理解存储、复用和验证的关系，再核对Fastly实际配置。尤其要注意：已存在的浏览器副本不会因为CDN清理而被远程删除。固定URL一旦设置了很长浏览器新鲜期，后续再改服务器响应头，未必立即影响已经拿到旧策略的客户端。

Surrogate-Key的价值，是把页面还原成内容依赖关系

按URL清理适合目标明确、数量有限的更新。但修改一篇文章，受影响的可能还有栏目页、首页推荐、作者列表和公开接口。如果发布程序只知道文章地址，就容易出现“正文新了，列表旧了”。逐个维护这些URL可以解决小规模问题，随着语言、分页和接口版本增加，维护成本会迅速上升。

Fastly的Surrogate-Key内容标签机制允许一个缓存对象关联多个标签，同一标签也能关联多个对象。

发布程序清理某个标签时，目标是与它关联的缓存对象集合。它不是Fastly自动理解了业务关系，而是应用把这些关系明确告诉了缓存系统。

以商品为例，详情页、公开商品接口，以及已经展示该商品的列表，可以关联product-42；分类列表再关联category-shoes；首页推荐区关联home-feed。修改商品文案时，可以围绕商品依赖清理；改变分类归属或推荐顺序时，还需要触发对应列表关系的更新。标签应描述业务对象或内容集合，不能只是把URL换一种方式写进去。

最容易遗漏的情况，是新内容进入一个此前不包含它的列表。例如某商品刚被放进鞋类分类，旧分类页里没有它，自然也可能没有product-42标签。此时只清理商品标签，旧分类页仍然留在缓存中。更可靠的做法是让列表始终携带稳定的分类标签，并在成员增加、删除或排序变化时清理分类，而非只追踪已经出现的商品。

删除和权限变化也要进入同一套依赖模型。文章撤下后，详情页的旧200、列表中的摘要、搜索接口结果以及某些重定向，都可能需要处理。新地址首次发布前若已被访问过，还应检查是否存在缓存的404。

更新不能只围绕“成功页面换正文”设计，否则上线和下线阶段最容易漏项。

标签也有粒度成本。只使用一个全站标签，虽然实现容易，却让每次编辑都接近全站失效；把每个细微变体都拆成独立标签，则增加事件数量和管理难度。我们更建议从内容对象、稳定列表集合和必要的站点范围分层，观察哪些事件真正需要跨层失效，再决定是否增加细粒度标签。

实现时还要检查大小写、空格分隔、响应头长度限制和服务边界。清理操作针对具体服务，不会因为另一服务也使用了同名标签，就自动同步过去。新规则上线后，已经缓存的旧对象也不会凭空补上标签。迁移标签体系时，需要安排旧对象的失效与重新填充，不能只验证新请求返回的标签正确。

软清理与硬清理，解决的是两种不同问题

Fastly的Soft Purge软清理会把对象标记为过期，而不是立即让它彻底无法复用。是否还能提供旧内容、如何重新验证，取决于验证器、允许过期内容的配置及实际请求路径。不要把“软清理”简单翻译成“清理速度慢一点”，它改变的是内容失效后的使用方式。

在配置允许的情况下，stale-while-revalidate可以先交付旧响应，同时安排后台更新；stale-if-error则为符合条件的源站失败提供旧内容回退。Fastly对过期对象与重新验证的说明区分了这些流程。按照其软清理指南采用后台重新验证方案时，还需要同时配置stale-if-error。但正常更新与源站故障时允许旧内容的窗口，仍应该分别由业务决定，不能机械使用同一个期限。

如果一个公共文章页只修改了错别字，短暂展示旧文本通常可以接受；若是撤下错误公告、修正具有法律风险的内容，或者停止提供已泄露的信息，软清理就不应被当作停止交付旧副本的方案。此时应评估硬清理，同时在源站阻断错误内容再次生成，并检查其他CDN与应用缓存。已经下载到用户设备的内容，无法靠边缘清理收回。

硬清理让旧对象不能再匹配新的缓存查找，但不会主动把新内容推送到所有节点。后续请求还要获取新版本，或经过其他上游缓存层。因此，“旧对象不再可用”与“各地区已经有新对象可命中”之间，仍存在重新填充过程，访问延迟和源站负载都可能在这一阶段变化。

ETag和Last-Modified是这条链路里的重要细节。软清理后的条件验证，如果遇到错误的验证器，源站可能把实际已经变化的内容判断为未变化。此时即便Age重新计数，也不能证明正文更新。ETag应随实际响应版本变化；多语言、压缩或其他表示变体也需要符合各自的验证语义。

还有一个操作边界：Fastly的purge-all属于硬清理，不能仅靠添加软清理请求头改成软模式。不要把全站清理作为日常发布的快捷键。如果业务确实需要广泛失效，应先确认对象规模、回源承载和替代发布策略，再执行受控变更。

清理越快，越要认真计算重新填充的代价

一个热门页面失效后，大量用户可能同时等待新版本；如果同时失效的是成千上万个页面，即使每个页面只需要少量回源，也可能叠成发布高峰。更新更及时和源站更轻松并不自动同时成立。定向清理的价值之一，就是把重新填充范围约束在真正变化的内容上。

Fastly的请求合并机制可以让符合条件的相同对象请求共享一次上游获取，缓解缓存击穿。但不要把它理解成“全世界只回源一次”。不同缓存键、不同缓存层和服务路径仍会影响请求数量；明确绕过缓存的请求，也不能照搬可缓存对象的合并收益。

如果查询参数、语言头或Cookie产生大量无必要变体，同一页面可能分散成许多对象。清理后需要重新填充的对象数随之增加，命中率也难以恢复。反过来，为了减少变体而忽略真正影响内容的币种、地区或身份条件，则可能返回错误数据。缓存键设计必须先满足内容正确，再追求集中命中。

启用Shielding分层缓存后，边缘未命中可能由Shield层满足，并不必然到达企业源站。这有助于减少重复获取，但也意味着诊断需要看多层状态。不能把所有边缘MISS都计入企业源站请求，也不能只看某层HIT就宣布整条发布链路已经正确。

预热可以作为辅助，却不宜全站无差别抓取。更合理的是按预计访问量、生成成本和更新影响挑选关键入口，限制并发，并从业务地区验收。冷门对象可能被提前淘汰，预热过也不保证长期驻留。对源站来说，合理的发布顺序、必要的限速和准确标签，通常比粗放预热更值得优先做好。

CDNChart的验收方法：把发布过程拆成五个时刻

我们建议给发布链路增加五个记录点：内容提交时间、所有可回源实例准备好新版本的时间、清理请求发出时间、清理接口响应时间，以及各测试路径稳定看到预期版本的时间。它们分别反映业务发布、源站就绪、失效触发、接口处理和用户侧观测，不能合并成一个“刷新耗时”。

从内容提交到稳定看到新版本，可以评估整条发布链路；从清理请求发出到稳定看到新版本，可以观察失效与重新获取共同造成的等待。后者仍不是纯粹的Fastly清理传播延迟，因为它包含回源、应用处理和探测间隔。报告必须把指标名称写准确，避免把业务观测结果直接套成厂商承诺。

“稳定看到”需要提前定义。例如在固定观察窗口中，连续若干次请求都获得预期版本，而且没有再次退回旧版本。具体连续次数和窗口长度由业务决定。单次出现新版本后又返回旧版本，说明需要继续检查源站副本、缓存变体或交付路径，不能把第一次成功时间直接作为完成时间。

每条记录至少保留地区、运营商、请求URL、语言等内容变体、地址族、响应IP、状态码、正文版本标识、相关缓存头和耗时。版本标识最好由应用随内容生成，例如正文里的版本字段或与响应绑定的自定义头；不能由边缘每次临时生成一个新时间戳，制造“响应很新”的假象。

多地区观察要保持相同请求条件，并把中国大陆、港澳台和海外分开；大陆再关注实际用户运营商。CDNChart的多地区网站测速可辅助观察状态码、响应IP和访问耗时，但发布版本、清理事件和源站请求量，需要结合自建检查、服务日志与发布系统记录。不要把普通测速结果说成已经自动完成缓存一致性验收。

源站侧同步记录请求峰值、并发、CPU、数据库负载和错误比例，并将304条件验证与200响应的重新生成分开观察。在相同用户请求量下比较发布前后及不同策略，才能判断清理是否只是减少等待，却把压力转移给了应用。仅看一个周期内的平均回源量，容易漏掉短时峰值。

统计时同时报告稳定更新延迟的P50、P95，以及超时、失败和观察结束仍未更新的路径。后几类不能当作零延迟，也不能悄悄删除。若探测间隔是一秒，就不能据此声称验证了毫秒级传播；跨机器记录还要校准时钟。不同地区的P95也不能直接平均成一个全球P95。

为了把速度与正确性放到同一份报告，我们建议增加“预期版本成功比例”：在明确的观察窗口内，状态与正文都符合预期的请求数，除以全部实际发出的验收请求数。旧版本占比、访问失败占比另列。这样就不会出现“只统计成功更新的节点，所以传播看起来很快”的选择偏差。

实际检查时，先看正文版本，再解释HIT、MISS和Age

在自己控制的测试域名上，可以先用正常GET保存响应头和正文，发布后用相同URL重复观察。下面的curl示例会保存文件；Windows环境应使用curl.exe，并按终端语法调整换行。示例域名需要替换为经过授权的测试地址：

curl --silent --show-error --dump-header - --output page-before.html "https://www.example.com/articles/42"
curl --silent --show-error --dump-header - --output page-after.html "https://www.example.com/articles/42"

不要在验收请求中随手添加随机查询参数。它可能生成不同缓存键，让测试绕过原本要检查的旧对象。也不要只发HEAD请求，或只检查HTTP 200。确认page-after.html里的标题、版本字段和相关数据，再结合Age、X-Cache、X-Served-By、ETag解释发生了什么。

需要核对Fastly内部标签时，可以在受控排查中发送Fastly-Debug请求头；调试输出不应公开传播。有关HIT、MISS与Age的判断边界，最重要的一点是：它们说明缓存处理的线索，不直接说明内容是否正确。MISS拿到的也可能是尚未更新的源站副本，HIT同样可能命中已经更新的新对象。

curl --silent --show-error --dump-header - --output page-debug.html --header "Fastly-Debug: 1" "https://www.example.com/articles/42"

如果测试服务已给对象关联article-42标签，并且确实准备好执行定向硬清理，可以通过Fastly标签清理API触发该操作。以下是类Unix终端示例，变量应由受控环境提供；不要把真实令牌写入前端页面、公共脚本或文章：

curl --silent --show-error --fail-with-body --request POST --header "Fastly-Key: ${FASTLY_API_TOKEN}" "https://api.fastly.com/service/${FASTLY_SERVICE_ID}/purge/article-42"

不添加软清理头时，上述操作按默认硬清理语义处理。需要测试软清理时，再添加Fastly-Soft-Purge: 1，并先核对对应验证和过期内容策略。接口返回成功只用于登记清理事件，随后仍要检查正文版本。若某路径MISS仍返回旧正文，优先核对上游内容；若只有特定语言或参数版本旧，重点检查缓存键、标签覆盖和服务ID。

正确发布顺序，比反复点击清理更重要

一个值得纳入演练的故障是：源站A已更新，源站B仍在提供旧内容，发布程序立即触发清理。后续缓存填充如果取到B的响应，就可能再次保存旧版本。把它误判成“CDN清理没生效”，只会重复相同过程。发布前应先确认所有可能被选为回源目标的实例和应用缓存已经就绪，或把流量明确切到已就绪版本。

前端发布还涉及资源顺序。通常先准备新的版本化JS、CSS和图片，验证可访问，再更新引用它们的HTML或清单，随后清理固定地址的入口及必要列表。旧资源应按回滚和仍在使用旧HTML的客户端需求保留，不能在新HTML上线时立即删除全部旧文件，否则旧页面会遇到资源404。

内容写入和清理事件之间也需要可靠衔接。可以通过持久化事件队列或事务性发件箱记录待处理更新，保留失败重试和人工补偿入口。清理请求超时，应先按流程核对状态并受控重试，而不是假定完全没有生效。并发事件需要去重或合并，但合并等待本身也必须计入业务允许的更新窗口。

Fastly对清理方式与速率约束的说明区分了URL、标签清理和purge-all，批量操作也有边界。接入时应按实际账户和官方限制设计队列、退避与告警，而不是把事件数量当成无限。发布系统应保存服务ID、目标URL或标签、内容版本、请求与响应时间、结果及重试记录，不能把审计完全寄托在缓存访问日志上。

安全上还要单独检查URL清理请求鉴权。Fastly文档指出，URL清理默认不要求鉴权，并建议启用鉴权；其他清理请求默认需要鉴权。清理入口若可被滥用，攻击者即使不读取内容，也可能通过反复失效增加回源压力。令牌应限制到所需服务和操作，并有轮换、撤销及使用记录。

试用时至少对照四种发布状态

第一组保留当前CDN及现有策略，记录真实更新窗口与源站成本；第二组在Fastly上尽量保持相同缓存键、TTL、响应内容和安全要求，用来区分基础交付差异；第三组改用较长TTL配合定向硬清理；第四组只在业务允许的内容上加入软清理或过期内容回退。第三、第四组才主要回答即时缓存控制的增量价值。

每组都应包含目标详情页、关联列表和未改动的对照页。测试前确认这些对象已缓存，避免本来没有旧副本，却把发布后第一次请求当成清理成功。更新后既检查目标与关联内容是否改变，也看无关页面是否出现不必要的回源与延迟波动；仅凭一个Age值不能独立证明没有误清理。

试用前就应写明最大允许旧内容窗口、关键路径失败要求、源站承载上限和回滚目标。若新鲜度达标却突破源站承载上限，应先缩小失效范围或调整填充策略；若源站很轻松但旧版本持续超时存在，则不能用较高命中率抵消发布正确性问题。没有预先约定门槛，试用很容易变成挑选最漂亮的结果。

验收阶段还要覆盖普通更新、删除、分类成员变化、清理事件失败、源站部分实例未就绪，以及回滚。不要只演示最顺利的一次发布。性能测试也应分别观察稳定热缓存、失效后的首次获取和重新填充期间的请求，避免用发布前的低延迟掩盖发布时的尾部等待。

回滚尤其要分开记录：恢复上一版VCL配置，不等于源站内容恢复，也不会自动把已经失效的旧对象重新放回缓存。业务回滚需要让源站重新提供预期版本、处理相关失效，并再次验证页面与资源引用关系。若网站使用多CDN，清理与回滚流程还必须逐个覆盖实际交付系统，不能假设Fastly的标签事件会被其他厂商接收。

成本不能只看命中率，也不能只看CDN流量单价

较长TTL与准确清理，可能减少未变化内容的源站验证和重新生成，但不会自动减少用户下载的字节数。原本从源站交付的数据转到Fastly后，依然需要核算CDN交付与请求成本。Fastly的内容交付计费说明区分区域流量、请求及其他产品，实际采购还要按账户方案与合同确认，不能从“缓存更多”直接推出“总费用必然下降”。

建议把成本拆成CDN交付与请求、企业源站出流、源站计算和数据库、额外产品与支持、发布系统维护，以及更新错误造成的处理成本。图片优化、Compute、安全与可观测性需求是否包含在采购范围内，也应分别核对。CDN产品页同时出现这些能力，不代表购买基础交付后就自动获得全部功能。

请求命中率与字节命中率也要分开看。一批小型公共接口即使占用带宽不多，命中后仍可能显著减少昂贵的应用计算；大量图片命中虽然节省源站出流，却不一定解决数据库压力。对频繁更新网站，更有意义的问题是：节省了哪种回源，发布后又增加了多少重新生成，而非单独追求一个更高的HIT百分比。

运维成本往往决定收益能否落地。接入初期需要整理依赖标签、保护认证路径、建设清理事件与告警、维护规则版本，并练习故障回滚。如果团队只能人工逐条刷新，又没有足够流量或明显更新痛点，复杂能力带来的维护投入可能暂时超过收益。Fastly的可控性是优势，也意味着有人需要持续理解和维护这些控制。

哪些网站更值得评估，哪些需求应换一种解法

对新闻媒体、内容聚合、商品目录、公共数据接口和频繁发布的文档站，Fastly值得进入候选范围：它们往往存在固定URL、跨页面内容依赖，以及“不希望短TTL持续打源站，又不能等待很久才更新”的矛盾。前提是团队能接入内容事件，并愿意把版本正确性与源站承载一起验收。

以版本化静态文件为主、更新很少的小网站，可能通过可靠的资源命名和简单TTL就满足需求；用户专属账户、交易确认与权限决策，则不能依赖共享缓存的新鲜度保证正确。Fastly的HTTP缓存行为说明还特别指出，Authorization请求头本身并不自动阻止缓存。认证请求应设计明确的pass路径，并核对private等响应策略与自定义规则，不能把“带令牌”当作天然缓存隔离。

商品展示价格允许的更新窗口，应与订单提交时的权威价格校验分开；库存展示可以有缓冲，扣减库存却必须由交易系统处理。若需求要求每个用户立刻收到变化，还要评估轮询、推送或其他应用机制。清理CDN只影响后续相关请求，不会主动改写已经打开页面中的数据。

采购前还应追问的三个问题

Fastly即时缓存清理，能保证所有用户同时看到新版本吗？

不能据此作这样的保证。业务提交、源站就绪、边缘失效、重新获取和客户端展示是不同环节。验收应约定目标路径、允许的旧内容窗口、失败处理和版本判断方法，而不是只把清理接口的响应时间写进采购条件。

首页经常更新，是不是只能把整站缓存一起清掉？

不需要这样设计。首页整体变化时，可以清理首页对象或对应集合标签；若采用分块或独立接口，还可以进一步区分更新范围。但拆分也有额外请求和版本协调成本，应按真实依赖关系选择，不能为了更细的清理粒度无止境拆页面。

什么时候可以认为这项能力值得投入？

当相同业务负载下，旧版本暴露窗口达到要求，无关缓存没有被大面积波及，发布和回滚期间的源站峰值能够承受，并且总维护成本可以接受时，投入才有充分理由。CDNChart更看重这个结果：内容更新可控，同时保住未变化内容的缓存收益。它比一句“清理很快”，更能说明Fastly对这家网站究竟有没有价值。