一、背景：为什么要从 Cloudflare Free 迁移出来
前几天我连续测试了 Cloudflare Free 在中国大陆访问 WordPress 主站的表现。
从结果看，Cloudflare Free 并不是完全不可用。尤其在海外访问、静态资源缓存、HTTPS、全球边缘网络这些方面，它依然非常优秀。
但问题出在中国大陆线路。
在我的网站场景里，Cloudflare Free 对中国大陆用户并不稳定。尤其是移动、联通线路，偶尔会出现访问慢、响应时间波动大、部分节点绕路明显的问题。
我的网站结构是：
中文主站：https://www.shuijingwanwq.com/
英文站：https://www.shuijingwanwq.com/en/
源站：阿里云杭州 ECS
程序：WordPress + Polylang + W3 Total Cache
我不想拆成：
中文站：www.shuijingwanwq.com
英文站：en.shuijingwanwq.com
也不想新增：
cn.shuijingwanwq.com
因为网站里的图片、CSS、JS、上传文件、WordPress 资源路径都是共用的。如果为了 CDN 而改变站点结构，后续 SEO、Polylang、多语言、图片路径、缓存规则都会变复杂。
所以这次的目标很明确：
不换主域名
不拆 /en/ 目录
不新增 cn 子域名
不升级 Cloudflare Business
尽量低成本解决中国大陆访问慢的问题
同时尽量不要明显牺牲海外访问体验
最后我选择了腾讯云 EdgeOne。
二、为什么选择 EdgeOne，而不是继续折腾 Cloudflare
一开始我考虑过几种方案。
第一种是继续使用 Cloudflare Free，然后尝试各种缓存规则、灰云、分流、智能 DNS。但这个方向的问题是：Cloudflare Free 本身在中国大陆没有真正意义上的境内加速能力。缓存命中并不等于线路就一定好。
第二种是升级 Cloudflare Pro 或 Business。Pro 对中国大陆线路帮助有限；Business 虽然可以通过 Partial CNAME Setup 做更复杂的架构，但价格对个人博客来说明显偏高。
第三种是国内 CDN + 海外 Cloudflare 双 CDN 分流。但这种方案虽然技术上可行，实际维护成本比较高，尤其是同一个 www 主域名下还要兼顾 /en/、图片、静态资源、证书、缓存、SEO 和回源 Host。
最后我选择了更直接的方式：
www.shuijingwanwq.com → 腾讯云 EdgeOne → 阿里云杭州 ECS
也就是说，用 EdgeOne 作为新的统一边缘层，替代 Cloudflare Free。
三、开通 EdgeOne：先用个人版低成本验证
进入 EdgeOne 后，第一步是添加站点。
这里填写的是根域名：
shuijingwanwq.com
而不是：
www.shuijingwanwq.com
因为 EdgeOne 先创建的是“站点”，后面再在站点下添加具体的加速域名。
套餐选择时，我没有直接上基础版，而是先选择了个人版。
当时页面显示个人版为：
1 个站点
50GB/月加速流量
300 万次/月加速请求
本次开通时还有优惠，实付金额是 9.9 元。
这个选择的目的不是一步到位，而是先用最低成本验证：
EdgeOne 是否能正常接入 WordPress
中国大陆访问是否改善
海外访问是否还能接受
缓存规则是否能复刻 Cloudflare 的效果
如果后续流量超过个人版额度，再考虑升级套餐会更稳。
四、接入模式：先选择 CNAME 接入，而不是 NS 接入
EdgeOne 添加站点后，会要求选择加速区域和接入模式。
这里我选择：
加速区域：全球可用
接入模式：CNAME 接入
为什么没有选择 NS 接入？
因为 NS 接入会影响整个域名的 DNS 解析，包括：
www
根域名
邮箱 MX
SPF
DKIM
DMARC
站长平台验证记录
其他子域名
而我这次的目标只是先迁移：
www.shuijingwanwq.com
如果同时迁移 NS，风险会变大。尤其是企业邮箱、站长平台验证记录、历史子域名等，一旦漏迁，排查会很麻烦。
所以这次我采用了更稳的方式：
Cloudflare 暂时继续作为 DNS 管理面板
www 这条记录改成 CNAME 指向 EdgeOne
Cloudflare 不再代理 www 流量
五、域名归属验证：在 Cloudflare 添加 TXT 记录
选择 CNAME 接入后，EdgeOne 要求验证域名归属。
它给出了一条 TXT 记录：
主机记录：edgeonereclaim
记录类型：TXT
记录值：reclaim-...
由于当时域名 NS 仍然在 Cloudflare，所以这条 TXT 记录需要添加到 Cloudflare DNS 里。
添加完成后回到 EdgeOne 点击验证，很快就通过了。
六、添加加速域名 www，并配置回源
站点验证通过后，需要添加具体的加速域名：
www.shuijingwanwq.com
这里的配置比较关键。
我最终配置为：
加速域名：www.shuijingwanwq.com
源站类型：IP/域名
源站地址：121.40.248.29
回源协议：HTTPS
回源端口：443
回源 Host：使用加速域名 www.shuijingwanwq.com
推荐模板：不使用模板
这里不要把源站填成：
www.shuijingwanwq.com
否则后面 DNS 切到 EdgeOne 后，可能出现回源绕圈。
正确做法是填源站服务器的公网 IP。
EdgeOne 随后会生成一个 CNAME 地址：
www.shuijingwanwq.com.eo.dnse2.com
七、在 Cloudflare 中把 www 从 A 记录改成 CNAME
迁移前，Cloudflare 里的 www 记录是：
www.shuijingwanwq.com
类型：A
内容：121.40.248.29
代理状态：已代理
也就是还在走 Cloudflare 橙云代理。
Cloudflare 里不能直接把 A 记录改成 CNAME，所以我先删除旧的 www A 记录，再新增一条 CNAME：
类型：CNAME
名称：www
目标：www.shuijingwanwq.com.eo.dnse2.com
代理状态：仅 DNS
TTL：自动
这一步完成后，www.shuijingwanwq.com 就不再走 Cloudflare 代理，而是通过 DNS 直接指向 EdgeOne。
回到 EdgeOne 后，可以看到 www 域名状态逐步变成已生效。
八、配置 EdgeOne 边缘 HTTPS 证书
源站 ECS 上已经有 SSL 证书，但这并不代表 EdgeOne 边缘节点也有证书。
完整链路是：
用户浏览器
↓ HTTPS
EdgeOne 边缘节点
↓ HTTPS 回源
阿里云 ECS / Nginx / WordPress
所以这里需要配置的是：
用户浏览器 → EdgeOne
这一段的边缘 HTTPS 证书。
我选择了 EdgeOne 的免费证书，并使用自动验证。
证书申请完成后，HTTPS 状态变成已部署。
这一步完成后，访问：
https://www.shuijingwanwq.com/
已经可以正常打开，没有证书警告。
九、前台、英文站、文章页、后台验证
EdgeOne 接入后，我先在浏览器隐私窗口中验证中文首页。
然后验证英文站：
https://www.shuijingwanwq.com/en/
英文站路径、样式、图片都正常。
接着验证英文文章页，图片、表格、正文排版也正常。
最后验证 WordPress 后台：
https://www.shuijingwanwq.com/wp-admin/
后台也能正常进入。
这里说明几个关键点：
WordPress 没有异常
Polylang /en/ 路径没有异常
图片资源没有异常
CSS / JS 没有异常
后台登录没有异常
HTTPS 没有异常
到这一步，EdgeOne 的基础接入已经完成。
十、迁移 Cloudflare Cache Rules 到 EdgeOne
之前使用 Cloudflare 时，我做了两类配置。
第一类是在 WordPress 后台安装 Cloudflare 插件，并点击：
Apply Recommended Cloudflare Settings for WordPress
同时开启：
Auto Purge Content On Update
第二类是在 Cloudflare 的 Cache Rules 中配置了 6 条缓存规则。
迁移到 EdgeOne 后，Cloudflare 插件已经不能再自动清理 EdgeOne 缓存，所以核心工作变成：在 EdgeOne 里重新配置缓存规则。
进入：
EdgeOne → 站点加速 → 规则引擎
十一、规则 1：WordPress 后台绕过缓存
第一条规则用于排除 WordPress 后台：
规则名称：WordPress 后台绕过缓存
匹配条件：URL path 正则匹配 ^/wp-admin/
动作：节点缓存 TTL → 不缓存
后台页面不能被 CDN 缓存，否则可能导致登录态、后台界面、管理操作异常。
十二、规则 2：WordPress 登录页绕过缓存
第二条规则用于排除登录页：
规则名称：WordPress 登录页绕过缓存
匹配条件：URL path 正则匹配 ^/wp-login\.php$
动作：节点缓存 TTL → 不缓存
登录页必须绕过缓存，因为它会设置测试 Cookie，也会涉及登录跳转、安全校验等逻辑。
十三、规则 3：WordPress REST API 绕过缓存
第三条规则用于排除 REST API：
规则名称：WordPress REST API 绕过缓存
匹配条件：URL path 正则匹配 ^/wp-json/
动作：节点缓存 TTL → 不缓存
WordPress 后台编辑器、插件、主题、部分前端功能都会使用 REST API。缓存 REST API 很容易引发异常，所以这里直接绕过缓存。
十四、规则 4：上传目录静态资源长期缓存
第四条规则用于缓存上传目录：
规则名称：静态资源长期缓存
匹配条件：URL path 正则匹配 ^/wp-content/uploads/
动作：节点缓存 TTL → 自定义时间 30 天
强制缓存：关闭
这个目录主要是图片、附件等静态资源，适合较长时间缓存。
十五、规则 5：CSS / JS 缓存优化
第五条规则用于缓存 CSS 和 JS：
规则名称：静态资源（CSS JS）缓存优化
匹配条件：
文件后缀 等于 css
OR
文件后缀 等于 js
动作：
节点缓存 TTL → 自定义时间 30 天
强制缓存：关闭
这里使用“文件后缀”而不是 URL 正则，规则更清晰。
十六、规则 6：HTML 页面缓存（SEO 安全）
这是最关键的一条规则。
最终配置为：
规则名称：HTML 页面缓存（SEO 安全）
匹配条件：
URL path 正则不匹配
^/(wp-admin/|wp-login\.php|wp-json/|feed/|xmlrpc\.php|wp-cron\.php)
动作：
节点缓存 TTL → 自定义时间 10 分钟
强制缓存：关闭
一开始我曾经考虑过给 HTML 规则添加：
HTTP 请求头 Cookie 不存在
但后来发现普通访客也可能带有 _ga 这类统计 Cookie。如果要求 Cookie 不存在，很多真实访客反而无法命中 HTML 缓存。
所以最终 HTML 规则不再判断 Cookie，而是把“已登录用户绕过缓存”单独放到最后一条规则中处理。
HTML 页面缓存 TTL 设置为 10 分钟，是比较保守的选择。即使忘记手动清缓存，首页、列表页、文章页最多也只是短时间旧内容。
十七、规则 7：WordPress 已登录用户绕过缓存
为了防止已登录用户拿到普通访客缓存页面，我新增了第 7 条规则：
规则名称：WordPress 已登录用户绕过缓存
匹配条件：
HTTP 请求头 Cookie 正则匹配 wordpress_logged_in
动作：
节点缓存 TTL → 不缓存
这条规则必须放在最下面。
因为 EdgeOne 的规则优先级是：
下方规则优先级更高
最终规则顺序如下：
01 HTML 页面缓存（SEO 安全）
02 静态资源长期缓存
03 静态资源（CSS JS）缓存优化
04 WordPress 后台绕过缓存
05 WordPress 登录页绕过缓存
06 WordPress REST API 绕过缓存
07 WordPress 已登录用户绕过缓存
这个顺序很重要。
普通 HTML 页面先匹配第 1 条；静态资源由第 2、3 条覆盖；后台、登录页、REST API、已登录用户由更靠下的规则覆盖，最终绕过缓存。
十八、部署状态一定要等到“已生效”
配置 EdgeOne 时，有一个细节很容易误判。
每次修改规则或域名配置后，EdgeOne 可能会显示：
部署中
这时立刻测试，结果可能不稳定。
之前我一度以为 HTML 缓存必须开启“强制缓存”才能命中。后来等域名和规则全部变成“已生效”后，再次测试发现：
强制缓存关闭
HTML 也可以正常 HIT
所以现在的最终结论是：
HTML 页面缓存：强制缓存关闭
TTL：10 分钟
这比强制缓存开启更稳。
十九、用 curl 验证 EdgeOne 缓存是否生效
配置完成后，我用 curl 做了几组测试。
1. 普通访客首页
curl -s -D - -o /dev/null https://www.shuijingwanwq.com/
curl -s -D - -o /dev/null https://www.shuijingwanwq.com/
结果：
eo-cache-status: HIT
说明普通 HTML 页面已经命中 EdgeOne 缓存。
2. 带统计 Cookie 的普通访客
curl -s -D - -o /dev/null -H "Cookie: _ga=test" https://www.shuijingwanwq.com/
curl -s -D - -o /dev/null -H "Cookie: _ga=test" https://www.shuijingwanwq.com/
结果：
eo-cache-status: HIT
说明 _ga 这类统计 Cookie 不影响普通访客命中 HTML 缓存。
3. 模拟已登录用户
curl -s -D - -o /dev/null -H "Cookie: wordpress_logged_in_test=1" https://www.shuijingwanwq.com/
curl -s -D - -o /dev/null -H "Cookie: wordpress_logged_in_test=1" https://www.shuijingwanwq.com/
结果：
eo-cache-status: MISS
说明已登录用户不会命中普通访客缓存。
这组结果正是我想要的：
普通访客：首页 HIT
带统计 Cookie 的普通访客：首页 HIT
已登录用户：首页 MISS
二十、关于 Cloudflare 插件和自动清缓存
迁移到 EdgeOne 后，WordPress 里的 Cloudflare 插件已经不能再负责 EdgeOne 的缓存刷新。
以前 Cloudflare 插件里的：
Auto Purge Content On Update
可以在文章更新时自动清理 Cloudflare 缓存。
但现在：
www.shuijingwanwq.com → EdgeOne
Cloudflare 已经不再代理 www 流量，所以这个自动清理功能对 EdgeOne 没有作用。
不过响应头里仍然可能看到：
cf-edge-cache: cache,platform=wordpress
这不代表请求还在走 Cloudflare，而是 WordPress 插件或历史配置留下的响应头。
当前我暂时采用保守方案：
HTML 页面 TTL 只设置 10 分钟
更新文章后必要时手动刷新 EdgeOne 缓存
后续再考虑接入 EdgeOne API 自动刷新
后续可以考虑两种方式：
方案一：寻找支持 EdgeOne 的 WordPress 缓存刷新插件
方案二：自己写一个小插件或 WPCode 代码片段，调用 EdgeOne 缓存清理 API
但这不是本次迁移的第一优先级。当前最重要的是主链路稳定，缓存规则安全。
二十一、最终结果
这次迁移完成后，当前状态是：
www.shuijingwanwq.com 已接入 EdgeOne
加速区域：全球可用
接入模式：CNAME 接入
源站：阿里云杭州 ECS
回源协议：HTTPS
HTTPS 证书：EdgeOne 免费证书
中文首页：正常
英文 /en/：正常
单篇文章：正常
WordPress 后台：正常
图片缓存：HIT
HTML 页面缓存：HIT
登录页：MISS
REST API：MISS
已登录用户：MISS
最终 EdgeOne 缓存规则为：
| 顺序 | 规则名称 | 作用 |
|---|---|---|
| 01 | HTML 页面缓存（SEO 安全） | 普通 HTML 页面缓存 10 分钟 |
| 02 | 静态资源长期缓存 | /wp-content/uploads/ 缓存 30 天 |
| 03 | 静态资源（CSS JS）缓存优化 | CSS / JS 缓存 30 天 |
| 04 | WordPress 后台绕过缓存 | /wp-admin/ 不缓存 |
| 05 | WordPress 登录页绕过缓存 | /wp-login.php 不缓存 |
| 06 | WordPress REST API 绕过缓存 | /wp-json/ 不缓存 |
| 07 | WordPress 已登录用户绕过缓存 | wordpress_logged_in Cookie 不缓存 |
二十二、这次迁移的几个经验
第一，不要一上来就做 NS 接入。
如果只是迁移 www 主站，CNAME 接入更安全，影响范围更小。
第二，EdgeOne 的规则优先级要特别注意。
它是下方规则优先级更高，所以“不缓存规则”应该放在更靠下的位置。
第三，修改规则后不要马上得出结论。
如果域名状态还在“部署中”，测试结果可能不稳定。一定要等到“已生效”后再测试。
第四，HTML 页面缓存不要一开始设置太长。
10 分钟是一个比较稳的起点，既能降低源站压力，又不会让内容更新延迟太久。
第五，普通访客也可能带 Cookie。
如果 HTML 缓存规则要求“Cookie 不存在”，会降低真实缓存命中率。更合理的做法是只针对 wordpress_logged_in 这类登录 Cookie 做绕过缓存。
第六，Cloudflare 插件迁移后不能自动清 EdgeOne 缓存。
这部分需要后续单独处理，不能误以为 Cloudflare 插件还在生效。
结语
这次从 Cloudflare Free 迁移到腾讯云 EdgeOne，并不是因为 Cloudflare 不好，而是因为我的主要访问人群仍然在中国大陆。
Cloudflare Free 对海外访问非常友好，但中国大陆线路不稳定是现实问题。对于一个已经备案、源站在阿里云杭州 ECS、中文流量占比较高、同时又有英文 /en/ 站点的 WordPress 博客来说，EdgeOne 这种国内外一体化边缘加速平台，确实是一个更适合当前阶段的选择。
这次迁移后，我没有改 WordPress 结构，也没有拆英文站，更没有新增 cn 子域名。
最终实现的是：
同一个 www 主域名
同一个 /en/ 英文目录
统一 EdgeOne 加速
普通访客 HTML HIT
静态资源 HIT
后台、登录页、REST API、已登录用户安全绕过缓存
从目前结果看，这次迁移是成功的。
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
发表回复