缓存策略不当导致网站加了cdn变慢了的典型案例分析

很多人以为只要挂了CDN就能加速，但实际会出现反效果，常见原因是缓存策略配置不当导致大量回源请求、缓存未命中、或者缓存被频繁清除。比如：Cache-Control设置为no-cache/no-store，或者TTL太短，会让CDN频繁向源站发起验证和回源，增加响应时延。

表现包括首字节时间（TTFB）变长、资源加载顺序被阻塞、以及浏览器瀑布图中大量“Waiting (TTFB)”或“CONNECT”阶段占用时间。若CDN和源站之间没有启用压缩或keep-alive，也会放大延迟。

确保评估静态与动态资源并分别制定缓存策略，避免“一刀切”配置。

常见错误包括：1）对静态资源设置短TTL或禁止缓存；2）缓存键包含不必要的Cookie或全部Query String；3）频繁自动清理缓存（如每次部署全量Purge）；4）未使用Surrogate-Control或Edge缓存层；5）错误地缓存动态页面或敏感内容造成回源验证。

这些错误使CDN无法发挥边缘缓存作用，导致每次请求都到源站去取数据，放大源站压力并增加网络往返时间。

优先检查Cache-Control、Expires、Set-Cookie、Vary头，以及CDN面板的缓存规则与日志。

排查步骤：1）用浏览器开发者工具查看Response Header（Cache-Control、Age、Via）；2）用curl -I或httpie检查回源头信息；3）查看CDN访问日志与命中率指标；4）做A/B测试对比启用/禁用CDN的响应时间；5）分析源站日志查看回源并发与错误率。

推荐工具：Chrome DevTools、curl、WebPageTest、GTmetrix、CDN控制台的实时统计与Trace功能。

若Age为0且每次请求均产生回源记录，说明缓存未命中或被短TTL清空。

修复策略包括：为静态资源设置较长的TTL并采用文件指纹（hash）策略；对动态页面使用缓存分层（Edge cache + Origin shield）和短期缓存结合stale-while-revalidate；清理不必要的Cookie或移除其对缓存键的影响；优化Cache-Control与Surrogate-Control头；合理使用Purge与Invalidate策略，避免频繁全量清除。

推行版本化部署（资源名带hash）、在CDN配置中按路径规则区分静态/动态、对API接口使用Cache-Control: public, max-age=0, s-maxage=60, stale-while-revalidate=30等组合。

添加Origin Shield或中转层以减少回源次数，开启压缩与HTTP/2或HTTP/3以降低传输延迟。

案例：某电商站上线CDN后首页TTFB从200ms变成800ms。排查后发现：页面HTML带有Set-Cookie且Cache-Control: no-cache，同时CDN缓存键默认包含全部Cookie，导致边缘节点每次回源获取个性化Cookie版本。解决措施：对HTML设置Edge Cache TTL（s-maxage），在CDN层剥离无关Cookie，不对带Cookie的响应做全量回源，采用stale-while-revalidate并启用Origin Shield。改造后TTFB回落至180ms，边缘命中率从5%提升至85%。

这个案例强调了缓存策略与HTTP头的一致性，以及在CDN上正确配置缓存键的重要性，避免因为个别标头或Cookie把整个页面流量逼回源站。

1）区分资源类型并制定TTL；2）文件指纹化；3）避免将无关Cookie纳入缓存键；4）使用边缘缓存与Origin Shield；5）监控命中率与回源比率。

来源：缓存策略不当导致网站加了cdn变慢了的典型案例分析