CDN SSG看似简单，真正落地时却很容易踩坑。你有没有想过，一个完全由静态文件组成的网站，竟然会因为服务器宕机而无法访问？很多刚接触静态站点生成（SSG）的人会以为“静态”就等于“永远不会坏”，但现实是：只要你还依赖一台源站服务器，它就存在单点故障的风险。一旦服务器硬盘损坏、网络中断或遭受攻击，所有静态页面都会跟着消失。
今天这篇文章就是想跟你聊一个很实用的思路：利用CDN的边缘缓存机制，让SSG站点实现“零回源容灾”——也就是说，即便源站彻底离线，用户依然能从CDN节点上拿到完整的页面内容。我会尽量避开技术黑话，用场景化的方式来解释。
先从“静态站点生成（SSG）”到底是什么说起
实际操作要点
SSG的全称是Static Site Generator，中文叫“静态站点生成器”。常见的工具有Hugo、Jekyll、Next.js（导出模式）、Gatsby等。它的工作流程很简单：你写好Markdown文章，选好模板，然后运行一条命令，工具会把所有页面渲染成纯HTML、CSS、JavaScript文件，输出到一个文件夹里。
这些文件是“死”的，不需要数据库，不需要PHP或Node.js运行时。你把它们丢到Nginx或者Apache服务器上，用户访问时直接下载对应文件即可。相比WordPress这类动态网站，SSG的加载速度极快，安全性也更高（因为没有数据库注入风险）。
但问题在于：这些文件必须存放在某台服务器上。如果那台服务器挂了，用户就什么都看不到了。你以为自己躲过了动态网站的性能问题，却掉进了单点故障的坑。
CDN边缘缓存是什么？为什么能“救火”？
故障定位思路
CDN（内容分发网络）本质上是一张遍布全球的代理服务器网络。当你把网站接入CDN后，用户访问时不是直接请求你的源站，而是请求距离他最近的CDN节点。CDN节点会先检查自己有没有缓存过这个文件，如果有，直接返回；如果没有，就向源站要一份，然后缓存起来，下次再有同样的请求就能秒回。
这个“缓存”就是关键。对于SSG站点来说，所有页面文件都是静态的，而且很少变化（除非你重新构建发布）。因此你可以告诉CDN：这个文件缓存一年，甚至永久。只要缓存设得够长，CDN节点上的副本就等于一个“永不过期的副本”。哪怕源站后来宕机了，CDN节点手中的文件并不会消失。
这就是“零回源容灾”的核心——用户请求永远在边缘节点被打回，根本不会走到源站。源站只是用来“灌”数据的初始入口，灌满之后就可以“退休”了。
延伸阅读：此处可内链到“CDN SSG配置案例”相关文章。
关联教程：此处可内链到“CDN SSG部署与验证”内容。
零回源容灾的真正含义：用户无感知，运维零压力
容易忽略的细节
很多人对容灾的理解还停留在“服务器坏了赶紧切换到备用机”。但备用机也需要维护，也存在故障概率。而零回源容灾的思路更彻底：让回源这件事本身变成非必需的。
具体来说，你需要做到两点：
- 缓存覆盖率100%：确保所有HTML、CSS、JS、图片等静态资源都有缓存，并且缓存时长要足够长（比如31天甚至365天）。对于SSG站点，除了极少数动态交互（如评论框），主体内容都是静态的。
- 缓存永不过期（或容忍源站短暂不可用）：即使源站挂了，CDN节点也不能擅自删除缓存。大部分CDN（如Cloudflare、Akamai、又拍云、七牛云等）都支持配置“stale-while-revalidate”或“强制缓存”策略，允许在源站不可用时继续使用过期缓存。
一旦做到这两点，你的站点就具备了“离线可用”能力。用户看到的永远是缓存中的内容，无论源站是重启、迁移还是被攻击，都不影响阅读体验。
CDN SSG：具体怎么配置？从缓存策略到回源兜底
下面我以常见的CDN服务为例，讲一下配置要点。不需要担心品牌差异，核心逻辑是通用的。
第一步：设置合理的Cache-Control头
在源站的Nginx（或者其他Web服务器）上，对静态资源添加如下响应头：
location ~* .(html|css|js|png|jpg|gif|ico)$ {
expires 365d;
add_header Cache-Control "public, immutable";
}
“public”表示CDN可以缓存，“immutable”告诉浏览器和CDN这个文件永远不会变化，可以放心缓存。对于SSG站点的HTML文件，由于每次构建都会生成新文件名（或使用哈希版本），你可以放心设置immutable。
第二步：在CDN控制台开启“强制缓存”或“回源失效时使用缓存”
很多CDN默认情况下如果源站返回500或超时，会主动删除缓存并返回错误。你需要关闭这个行为，改成“即使回源失败，也返回缓存中的旧内容”。
- 在Cloudflare中，这叫“Cache Reserve” + “Edge Cache TTL”设置为“Respect Origin”；并且开启“Always Use HTTPS”保证缓存不会因协议问题失效。
- 在又拍云/七牛云中，通常有“回源失败时使用缓存”的开关，勾选即可。
- 在Akamai中，可以设置“stale-while-revalidate”和“stale-if-error”行为。
这一步是容灾的关键。当源站宕机时，CDN节点发现自己无法回源，就会检查本地是否有缓存，有则直接返回。这样用户看到的还是正常页面，只会缺失一些无法更新的动态数据（如最新文章）。
第三步：提前做缓存预热
为了让每个边缘节点都提前“吃饱”，你需要在每次构建部署后，立即向CDN发起预请求，让节点把热点页面都缓存起来。很多CDN提供“预热”API，你可以写个脚本在CI/CD流程中调用。
缓存预热的另一个好处是：避免首次访问的用户触发回源，减少源站压力。而对于容灾而言，预热可以保证所有节点在源站离线前就已经握有完整的副本。
第四步：监控缓存命中率与源站状态
配置完成后，建议定期查看CDN的缓存命中率。正常SSG站点的命中率应该接近100%（排除一些特殊的动态请求）。如果发现命中率下降，检查是不是缓存策略被覆盖，或者有新的URL没有被缓存。
同时可以设置源站健康检查告警。一旦源站离线，你不再需要着急修复（因为用户没受影响），但还是要尽快恢复源站以便下次更新内容。
常见误区与避坑指南——CDN SSG
我的处理经验
下面几点是我见过很多新手踩过的坑，列出来供你参考：
- 误区一：认为SSG不需要CDN，直接放对象存储就可以。 对象存储（如OSS、S3）本身也有高可用，但如果你只依赖一个地域的存储，依然有区域故障风险。CDN的边缘缓存可以跨区域提供冗余。
- 误区二：缓存时间设太长，更新内容怎么办？ 如果你每次构建生成新的文件路径（比如index.a1b2c3.html），旧版本会自动失效，无需担心缓存问题。如果你用固定路径（比如index.html），则需要使用“版本号”或“缓存刷新”来主动更新。
- 误区三：开启强制缓存后，源站恢复时用户看不到新内容。 这个可以通过“版本化文件名”解决。新的构建产生新的文件名，旧的缓存自动无人访问，无需手动清除。
- 误区四：零回源容灾等于不需要源站。 注意，源站仍是内容发布的唯一入口。如果你需要更新文章或修改模板，必须通过源站重新构建并推送。零回源指的是“用户请求不经过源站”，而非完全废弃源站。
想继续深入：此处可内链到“CDN SSG优化清单”文章。
相关阅读：此处可内链到“CDN SSG常见问题”专题。
总结：把鸡蛋放在很多篮子里
实际操作要点
SSG本身是一个很好的架构，但静态文件也需要保障高可用。通过CDN边缘缓存，你可以把“鸡蛋”同时放在全球成百上千个边缘节点上。每个节点都保存着你网站的完整副本，任何一个节点出问题，其他节点可以无缝接管。再加上“回源失败时使用缓存”的兜底策略，你甚至能容忍源站长时间离线。
这种架构非常适合博客、文档站、营销页面、静态电商首页等场景。如果你正在运维一个SSG站点，不妨花半天时间检查和配置CDN的缓存策略。一旦配好，你就能享受到“服务器关机，网站依旧在线”的奇特体验——对于运维来说，这才是真正的躺赢。
最后补充一句：技术没有银弹，零回源容灾的前提是你的站点几乎没有动态交互（登录、购物车等）。如果你需要实时数据，可以配合服务端渲染（SSR）或客户端异步加载。但大部分内容型网站，静态化加CDN缓存已经足够稳了。把这些步骤跑通后，CDN SSG基本就能稳定落地。
延伸阅读