WordPress 开了 CDN 首页仍慢或每次都像在回源：先核 HTML 是否命中边缘缓存，再查缓存头与回源链路

CDN 已经挂上了，测速图或海外客户却还在说「首页打开要等好久」。静态图片、CSS 看起来挺快，首屏文字却像是在远处一台机器上现算。有人建议换一家 CDN，有人怀疑主题太重，也有人直接把全站缓存时间拉到最长。这和近期已发的 挂 CDN 后后台样式错乱或静态资源 404、TTFB 很高但静态资源很快、改了报价客户还看见旧版、开了 Cloudflare 后询盘一直转圈或提交失败、启用 Redis 对象缓存后仍慢或出现陈旧数据 不是一类故障。「静态资源 404 / 后台样式错乱」卡的是回源 Host、HTTPS 和混合内容，资源根本没加载对；「TTFB 很高但静态资源很快」卡的是源站页面缓存、慢查询和对象缓存，讨论时往往还没先确认 HTML 有没有在边缘命中；「改了报价还看见旧版」卡的是五层缓存清不掉旧内容；「询盘转圈」卡的是 Bot、WAF 或整页缓存误伤了表单 POST；「Redis 对象缓存后仍慢」卡的是对象缓存连接、前缀和 drop-in。本文前提相反：CDN 已经接上，页面也能打开，慢的是 HTML 一直在回源，或回源那一段本身很慢。

更稳的顺序是：先看响应头，确认这次请求是 HIT、MISS、DYNAMIC 还是 BYPASS → 再把「经 CDN 访问」和「直连源站」的耗时分开记 → 再查源站返回的 Cache-Control、Set-Cookie 有没有把 HTML 排除出缓存 → 再看缓存键是不是被营销参数或 Cookie 打散 → 最后才为内容页配置 HTML 缓存与排除规则，并检查回源地域、协议和源站防火墙是否把 CDN 节点限流。别一上来换 CDN 厂商，或把全站 Cache Everything 打开再去修询盘和后台。本篇未取得可核验的百度指数或微信指数实时数值，也不用这类数字判断该不该先查命中率。DEVDIY 在 WordPress 站点上做性能核对时，也是先分清「没打到边缘」和「打到了但回源慢」，再决定改规则还是改源站。

适用场景

本文适用于：外贸 / 跨境询盘站或内容型独立站，已经接了 Cloudflare、阿里云、腾讯云或其他 CDN，首页、文章页或落地页在浏览器里能打开，但首字节时间仍然接近源站，或每次都像是重新生成。不适用于：挂上 CDN 后后台样式错乱、图片或脚本 404（按回源 Host、HTTPS 与混合内容那篇收口）；还没分清页面缓存、慢查询和对象缓存，只是源站 TTFB 偏高（按 TTFB 那篇收口）；改了文案或报价，客户仍看见旧版（按五层缓存清理那篇收口）；询盘提交转圈、被挑战页或 WAF 拦住（按防护误伤合法提交那篇收口）；对象缓存启用后数据陈旧或更慢（按 Redis 对象缓存那篇收口）。那些按各自专题处理，别和「HTML 没有命中边缘，或回源链路偏慢」混改。

先分清：未命中 vs 源站慢 vs 回源链路慢 vs 缓存键打散

「开了 CDN 还是慢」常见落在四条线上：

• HTML 根本没进边缘缓存：静态资源已经是 HIT，HTML 却一直是 MISS、EXPIRED、DYNAMIC 或 BYPASS。用户感受到的首字节，基本等于源站生成时间加上回源网络。
• 直连源站也慢：边缘只是把源站的慢如实传回来。这时应回到页面缓存、PHP 与数据库，而不是继续加 CDN 节点。
• 直连源站快，经 CDN 回源慢：问题在回源链路，比如节点和源站跨地域、回源协议或端口不一致、源站防火墙把 CDN IP 当成高频访问限流。
• 缓存键被打散：理论上允许缓存，可 utm_source、gclid、会话 Cookie 让同一页面变成大量不同的键，命中率低，看起来就像「每次都在回源」。

