![[图2，EdgeOne 昨日 L7 访问流量，显示 6.56 GB]](https://media.shuijingwanwq.com/2026/07/2-20-1024x480.png)
![[图4：EdgeOne 按 URL path 开始于 /en/ 筛选后的流量截图]](https://media.shuijingwanwq.com/2026/07/4-24-1024x664.png)
![[图3：执行核心升级时返回 524 No Reason Phrase]](https://media.shuijingwanwq.com/2026/07/3-28-1024x500.png)
我的 WordPress 站点目前采用了拆分后的 CDN 架构：
www.shuijingwanwq.com：腾讯云 EdgeOneen.shuijingwanwq.com：Cloudflaremedia.shuijingwanwq.com：Cloudflareadmin.shuijingwanwq.com：后台独立域名，不经过前台 CDN
这套架构在访问速度和流量拆分方面已经基本稳定，但在观察 CDN 数据时，我发现了一个比较明显的问题：
EdgeOne 和 Cloudflare 的缓存 Hit 比例都不算高，尤其是 HTML 页面仍然存在大量 MISS。
2026 年 7 月 20 日，我对中文站和英文站的 HTML 边缘缓存规则进行了统一调整，将 TTL 改为 12 小时。运行约三天后，我在 7 月 23 日重新查看两边的缓存数据，评估这次调整是否真正有效。
本文记录完整的分析、调整过程和阶段性结果。
一、为什么开始关注 CDN Hit 命中率
CDN 是否生效，不能只看域名是否已经接入，也不能只看页面偶尔访问是否很快。
更加关键的是：
- 请求是否真正由边缘节点返回；
- 同一个页面是否能够从 MISS 转为 HIT；
- 缓存是否过早过期；
- 大量 HTML 是否仍然频繁回源；
- 命中率提升后，源站压力和访问延迟是否随之下降。
在最初的连续请求测试中，EdgeOne 和 Cloudflare 都能够正常完成从 MISS 到 HIT 的转换。
例如，中文站首页第一次请求为：
eo-cache-status: MISS
TTFB: 6.29 秒
第二、三次请求则变为：
eo-cache-status: HIT
TTFB: 0.06～0.07 秒
中文文章页也能够从约 0.89 秒的 MISS，下降到约 0.07 秒的 HIT。
英文站使用 Cloudflare，同样能够从：
cf-cache-status: MISS
TTFB: 3.81 秒
转变为：
cf-cache-status: HIT
TTFB: 约 0.93～1.00 秒
这说明两套 CDN 的缓存机制本身没有失效。
真正的问题是：
虽然单个页面能够正常缓存，但站点整体的缓存复用率仍然偏低。
二、EdgeOne 调整前的缓存表现
我先在 EdgeOne 中筛选：
Host = www.shuijingwanwq.com
统计时间选择最近 7 天。
调整前，中文站共收到约 76.76 万次请求，其中：
| 缓存状态 | 请求数 |
|---|---|
| HIT | 38.75 万 |
| MISS | 33.71 万 |
| dynamic | 2.29 万 |
| other | 2.01 万 |
整体请求 Hit 比例约为：
38.75 ÷ 76.76 ≈ 50.5%
如果只统计可以直接比较的 HIT 和 MISS：
38.75 ÷（38.75 + 33.71）≈ 53.5%
也就是说，每 100 个可缓存请求中，大约只有 53 个从 EdgeOne 边缘缓存返回，另外约 47 个仍然需要回源。
这个结果不能算完全失效，但对于一个已经启用全页缓存和 CDN 的 WordPress 站点来说，仍然有比较明显的提升空间。
三、请求命中率尚可，但流量命中率更低
只看请求次数还不够。
如果命中的都是体积很小的请求，而体积较大的 HTML 页面经常 MISS，那么源站流量和实际访问体验仍然不会理想。
调整前的 EdgeOne 响应流量约为 15.73 GB：
| 缓存状态 | 响应流量 |
|---|---|
| MISS | 11.33 GB |
| HIT | 4.19 GB |
| dynamic | 118.18 MB |
| other | 94.25 MB |
整体流量 Hit 比例约为：
4.19 ÷ 15.73 ≈ 26.6%
只统计 HIT 和 MISS 时，流量命中率约为：
4.19 ÷（4.19 + 11.33）≈ 27.0%
这意味着：
EdgeOne 虽然命中了大约一半请求，但体积更大的响应更容易出现 MISS。
因此，当前真正需要优化的不是少量静态小文件，而是大量 WordPress HTML 页面。
四、MISS 流量主要来自正常的 200 页面
为了确认 MISS 是否主要由 404、攻击扫描或异常重定向造成，我进一步筛选：
缓存状态 = MISS
再按 HTTP 状态码查看流量分布。
结果如下：
| 状态码 | MISS 流量 |
|---|---|
| 200 | 9.68 GB |
| 301 | 856.23 MB |
| 404 | 771.66 MB |
| 524 | 9.36 MB |
| 500 | 2.67 MB |
其中状态码 200 的正常响应约占全部 MISS 流量的 85%。
因此可以确认：
低命中率的主要原因，不是大量 404 或异常请求，而是正常的 WordPress 前台页面频繁 MISS。
301 和 404 合计也超过了 1.6 GB，后续仍然值得关注，但它们不是此次问题的核心。
五、约 97% 的正常 MISS 流量来自无扩展名页面
继续限定：
缓存状态 = MISS
状态码 = 200
然后按资源类型查看。
数据中约有 9.39 GB 被 EdgeOne 归为“字段不存在”，另外包括：
| 资源类型 | MISS 流量 |
|---|---|
| 字段不存在 | 9.39 GB |
/ | 244.07 MB |
.xml | 38.24 MB |
.txt | 4 MB |
.js | 2.44 MB |
“字段不存在”约占 9.68 GB 正常 MISS 流量的 97%。
结合 URL Path 数据，可以判断这些请求主要是没有文件扩展名的 WordPress 路由，例如：
/
/page/2/
/page/3/
/page/132/
/2026/07/11/19354/
/category/...
/tag/...
也就是说：
当前真正拉低 Hit 的，主要是首页、文章、分类、标签和分页等 HTML 页面，而不是 CSS、JavaScript 或图片文件。
六、首页和大量分页页面反复 MISS
流量较高的路径包括：
| URL Path | MISS 流量 |
|---|---|
/ | 244.07 MB |
/page/3/ | 22.92 MB |
/page/132/ | 21.71 MB |
/page/4/ | 21.55 MB |
/page/2/ | 20.95 MB |
首页一周内产生了 244.07 MB 的 MISS 流量。
更值得注意的是，/page/132/ 这样的深层分页，MISS 流量也接近前几页。这说明搜索引擎和机器人会持续遍历站点归档，而不是只访问首页和前几页。
进一步按请求数查看时，Top 路径为：
| URL Path | MISS 次数 |
|---|---|
/ | 5478 |
/robots.txt | 713 |
/xmlrpc.php | 651 |
/feed/ | 394 |
/page/3/ | 393 |
不过这些 Top 路径合计只占全部正常 MISS 请求的一小部分。
绝大多数 MISS 仍然分散在大量长尾页面中。
这与我的站点实际情况比较吻合：
- 已发布文章数量较多；
- 分类、标签和分页页面很多；
- 很多页面访问频率不高；
- 同一个页面可能在缓存过期后才迎来下一次访问；
- 不同边缘节点都可能经历首次冷缓存。
七、最终找到的核心问题：EdgeOne HTML 只缓存 1 小时
在 EdgeOne 的规则引擎中，负责普通前台 HTML 的规则为：
HTML页面缓存（SEO安全）
规则排除了：
/wp-admin/
/wp-login.php
/wp-json/
/feed/
/xmlrpc.php
/wp-cron.php
但普通 HTML 页面使用的节点缓存 TTL 只有：
1 小时
强制缓存处于关闭状态。
对于文章数量较少、访问较集中的网站，1 小时可能仍然能够获得不错的命中率。
但对于长尾页面非常多的技术博客，1 小时明显偏短。
一个页面在某个边缘节点第一次被访问后进入缓存，如果接下来 1 小时内没有第二次访问，下次请求就可能再次回源。
当站点存在数千篇文章、大量标签和数百页分页时，这种情况会非常普遍。
八、Cloudflare 英文站同样存在命中率偏低的问题
英文站使用：
en.shuijingwanwq.com
由 Cloudflare 提供 CDN 服务。
调整前，在过去 24 小时、限定英文站 Host 的情况下，Cloudflare 数据为：
| 指标 | 调整前 |
|---|---|
| 总请求数 | 23.42k |
| Cache Hit Rate | 16.76% |
| 带宽 | 708.35 MB |
| HIT | 3.87k |
| MISS | 13.24k |
| EXPIRED | 1.64k |
| BYPASS | 1.83k |
| DYNAMIC | 931 |
虽然 Cloudflare 的 HTML 规则没有明确设置 Edge TTL，但源站响应中存在：
cache-control: max-age=14400
也就是 4 小时。
首页响应的 Age 已超过 3600 秒后仍然为 HIT，也证明 Cloudflare 的实际缓存时间确实超过 1 小时。
不过，16.76% 的整体命中率仍然偏低。
尤其是：
EXPIRED：1.64k
说明不少资源已经成功缓存，但在下一次访问前已经过期。
因此，仅仅把 EdgeOne 从 1 小时调整到 Cloudflare 当前的 4 小时，并不能充分解决问题。
九、最终决定：两边统一设置为 12 小时
经过前面的分析，我最终没有继续设计文章页、首页、分类页等多层规则。
虽然分层规则理论上可以更加精细，但也会带来额外维护成本。
对于我当前的需求，更重要的是：
- 提高整体 Hit；
- 保持 EdgeOne 与 Cloudflare 逻辑统一；
- 不让规则体系变得过于复杂；
- 避免为了提高命中率误缓存后台和个性化页面；
- 调整后能够简单观察结果。
最终采用的统一方案为：
普通 WordPress HTML 边缘缓存 TTL：12 小时
EdgeOne 配置
设置为：
节点缓存 TTL：12 小时
强制缓存：关闭
其他匹配条件、规则顺序保持不变。
Cloudflare 配置
设置为：
缓存资格：符合缓存条件
边缘 TTL：忽略缓存控制标头，使用 12 小时
浏览器 TTL：不单独设置
缓存密钥：不单独设置
Cloudflare 只覆盖边缘节点的缓存时间，不需要让用户浏览器也强制缓存 12 小时。
十、同时完善个性化 Cookie 绕过缓存
将 HTML 边缘 TTL 延长到 12 小时后，个性化请求的绕过规则也需要更加完整。
原来的规则只匹配：
wordpress_logged_in_
它只能覆盖 WordPress 已登录用户。
为了避免密码保护文章和评论者相关页面被公共缓存，我将两边的规则统一扩展为：
wordpress_logged_in_
wp-postpass_
comment_author_
规则名称也从：
WordPress 已登录用户绕过缓存
调整为：
WordPress 个性化 Cookie 绕过缓存
EdgeOne 正则
wordpress_logged_in_|wp-postpass_|comment_author_
匹配后执行：
节点缓存 TTL：不缓存
Cloudflare 表达式
(http.host eq "en.shuijingwanwq.com" and
(
http.cookie contains "wordpress_logged_in_" or
http.cookie contains "wp-postpass_" or
http.cookie contains "comment_author_"
))
匹配后执行：
绕过缓存
这样既延长了匿名访客的公共 HTML 缓存时间，也保留了登录、密码保护和评论者页面的安全边界。
十一、运行三天后，Cloudflare 命中率明显提升
2026 年 7 月 23 日，我重新查看英文站过去 24 小时的数据。
调整后的数据为：
| 指标 | 调整前 | 调整后 |
|---|---|---|
| 总请求数 | 23.42k | 20.94k |
| Cache Hit Rate | 16.76% | 20.25% |
| HIT | 3.87k | 4.12k |
| MISS | 13.24k | 10.65k |
| EXPIRED | 1.64k | 951 |
Cache Hit Rate 从：
16.76%
提升到：
20.25%
增加了 3.49 个百分点。
相对提升约为：
(20.25% - 16.76%) ÷ 16.76% ≈ 20.8%
虽然总请求量有所下降，但 HIT 次数反而从 3.87k 增加到了 4.12k。
这说明命中率提高不只是因为请求总量下降，缓存复用本身也确实改善了。
十二、Cloudflare 的 EXPIRED 下降约 42%
这次调整最直接的效果，体现在过期请求数量上。
调整前：
EXPIRED：1.64k
调整后：
EXPIRED：951
下降约：
(1640 - 951) ÷ 1640 ≈ 42%
这与将 Edge TTL 从约 4 小时提高到 12 小时的预期一致。
原来一部分页面虽然进入了缓存，但在下一次访问前已经过期。延长到 12 小时后，这些页面获得了更长的复用窗口，其中一部分请求就能够继续返回 HIT。
调整后，Cloudflare 仍然存在大量 MISS，主要原因包括：
- 英文站访问量低于中文站；
- 英文文章长尾较多；
- 访客分布在不同国家和地区；
- 不同 Cloudflare 节点需要分别经历冷缓存；
- 404 和机器人扫描请求较多。
因此，12 小时可以改善命中率，但无法消除所有首次 MISS。
十三、EdgeOne 的请求命中率也明显提高
7 月 23 日，我在 EdgeOne 中选择：
2026-07-22 11:30 ～ 2026-07-23 11:30
Host = www.shuijingwanwq.com
查看过去 24 小时的数据。
总请求约为 10.65 万次：
| 缓存状态 | 请求数 |
|---|---|
| HIT | 6.23 万 |
| MISS | 3.74 万 |
| other | 4377 |
| dynamic | 2501 |
整体请求 Hit 比例约为：
6.23 ÷ 10.65 ≈ 58.5%
如果只统计 HIT 和 MISS：
6.23 ÷（6.23 + 3.74）≈ 62.5%
调整前的近 7 天数据为：
- 整体请求 Hit 比例：约 50.5%
- 仅 HIT 与 MISS：约 53.5%
调整后分别达到：
- 整体请求 Hit 比例：约 58.5%
- 仅 HIT 与 MISS：约 62.5%
提高幅度约为 8～9 个百分点。
需要说明的是，调整前使用的是最近 7 天数据，调整后使用的是过去 24 小时数据，两者并不是严格相同的统计周期。
但请求 Hit 和流量 Hit 同时提高，仍然能够说明调整方向是有效的。
十四、EdgeOne 的流量命中率同步提升
过去 24 小时，EdgeOne 响应流量为 2.24 GB：
| 缓存状态 | 响应流量 |
|---|---|
| MISS | 1.40 GB |
| HIT | 796.86 MB |
| other | 22.63 MB |
| dynamic | 18.57 MB |
整体流量 Hit 比例约为：
796.86 MB ÷ 2.24 GB ≈ 35.6%
只统计 HIT 与 MISS 时，结果也约为 35.7%。
调整前的流量命中率约为：
27%
调整后约为：
35.7%
提高接近 9 个百分点。
这项提升尤其重要。
因为它说明此次调整并不只是让更多小请求获得 HIT，体积较大的 HTML 响应也有更多开始由 EdgeOne 边缘节点直接返回。
十五、最终结果汇总
| 域名与指标 | 调整前 | 调整后 |
|---|---|---|
| en Cache Hit Rate | 16.76% | 20.25% |
| en HIT 请求 | 3.87k | 4.12k |
| en MISS 请求 | 13.24k | 10.65k |
| en EXPIRED 请求 | 1.64k | 951 |
| www 整体请求 Hit | 约 50.5% | 约 58.5% |
| www 可缓存请求 Hit | 约 53.5% | 约 62.5% |
| www 整体流量 Hit | 约 26.6% | 约 35.6% |
从结果来看，中文站和英文站都出现了比较明确的改善。
尤其是：
- Cloudflare EXPIRED 明显下降；
- EdgeOne 请求 Hit 提高；
- EdgeOne 流量 Hit 同步提高；
- 两边的规则结构仍然保持统一；
- 没有开启全局强制缓存；
- 后台、登录、REST API 和个性化 Cookie 仍然保持绕过。
十六、为什么暂时不继续提高到 24 小时
既然 12 小时有效，是否应该继续提高到 24 小时甚至更长？
我目前决定暂时不继续调整。
原因包括：
- 12 小时已经带来了明确改善；
- 首页、分类、标签和分页属于会发生变化的聚合页面；
- TTL 继续增加后，内容更新延迟风险也会增加；
- 当前剩余 MISS 中有大量首次访问和跨节点冷缓存；
- 继续单纯增加 TTL，收益可能逐渐变小；
- 当前配置简单，维护成本较低。
因此，现阶段更合理的选择是：
保持 12 小时配置稳定运行，不再为了追求更高数字继续增加复杂规则。
如果以后发现首页或分类页面更新不及时，可以再考虑为首页设置更短 TTL、文章页设置更长 TTL。
但当前还没有必要进入这种精细化阶段。
十七、这次调整带来的实际经验
这次排查让我确认了几个比较重要的结论。
1. 单次测试正常，不代表整体命中率理想
页面能够从 MISS 转为 HIT，只能证明规则可以缓存。
整体命中率还取决于：
- 缓存 TTL；
- 页面访问频率；
- 长尾 URL 数量；
- 边缘节点分布；
- 查询参数；
- 页面更新和缓存清理；
- 机器人访问结构。
2. 请求 Hit 和流量 Hit 必须一起看
请求命中率较高，不代表大流量页面也得到了良好缓存。
我调整前的情况就是：
- 请求 Hit 约 50%
- 流量 Hit 只有约 27%
这说明较大的 HTML 页面仍然频繁回源。
3. WordPress 大型内容站不能只使用很短的 HTML TTL
文章、标签和分页非常多时，1 小时 TTL 会使大量长尾页面还没等到第二次访问就过期。
对于当前站点，统一到 12 小时后，效果明显更合理。
4. 提高 Hit 不应以牺牲个性化安全为代价
延长公共 HTML 缓存时，需要继续绕过：
wordpress_logged_in_
wp-postpass_
comment_author_
后台、登录、REST API、Feed 和 XML-RPC 等路径也应继续保持独立处理。
5. 不需要为了一个指标无限深入分析
在排查过程中，我一度考虑创建 Cloudflare 自定义仪表板，继续拆分请求、流量和各种缓存状态。
但对当前目标而言，现有数据已经足够支持判断。
最终真正有效的动作并不复杂：
将 EdgeOne 和 Cloudflare 的普通 HTML 边缘缓存统一设置为 12 小时
这也说明，技术分析需要适可而止。
在证据已经足够支持低风险调整时，继续增加分析维度可能只会提高时间成本，而不一定带来同等价值。
十八、结语
这次调整没有引入新的 WordPress 插件，也没有修改源站代码。
最终只完成了两项配置优化：
- 将 EdgeOne 和 Cloudflare 的普通 HTML 边缘缓存 TTL 统一为 12 小时；
- 将个性化 Cookie 绕过规则扩展为登录用户、密码保护文章和评论者 Cookie。
运行三天后，两边的缓存命中率都出现了明确改善：
- Cloudflare Cache Hit Rate 从 16.76% 提高到 20.25%；
- Cloudflare EXPIRED 下降约 42%；
- EdgeOne 请求 Hit 从约 50.5%提高到约 58.5%；
- EdgeOne 流量 Hit 从约 26.6%提高到约 35.6%。
这并没有让所有请求都变成 HIT。
对于文章、标签和分页数量很多的网站，大量长尾页面、首次访问和不同边缘节点的冷缓存仍然会产生 MISS。
但从当前数据看，12 小时已经是一个更适合本站现状的平衡值：
它明显提高了缓存复用率，同时没有把内容更新延迟扩大到难以接受的程度。
现阶段，我会继续保持这套配置，不再继续增加缓存时间，也不再增加更多分层规则。
Linux 服务器运维、部署与线上故障排查
如果你的网站或后端服务部署在 Linux 服务器上，遇到访问异常、Nginx 配置问题、MySQL / Redis 异常、Docker 服务不可用、磁盘占满、CPU / 内存过高等问题，可以联系我做一次远程排查。
适合以下场景：
✅ 网站打不开或访问不稳定
✅ Nginx / PHP-FPM 配置异常
✅ MySQL / Redis 性能或连接问题
✅ Docker 服务部署与维护
✅ 服务器迁移与环境配置
✅ CPU / 内存 / 磁盘异常排查
服务内容：
✅ Linux 环境检查
✅ 网站部署与迁移
✅ Nginx / PHP-FPM / MySQL / Redis 排查
✅ Docker 配置与维护
✅ 服务器性能分析
✅ 长期远程运维支持
如需咨询，请联系我，并注明：Linux 运维咨询。
联系方式：
Telegram：@shuijingwan
微信：13980074657
邮箱：shuijingwanwq@gmail.com
发表回复