![[图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)
一、背景：这不是推翻旧结论，而是修正旧结论的适用范围
几天前，我写过一篇文章：
CDN 上线前后性能对比实测：WordPress 缓存误判修正与真实加速效果验证
那篇文章主要解决的是另一个问题：
WordPress 性能优化不能只看“是否用了 CDN”，还要确认 W3 Total Cache、Cloudflare Cache Rule、响应头、HTML 缓存是否真正闭环。
当时我确认了几件事：
- W3 Total Cache 的 Page Cache 重新开启后，页面缓存是有效的；
- Cloudflare HTML Cache Rule 可以让首页 HTML 命中缓存；
cf-cache-status: HIT和age可以作为判断 Cloudflare 缓存命中的重要依据；- 我之前一度认为 W3TC Page Cache 在 Nginx 下不生效，其实是误判。
这些结论现在看仍然成立。
但是，最近几天流量持续下降，我又开始排查新的问题。结果发现：
缓存命中，不等于中国大陆访问一定快。
这篇文章，就是对上一篇结论的进一步修正：
Cloudflare 免费版可以让 WordPress HTML 命中缓存，但如果主要用户在中国大陆，尤其是移动、联通线路，访问 Cloudflare 普通全球网络仍然可能出现明显波动。
二、问题出现：boce 测速显示移动和联通线路非常慢
最近几天，我一直在观察网站流量下降的问题。今天再次使用 boce.com 测试首页：
https://www.shuijingwanwq.com/
第一次测试结果并不理想。
其中：
| 线路 | 平均响应 |
|---|---|
| 全部平均 | 5.245s |
| 电信平均 | 0.967s |
| 移动平均 | 7.286s |
| 联通平均 | 7.341s |
从这个结果看，电信线路还可以，但移动和联通非常慢。
如果只看这张图，很容易怀疑：
- WordPress 变慢了；
- W3TC 没有生效；
- Nginx 配置有问题；
- PHP 或 MySQL 拖慢了首页；
- Cloudflare HTML 缓存没有命中。
但这个判断还不够严谨。
因为上一篇文章已经证明过，缓存闭环有可能是正常的。所以我第一步不是继续改 WordPress，而是先看响应头。
三、确认缓存状态：Cloudflare 的确已经 HIT
在本地执行：
curl -I https://www.shuijingwanwq.com/
返回中有几行非常关键：
age: 908
cache-control: max-age=14400
cf-cache-status: HIT
cf-ray: a165b9c22fc3eb28-SJC
server: cloudflare
这说明：
- 首页 HTML 不是实时回源到 WordPress 生成；
- Cloudflare 缓存已经命中；
age有值，说明缓存已经存在一段时间；cf-cache-status: HIT说明这次请求是由 Cloudflare 缓存返回的。
也就是说，这次慢，不是因为 WordPress 实时生成首页太慢。
但另一个信息很刺眼：
cf-ray: ...-SJC
SJC 通常表示 Cloudflare 的 San Jose 节点。也就是说，我在成都移动网络访问中文主站时，请求很可能被 Cloudflare 路由到了美国圣何塞节点。
继续用完整耗时命令测试：
curl -o /dev/null -s -w \
"DNS: %{time_namelookup}s\nConnect: %{time_connect}s\nTLS: %{time_appconnect}s\nTTFB: %{time_starttransfer}s\nTotal: %{time_total}s\nRemote IP: %{remote_ip}\n" \
https://www.shuijingwanwq.com/
结果：
DNS: 0.001029s
Connect: 1.278439s
TLS: 2.267914s
TTFB: 3.082981s
Total: 6.072956s
Remote IP: 172.67.216.242
这个结果说明：
- DNS 很快；
- TCP 建连慢；
- TLS 握手慢；
- TTFB 慢；
- Total 总耗时超过 6 秒；
- Remote IP 是 Cloudflare IP。
所以问题基本可以定性为：
成都移动直连 Cloudflare 免费版时，即使缓存已经 HIT，链路仍然可能很慢。
四、Cloudflare China Network：普通 Cloudflare 免费版不等于中国大陆加速
后来我查了一下 Cloudflare 官方文档，发现这个问题并不是个例。
Cloudflare 官方文档明确说明，想要快速、可靠地向中国大陆用户交付内容，需要中国大陆境内基础设施；如果流量被路由到中国境外服务器，会遇到更高延迟和可靠性问题。Cloudflare China Network 正是为了解决这个问题，它通过 Cloudflare 与 JD Cloud 合作，在中国大陆数据中心运行部分 Cloudflare 性能和安全产品。
参考：
Cloudflare China Network 官方文档
但 Cloudflare China Network 不是普通免费版、Pro 或 Business 默认拥有的能力。官方接入流程要求准备 ICP 备案或许可证、在网站页脚展示 ICP 号，并由 JD Cloud 审核域名内容。
参考：
Cloudflare China Network Get started
对我来说，ICP 这一关不是最大问题。我的域名早在 2013 年就已经备案。
真正的问题是：
Cloudflare China Network 更像企业级方案，而不是个人技术博客现阶段轻易接入的普通 CDN 选项。
五、第二次 boce 测试又变快了：这说明问题是波动，而不是单次故障
过了一会儿，我再次用 boce 测试首页。
这次结果明显好很多：
| 线路 | 平均响应 |
|---|---|
| 全部平均 | 1.256s |
| 电信平均 | 1.033s |
| 移动平均 | 1.799s |
| 联通平均 | 0.895s |
如果只看第二次测试，似乎可以认为 Cloudflare 免费版还不错。
但结合第一次 boce、本地成都移动 curl、cf-ray: SJC 等结果，更合理的判断不是“问题消失了”，而是：
Cloudflare 免费版对中国大陆访问不是稳定地慢，而是波动较大。
有时可以接受，有时移动、联通会突然非常慢。
对于普通浏览体验来说，这可能只是偶尔慢一下；但对于一个依赖搜索流量、广告展示、联盟营销转化的 WordPress 博客来说，这种波动值得重视。
六、搭建灰云测试域名：cn-test.shuijingwanwq.com
为了避免继续猜测，我决定做一个最简单、最干净的对照实验。
实验目标是：
同一个静态 HTML 文件，一个通过 Cloudflare 免费版访问，一个绕过 Cloudflare 直连阿里云 ECS，看中国大陆访问到底谁更快。
我新建了一个测试子域名：
cn-test.shuijingwanwq.com
在 Cloudflare DNS 中设置为：
DNS only / 灰云
也就是说，这个子域名不经过 Cloudflare CDN，而是直接解析到阿里云杭州 ECS。
Cloudflare 官方文档中也说明，DNS 记录的代理状态决定 HTTP/HTTPS 流量是否经过 Cloudflare 网络；灰云 DNS only 时，请求会直接访问源站。
参考：
Cloudflare DNS Proxy status 官方文档
服务器使用的是 OneinStack，所以我直接用 OneinStack 的 vhost.sh 添加了新的 Nginx 虚拟主机：
~/oneinstack/vhost.sh
选择 Let’s Encrypt 申请证书，域名填写：
cn-test.shuijingwanwq.com
最终生成：
Virtualhost conf: /usr/local/nginx/conf/vhost/cn-test.shuijingwanwq.com.conf
Directory of: /data/wwwroot/cn-test.shuijingwanwq.com
Let's Encrypt SSL Certificate: /usr/local/nginx/conf/ssl/cn-test.shuijingwanwq.com.crt
SSL Private Key: /usr/local/nginx/conf/ssl/cn-test.shuijingwanwq.com.key
七、创建静态测试页面，避免 WordPress 干扰
为了让测试尽可能干净，我没有直接测试 WordPress 首页，而是创建了一个静态文件：
/data/wwwroot/cn-test.shuijingwanwq.com/cdn-test.html
内容如下：
<!doctype html>
<html>
<head>
<meta charset="utf-8">
<meta name="robots" content="noindex,nofollow">
<title>CN Test</title>
</head>
<body>
<h1>CN Test</h1>
<p>This is a direct origin test page for cn-test.shuijingwanwq.com.</p>
</body>
</html>
为了避免搜索引擎收录测试域名，我还创建了：
robots.txt
内容：
User-agent: *
Disallow: /
服务器本机测试：
curl -k -I --resolve cn-test.shuijingwanwq.com:443:127.0.0.1 https://cn-test.shuijingwanwq.com/cdn-test.html
返回：
HTTP/2 200
server: nginx
公网测试：
curl -I https://cn-test.shuijingwanwq.com/cdn-test.html
返回：
HTTP/2 200
server: nginx
没有出现：
server: cloudflare
cf-cache-status
cf-ray
这说明 cn-test 已经是灰云直连阿里云 ECS。
八、复制同一静态文件到主站，保证对比公平
为了保证对比公平，我把同一个 cdn-test.html 复制到主站目录：
cp /data/wwwroot/cn-test.shuijingwanwq.com/cdn-test.html /data/wwwroot/www.shuijingwanwq.com/cdn-test.html
chown www:www /data/wwwroot/www.shuijingwanwq.com/cdn-test.html
这样得到两个测试地址：
https://cn-test.shuijingwanwq.com/cdn-test.html
https://www.shuijingwanwq.com/cdn-test.html
两者差异只有一个：
cn-test：灰云，直连阿里云 ECS
www：橙云，经过 Cloudflare 免费版
这比直接测试 WordPress 首页更可靠，因为它排除了：
- PHP 执行；
- MySQL 查询；
- WordPress 插件；
- 主题渲染；
- 页面缓存状态；
- 首页内容体积差异。
九、成都移动本地测试：阿里云直连明显更快
在成都移动家庭网络下，关闭 VPN 后执行：
for url in \
https://cn-test.shuijingwanwq.com/cdn-test.html \
https://www.shuijingwanwq.com/cdn-test.html
do
echo "===== $url ====="
for i in {1..5}; do
curl -o /dev/null -s -w \
"Test $i | DNS:%{time_namelookup}s Connect:%{time_connect}s TLS:%{time_appconnect}s TTFB:%{time_starttransfer}s Total:%{time_total}s IP:%{remote_ip}\n" \
"$url"
sleep 2
done
done
灰云直连阿里云 ECS 结果：
Test 1 | DNS:0.646942s Connect:0.691377s TLS:0.747487s TTFB:0.790079s Total:0.790187s IP:121.40.248.29
Test 2 | DNS:0.010986s Connect:0.055257s TLS:0.111520s TTFB:0.153581s Total:0.153780s IP:121.40.248.29
Test 3 | DNS:0.194935s Connect:0.239629s TLS:0.294280s TTFB:0.336752s Total:0.336899s IP:121.40.248.29
Test 4 | DNS:0.013646s Connect:0.052931s TLS:0.106207s TTFB:0.143662s Total:0.143917s IP:121.40.248.29
Test 5 | DNS:0.013102s Connect:0.057821s TLS:0.113634s TTFB:0.156147s Total:0.156304s IP:121.40.248.29
Cloudflare 免费版结果：
Test 1 | DNS:0.856172s Connect:1.494555s TLS:1.836330s TTFB:2.189768s Total:2.715783s IP:104.21.78.52
Test 2 | DNS:0.013359s Connect:0.348307s TLS:2.060387s TTFB:2.316640s Total:2.316704s IP:104.21.78.52
Test 3 | DNS:0.002189s Connect:0.237458s TLS:0.659885s TTFB:1.596999s Total:1.597418s IP:172.67.216.242
Test 4 | DNS:0.003584s Connect:0.289218s TLS:0.864385s TTFB:1.799406s Total:1.799621s IP:104.21.78.52
Test 5 | DNS:0.002377s Connect:0.241457s TLS:0.696943s TTFB:1.519057s Total:1.519200s IP:104.21.78.52
结果非常明显。
灰云直连阿里云 ECS，除了第一次 DNS 冷启动，其余基本在：
0.14s - 0.34s
Cloudflare 免费版则基本在：
1.5s - 2.7s
并且 Cloudflare 版本已经确认是缓存命中：
cf-cache-status: HIT
cf-ray: ...-SJC
这说明它不是回源慢，而是中国大陆到 Cloudflare 普通网络的访问链路慢。
十、boce 对比：灰云直连平均 0.478s，Cloudflare 平均 1.755s
随后，我在 boce.com 分别测试这两个地址。
1. 灰云直连阿里云 ECS
测试地址：
https://cn-test.shuijingwanwq.com/cdn-test.html
结果：
| 线路 | 平均响应 |
|---|---|
| 全部平均 | 0.478s |
| 电信平均 | 0.36s |
| 移动平均 | 0.675s |
| 联通平均 | 0.391s |
2. Cloudflare 免费版
测试地址：
https://www.shuijingwanwq.com/cdn-test.html
结果：
| 线路 | 平均响应 |
|---|---|
| 全部平均 | 1.755s |
| 电信平均 | 2.297s |
| 移动平均 | 1.862s |
| 联通平均 | 1.104s |
两者对比：
| 测试对象 | 平均响应 |
|---|---|
| 阿里云 ECS 灰云直连 | 0.478s |
| Cloudflare 免费版 | 1.755s |
Cloudflare 免费版大约慢了 3.6 倍。
这次测试变量非常少：
- 同一台服务器；
- 同一个静态 HTML 文件；
- 同样是 HTTPS；
- 一个走阿里云 ECS 直连；
- 一个走 Cloudflare 免费版。
所以这个结果比直接测试 WordPress 首页更有说服力。
十一、对上一篇文章结论的修正
回到上一篇文章：
CDN 上线前后性能对比实测：WordPress 缓存误判修正与真实加速效果验证
那篇文章的结论可以保留，但需要加上适用范围。
旧结论可以概括为：
Cloudflare CDN + W3TC Page Cache 命中后，网站性能明显提升。
现在更准确的结论应该是：
Cloudflare CDN + W3TC Page Cache 命中后，海外访问和缓存闭环表现更好；但中国大陆访问是否变快，取决于 Cloudflare 普通网络在当地运营商线路上的路由质量。对于我的中文主站，阿里云 ECS 灰云直连在本次测试中明显快于 Cloudflare 免费版。
这不是否定 W3TC，也不是否定 Cloudflare。
真正要修正的是：
CDN 不是抽象意义上的“越多越好”，而是要看用户在哪里、线路怎么走、缓存是否命中，以及边缘节点是否真的离用户更近。
十二、为什么不建议按语言目录拆 CDN
一开始我考虑过一种架构：
www.shuijingwanwq.com 中文主站 → 国内 CDN
www.shuijingwanwq.com/en/ 英文站 → Cloudflare
但仔细分析后，这个结构并不干净。
原因是 DNS 和 CDN 接入通常首先按 hostname 生效，而不是按 URL 目录生效。
浏览器访问：
https://www.shuijingwanwq.com/en/
第一步解析的是：
www.shuijingwanwq.com
DNS 这一层并不知道后面的：
/en/
Cloudflare 的代理状态也是针对 DNS 记录的，决定某个主机名的 HTTP/HTTPS 流量是否经过 Cloudflare。
参考：
Cloudflare DNS Proxy status 官方文档
所以，常规、干净、低风险的方式无法实现：
www/ → 国内 CDN
www/en/ → Cloudflare
理论上可以通过多层 CDN、路径回源、反向代理等方式绕出来，但链路可能会变成：
用户 → 国内 CDN → Cloudflare → 源站
这不仅不干净，还会带来很多问题：
- 链路更长；
- 缓存更复杂；
- SSL、Host、SNI 更容易出问题；
- WordPress 登录、Cookie、跳转可能异常；
- Polylang canonical 和 sitemap 可能混乱；
- 排查问题会非常痛苦。
所以，如果按语言拆，真正干净的结构应该是：
www.shuijingwanwq.com 中文站
en.shuijingwanwq.com 英文站
但这又会带来新的 SEO 迁移成本。
十三、为什么长期更合理的方案可能是按地区分流，而不是按语言拆分
进一步想，我发现“按语言拆 CDN”本身也不一定符合真实访问场景。
我的网站真实情况并不是：
中文用户只访问 /
海外用户只访问 /en/
更可能是：
中国大陆用户：可能访问中文页面，也可能访问 /en/ 英文页面
海外用户：可能访问 /en/ 英文页面，也可能访问中文页面
所以更合理的长期方向不是：
中文目录 → 国内 CDN
英文目录 → Cloudflare
而是：
中国大陆用户访问 www → 国内 CDN
海外用户访问 www → Cloudflare
也就是说：
同一个 URL：
https://www.shuijingwanwq.com/
https://www.shuijingwanwq.com/en/
根据访问者所在地区，走不同 CDN。
这个方案的好处是：
- 不需要把
/en/迁移到en.shuijingwanwq.com； - Polylang URL 结构保持不变；
- canonical、sitemap、GSC、内链都不用大改；
- 国内用户无论访问中文还是英文，都走国内 CDN；
- 海外用户无论访问中文还是英文，都走海外 CDN；
- 更符合“网络质量按地区差异巨大”的现实。
Cloudflare Load Balancing 的 Geo steering 就是类似思路：根据国家、地区或数据中心把访问流量导向不同资源池；Cloudflare 文档也说明 Geo steering 可让访问者访问更接近自己的 endpoint，以改善页面加载性能。
参考：
Cloudflare Geo steering 官方文档
不过，这种方案不是简单加一条 DNS 记录就能完成。它需要：
- 智能 DNS；
- GeoDNS；
- 全球流量调度；
- 多 CDN 配置；
- 国内 CDN CNAME；
- 海外 CDN CNAME；
- SSL 证书统一；
- 源站回源策略；
- 缓存清理策略；
- 故障切换策略。
阿里云 DNS 文档中也说明，CNAME 常用于 CDN、企业邮箱和全局流量管理等场景。
参考：
Alibaba Cloud DNS 添加解析记录文档
所以我的判断是：
按地区分流，很可能比按语言拆 CDN 更适合作为长期方案；但它适合作为后续架构规划，不适合在当前流量波动期马上折腾。
十四、当前阶段的三个可选方案
结合这次测试，我现在大致有三个方案。
方案一：继续使用 Cloudflare 免费版
优点：
- 不需要继续折腾；
- 当前配置已经跑通；
- HTML 缓存已经 HIT；
- 对海外访问和英文站更友好；
- DNS、SSL、缓存规则、安全防护都在一套系统里。
缺点：
- 中国大陆访问波动较大；
- 移动、联通可能绕路；
- 对当前国内占比接近 80% 的流量不够友好；
- 可能影响用户体验、广告展示和联盟营销转化。
方案二：购买 Cloudflare China Network
优点：
- 继续保留 Cloudflare 统一体系；
- 中国大陆访问可以接入中国大陆境内网络；
- 理论上更适合“全球站 + 中国访问”的统一架构。
缺点：
- 更偏企业级方案；
- 需要 ICP 和内容审核；
- 可能涉及较高成本；
- 对个人技术博客现阶段未必划算。
我的域名 2013 年已经备案，ICP 不是主要障碍。真正需要评估的是商业可行性。
方案三：长期做按地区分流
长期目标可以是：
中国大陆用户 → 国内 CDN
海外用户 → Cloudflare
而不是：
中文站 → 国内 CDN
英文站 → Cloudflare
这种方案对我的站更合理，因为中国大陆用户也可能访问 /en/，海外用户也可能访问中文内容。
但这需要智能 DNS / GeoDNS / 全球流量调度，不适合马上动。
十五、我当前的决定：先不继续折腾 CDN，但保留测试结论
经过这次测试，我对 Cloudflare 免费版的定位更清楚了。
它适合：
- 海外访问；
- 英文站；
- 全球化尝试；
- DNS 管理；
- SSL；
- 安全防护；
- 静态资源缓存；
- 低成本 CDN 入门。
但它不一定适合：
- 以中国大陆用户为主的中文 WordPress 主站；
- 对移动、联通访问稳定性要求高的网站；
- 希望国内访问长期稳定低延迟的场景。
我现在暂时不想继续大幅折腾 CDN。短期先保持现状，但保留 cn-test.shuijingwanwq.com 这个灰云测试域名，作为后续对照样本。
如果后续国内访问继续影响流量和转化，再考虑：
短期：中文主站整体切回国内 CDN
长期：研究同一 www 域名按地区分流
十六、最终结论
这次排查给我的最大提醒是：
缓存命中只是 CDN 优化的第一步，线路质量才决定真实访问体验。
对于我的 WordPress 博客来说：
W3TC Page Cache 是必要条件；
Cloudflare HTML Cache Rule 是有效的；
cf-cache-status: HIT 说明缓存闭环没问题；
但中国大陆访问 Cloudflare 免费版仍然可能绕路；
灰云直连阿里云 ECS 在本次中国大陆测试中明显更快；
长期最合理的方向，可能不是按语言拆 CDN，而是按访问地区分流。
因此，上一篇文章的结论需要升级为：
WordPress 性能优化不能只看缓存是否命中，还要看目标用户所在区域、运营商线路、CDN 节点分配和实际访问路径。
一句话总结：
Cloudflare 免费版不是绝对意义上的“中国大陆加速器”。它更像一个低成本全球化入口；如果网站当前主要用户仍在中国大陆，就必须单独评估国内线路质量，而不能只看
cf-cache-status: HIT。
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
发表回复