先记下：首页、一篇代表文章、一条广告落地页各请求几次后的缓存状态和 Age；绕过 CDN 直连源站的耗时；响应里有没有 no-cache、private 或整页 Set-Cookie；地址栏是否总是带着一串营销参数。明确这是 缓存命中和回源路径 的问题，不是资源 404，也不是询盘被拦住。

第一步：先看缓存响应头，再把边缘和源站分开测

不要先改全站缓存时间，也不要先换 CDN。先确认「这一次请求到底有没有命中」：

1. 看响应头里的缓存状态。Cloudflare 常见 cf-cache-status：HIT 是命中；MISS、EXPIRED 表示本次回源；DYNAMIC 表示该资源默认不在缓存范围（很多站点的 HTML 就是这种状态）；BYPASS 往往是源站头或绕过规则要求不缓存。阿里云、腾讯云等国内 CDN 多用 X-Cache、Via 一类字段，看到 HIT 或 MISS 即可，具体名称以服务商文档为准。Age 表示对象已在缓存中停留的秒数，连续刷新若始终为 0 或不出现，说明没有被缓存。
2. HTML 和静态资源要分开看。很常见的情况是图片、CSS、字体已经命中，HTML 却每次回源。这时页面「资源很快、首屏仍慢」，不能只用静态资源的命中率来判断整站已经加速。
3. 把经 CDN 的完整耗时和直连源站的耗时分开记。经 CDN 时记录连接、握手和首字节；再临时用源站 IP 解析同一域名（不改公共 DNS）测一次源站。直连也慢，瓶颈在源站，按页面缓存、PHP 和数据库继续查。直连快、经 CDN 回源慢，才优先查回源地域、协议和源站对 CDN 节点的限流。第一次慢、随后明显快，说明能命中，但缓存时间太短或被频繁清理。
4. 和「TTFB 很高但静态资源很快」区分：那篇主切口是源站生成慢。本文先回答「HTML 有没有在边缘命中」；只有确认一直在回源、且直连源站也慢时，才回到那一套源站排查，避免两边来回改。
5. 和「挂 CDN 后静态资源 404」区分：那是资源路径或回源 Host 错了，页面会缺样式、缺图。本文假设资源能加载，慢的是 HTML 生成和回源。
6. 用无痕窗口，尽量避开本机已登录态。登录后的请求常常被正确绕过缓存，拿它当「CDN 没用」会误判。

预期：能口头说清首页和代表内容页是 HIT、MISS、DYNAMIC 还是 BYPASS；知道慢在「没缓存」还是「回源那段」；不会只因为静态资源很快，就认为 HTML 也已经加速。

第二步：检查源站缓存头与缓存键，再给 HTML 补规则和排除

命中状态看清之后，再改规则。这一步仍然不要整站 Cache Everything，也不要为了追求命中率把后台和询盘页一起缓存。

1. 核对源站返回的 Cache-Control、Expires 和 Set-Cookie。HTML 若带 no-cache、private 或 max-age=0，即便 CDN 配了缓存 HTML，也可能因遵循源站头而不缓存。WordPress 对登录用户和部分动态页会主动发出这类头，这是正常的；要查的是 未登录的内容页 是不是也被写成了禁止缓存。响应里一旦带 Set-Cookie，多数 CDN 默认不缓存。统计插件、多语言插件、会话或购物车插件，都可能给所有页面种 Cookie，要找出是谁在未登录的内容页上也 Set-Cookie。
2. 看缓存键有没有被打散。utm_source、gclid、fbclid 这类营销参数，会让同一篇内容变成大量不同 URL。可以在 CDN 上忽略这些参数，让它们共享同一份缓存。按 Cookie 或 User-Agent 做缓存变体时，变体数量会成倍增加，只有确实存在独立移动端模板等需求时才值得开。多语言站应按 URL 路径或子域区分语言，而不是靠 Cookie 切换——后者既难缓存，也不利于收录。
3. 内容页可以在边缘缓存，但必须排除不能缓存的路径和状态。通常要排除 /wp-admin/、/wp-login.php、文章预览，以及商店的购物车、结账、账户页；带有 wordpress_logged_in_、wp-postpass_、购物车相关 Cookie 的请求应绕过缓存。边缘缓存时间可以设得稍长，但发布和更新时必须能自动清掉相关 URL，否则就会滑向「改了报价客户还看见旧版」那一类问题。关于缓存命中、源站头和回源链路的核对顺序，也可对照 WordPress CDN 缓存命中与回源链路排查，按响应头、边缘与源站对比、缓存键和回源网络逐段看，不必一上来更换厂商。
4. 静态资源用长期缓存，更新靠换文件名或版本参数。不必靠频繁清理整站缓存来更新 CSS 和图片；HTML 和静态资源的策略应分开，不要用同一条规则硬套。
5. 再检查回源链路本身。源站在海外、访客在国内（或反过来），回源跨境本身就慢，可考虑就近源站或启用分层缓存，减少大量边缘节点同时直连源站。确认回源协议、端口与源站监听一致，源站证书有效，并开启 keep-alive，避免每次回源先走一次 301。源站防火墙、WAF 或面板安全插件，可能把 CDN 节点 IP 当成高频访问而限流，表现是间歇性变慢或 502、504；把 CDN 回源 IP 段加入白名单，并在源站通过真实 IP 头记录访客，避免误伤。偶发的 502、504 还要看源站 PHP-FPM 是否在排队——那已经回到源站容量，而不是再加一条 CDN 规则就能解决。
6. 和「询盘被挑战页或 WAF 拦住」区分：给 HTML 加缓存规则时，询盘页、含表单的落地页应绕过整页缓存，也不要把表单 POST 交给「一律缓存」的规则。加速首页，不能顺便把询盘交死。

预期：未登录的内容页不再因为整页 Set-Cookie 或 private 而无法缓存；营销参数不再把命中率打散；后台、登录、预览和购物流程被明确排除；能解释「直连快、经 CDN 回源慢」时，慢在地域、协议还是源站限流。

改完怎么验收，先别急着换厂商

规则调整后，用无痕窗口对首页、一篇文章页、一个分类或落地页各请求三次，记录缓存状态和首字节时间：后面两次应能看到 HIT，且 Age 会增长。再发布一篇测试内容或改一句不会影响业务的文案，确认相关 URL 的缓存被清掉、新内容可见。登录后台后再访问前台，确认不会把登录态页面缓存给访客，也不会让已登录的自己一直看到未登录的缓存页。CDN 控制台里按天看命中率和回源流量，比单次测速图更适合判断规则有没有生效。

清理缓存后的第一批请求都会回源，短时间变慢是正常现象，可以只清与本次变更相关的 URL，或在发布后预热首页和主要落地页。源站和 CDN 也不必须是同一家云厂商，关键仍是回源距离、协议是否顺畅、源站有没有给回源 IP 限流。

五处过完，通常能分清三类情况：HTML 根本没进缓存（DYNAMIC/BYPASS，或源站头、Set-Cookie、缓存键把命中率打掉）；源站本身慢（直连也慢，应回到页面缓存和查询）；回源链路慢（直连快、经 CDN 回源慢，查地域、协议和源站限流）。先让该命中的内容页在边缘命中，再决定要不要加节点、换线路或继续优化源站。不要为了命中率把后台、登录和询盘页一起缓存，也不要把「静态资源已经很快」当成首页已经加速。

转载自 CSDN-专业IT技术社区

原文链接：https://blog.csdn.net/lgm252008/article/details/170486140