没有不值得去解决的问题,也没有不值得去学习的技术!

将 media、en、admin 拆出 EdgeOne 后,我重新估算了网站每月的实际 CDN 成本

图5:media、en 和 admin 尚未拆分时,EdgeOne 单日产生了 6.56GB 流量和 18.32 万次请求

作者:

WordPress CDN 与全球加速实战

图16:浏览器访问正常,网站全球访问成功

(1) 从阿里云 DNS 到 Cloudflare 全球加速的完整迁移实战记录

这一套规则遵循 Cloudflare + WordPress 标准 CDN 架构:

(2) Cloudflare SSL/TLS 与 Cache Rules 配置实战

图12:评论实时生效

(3) WordPress + Cloudflare 推荐配置与 Cache Rules 实战优化(SSL / API / 缓存闭环完整记录)

CDN上线后的boce数据

(4) CDN 上线前后性能对比实测:WordPress 缓存误判修正与真实加速效果验证

【图9:boce 测试 cn-test,灰云直连阿里云 ECS,平均响应 0.478s】

(5) Cloudflare 免费版适合中国大陆 WordPress 主站吗?从缓存 HIT 到灰云直连阿里云 ECS 的实测复盘

【图1:腾讯云 EdgeOne 产品页,选择“立即使用”】

(6) 从 Cloudflare Free 迁移到腾讯云 EdgeOne:一次 WordPress 主站国内外加速实战

【图2:EdgeOne 上线后 boce 第二次测试,平均响应 0.354s,不可访问 2 个】

(7) Cloudflare Free 迁移到 EdgeOne 后到底快了多少?WordPress CDN 三阶段 boce 与 WebPageTest 实测对比

[图2,EdgeOne 昨日 L7 访问流量,显示 6.56 GB]

(8) EdgeOne 流量成本排查:将 WordPress uploads 静态资源迁移到 Cloudflare media 子域名

【图3,EdgeOne 301 请求的 URL Path 排行,集中在 /wp-content/uploads/ 图片路径】

(9) WordPress 图片迁移到 media 子域名后,EdgeOne 仍然出现大量 301 的排查与处理记录

图4:Cloudflare Edge TTL 配置、Cloudflare Browser TTL 配置

(10) WordPress Media CDN 迁移后的 Cloudflare Cache Rules 调整记录

[图4:EdgeOne 按 URL path 开始于 /en/ 筛选后的流量截图]

(11) EdgeOne 流量成本控制决策:是否将英文站从 /en/ 迁移到 en.shuijingwanwq.com

[图3:执行核心升级时返回 524 No Reason Phrase]

(12) WordPress 核心升级反复 524 与“另一更新正在进行”的排查记录

【图 10:新证书 SAN 信息截图,显示已经包含 en.shuijingwanwq.com】

(13) OneinStack 现有 Nginx 虚拟主机追加域名并重签 SSL 证书的一次实操记录

【图 8,curl 验证 www 与 en 的 html lang、canonical 均正确】

(14) WordPress Polylang 英文站从 /en/ 迁移到 en 子域名:W3TC 与 Redis 缓存问题排查

【图 14,最终回归验证:en 首页和文章页 Cloudflare HIT,lang 与 canonical 正确】

(15) 将 Polylang 英文子域名接入 Cloudflare:HTML 缓存、登录绕过与后台入口收敛

【图1:浏览器开发者工具中,旧 /en/ 首页返回 301,随后成功加载 en 子域名英文首页】

(16) WordPress 英文站从 /en/ 迁移到 en 子域名:兼容数千条 Nginx 旧规则并避免二次 301

升级请求经过 EdgeOne,长时间运行的后台请求最终出现超时,数据库中还一度留下了 core_updater.lock

(17) 将 WordPress 后台迁移到独立 admin 子域名:绕过 EdgeOne,解决核心升级 524 超时

【图 1,后台发布新文章后,中文首页仍未显示新文章】

(18) WordPress 多域名架构暂停复盘:en、admin、W3TC 与多 CDN 的可维护性重新评估

图5:media、en 和 admin 尚未拆分时,EdgeOne 单日产生了 6.56GB 流量和 18.32 万次请求

(19) 将 media、en、admin 拆出 EdgeOne 后,我重新估算了网站每月的实际 CDN 成本

此前,我的 EdgeOne 个人版同时承载了多个域名,包括中文主站、英文站、媒体资源域名和 WordPress 后台域名。

EdgeOne 个人版每月包含 50GB 安全加速流量和 300 万次安全加速请求。套餐启用几天后,我根据当时的流量消耗速度进行估算,发现 50GB 流量明显无法支撑完整的一个月,后续购买加量包几乎不可避免。

因此,我没有等到套餐流量彻底耗尽后才开始处理,而是在确认个人版额度不足后,陆续完成了三个域名的拆分:

  • media.shuijingwanwq.com 迁出 EdgeOne;
  • en.shuijingwanwq.com 迁出 EdgeOne;
  • admin.shuijingwanwq.com 迁出 EdgeOne。

现在,EdgeOne 中只保留中文主站 www.shuijingwanwq.com

完成拆分后,我又购买了一个 100GB 安全加速流量包和一个 1000 万次安全加速请求包。本文将根据迁移前后的实际数据,估算当前计费周期、下一个完整计费周期,以及没有拆分三个域名时的月度实际成本。

本文只考虑个人版套餐与加量包,不考虑后付费方案。

一、当前使用的套餐与加量包

我目前使用的是 EdgeOne 个人版套餐:

  • 套餐价格:9.9 元;
  • 每月安全加速流量:50GB;
  • 每月安全加速请求:300 万次;
  • 当前有效期:2026 年 7 月 6 日至 2026 年 8 月 6 日。

截至 2026 年 7 月 17 日,个人版中的 50GB 流量已经全部使用完毕。

安全加速请求已经使用:

Plaintext
161.27 万次 / 300 万次
图1:EdgeOne 个人版的 50GB 流量已经用完,安全加速请求已使用 161.27 万次
图1:EdgeOne 个人版的 50GB 流量已经用完,安全加速请求已使用 161.27 万次

我另外购买了两个有效期为 12 个月的加量包:

加量包规格价格
安全加速流量包100GB19.95 元
安全加速请求包1000 万次34 元

截至截图时间,100GB 流量包已经使用了 2.99GB,请求包暂时还没有开始扣减。

这是因为个人版中的 300 万次请求尚未耗尽。只有套餐内请求额度使用完毕后,才会继续消耗请求加量包。

图2:已经生效的 100GB 安全加速流量包和 1000 万次安全加速请求包
图2:已经生效的 100GB 安全加速流量包和 1000 万次安全加速请求包
图3:个人版、100GB 流量包和 1000 万次请求包的实际购买价格
图3:个人版、100GB 流量包和 1000 万次请求包的实际购买价格

二、本文如何计算“实际成本”

加量包的有效期为 12 个月,未使用额度可以继续跨月使用。

因此,不能把购买一个加量包时支付的全部金额,都算作购买当月的实际成本。例如,100GB 流量包虽然价格为 19.95 元,但如果某个月只使用其中 36GB,就不应将 19.95 元全部计入这个月。

本文按照实际消耗的加量包额度分摊成本。

流量包单位成本

Plaintext
19.95 元 ÷ 100GB
= 0.1995 元/GB

请求包单位成本

Plaintext
34 元 ÷ 1000 万次
= 0.034 元/万次

因此,每个月的实际成本按照下面的方式计算:

Plaintext
月度实际成本
= 个人版 9.9 元
+ 当月使用的流量包额度成本
+ 当月使用的请求包额度成本

这种计算方式不受加量包具体在哪一天购买影响,也不会因为某个月集中购买多个加量包,而夸大当月的真实资源成本。

三、三个域名拆分后的流量水平

在 media、en 和 admin 都迁出 EdgeOne 后,最近 6 小时的数据为:

指标最近6小时
L7 访问流量693.07MB
EdgeOne 响应流量667.02MB
客户端请求流量26.05MB
L7 请求数3.64 万次
图4:完成三个域名拆分后,EdgeOne 最近6小时的流量和请求情况
图4:完成三个域名拆分后,EdgeOne 最近6小时的流量和请求情况

将最近 6 小时的数据换算为一天:

Plaintext
每日流量:
693.07MB × 4
≈ 2.77GB

每日请求:
3.64 万次 × 4
≈ 14.56 万次

也就是说,只保留 www 域名后,EdgeOne 当前大致每天产生:

  • 2.77GB 流量;
  • 14.56 万次请求。

这组数据将作为拆分完成后的月度成本估算依据。

四、当前计费周期预计会消耗多少资源

当前计费周期为:

Plaintext
2026年7月6日—2026年8月6日

从 7 月 17 日截图时间到 8 月 6 日,大约还剩 19.48 天。

需要注意的是,当前周期属于过渡周期:

  • 周期前半段,media、en 和 admin 仍有部分流量经过 EdgeOne;
  • 周期后半段,只保留 www 域名;
  • 因此,当前周期的实际成本会高于拆分完成后的稳定月度成本。

1. 流量消耗估算

当前流量包已经使用:

Plaintext
2.99GB

剩余 19.48 天预计还会产生:

Plaintext
2.77GB × 19.48天
≈ 54GB

到 8 月 6 日时,预计累计使用流量包:

Plaintext
2.99GB + 54GB
≈ 56.99GB

对应的流量包实际成本为:

Plaintext
56.99GB × 0.1995元/GB
≈ 11.37元

2. 请求消耗估算

当前已经使用:

Plaintext
161.27万次

剩余时间预计还会产生:

Plaintext
14.56万次 × 19.48天
≈ 283.63万次

本周期总请求数预计为:

Plaintext
161.27万次 + 283.63万次
≈ 444.90万次

个人版包含 300 万次,因此预计需要使用请求包:

Plaintext
444.90万次 - 300万次
≈ 144.90万次

对应的请求包实际成本为:

Plaintext
144.90万次 × 0.034元/万次
≈ 4.93元

五、当前周期的预计实际成本

当前周期的实际成本由三部分组成:

项目预计实际成本
EdgeOne 个人版9.90 元
流量包实际消耗约11.37 元
请求包实际消耗约4.93 元
合计约26.20 元

因此,2026 年 7 月 6 日至 8 月 6 日这个过渡周期的预计实际成本为:

约26.2元

这个数字比后续稳定月份略高,主要是因为当前周期前几天,media、en 和 admin 仍然在消耗 EdgeOne 流量。

六、下一个完整周期的实际成本

下一个计费周期为:

Plaintext
2026年8月6日—2026年9月6日

这个周期共有 31 天,并且从周期开始时,EdgeOne 中就只剩下 www 域名,因此更能反映拆分完成后的长期成本。

1. 月度流量成本

按照每天约 2.77GB 计算:

Plaintext
2.77GB × 31天
≈ 85.94GB

个人版每月包含 50GB,因此需要使用流量包:

Plaintext
85.94GB - 50GB
≈ 35.94GB

对应的流量包实际成本:

Plaintext
35.94GB × 0.1995元/GB
≈ 7.17元

2. 月度请求成本

按照每天约 14.56 万次计算:

Plaintext
14.56万次 × 31天
≈ 451.36万次

扣除个人版包含的 300 万次后,需要使用请求包:

Plaintext
451.36万次 - 300万次
≈ 151.36万次

对应的请求包实际成本:

Plaintext
151.36万次 × 0.034元/万次
≈ 5.15元

3. 下个周期总成本

项目预计实际成本
EdgeOne 个人版9.90 元
流量包实际消耗约7.17 元
请求包实际消耗约5.15 元
合计约22.22 元

因此,在只保留 www 域名后,下一个完整计费周期的预计实际成本为:

约22.2元

这也是目前比较有参考价值的稳定月度成本。

七、如果没有迁出三个域名,每月会花多少钱

为了判断这次拆分的实际价值,我又使用拆分前的完整单日数据进行了估算。

2026 年 7 月 7 日,EdgeOne 的数据为:

指标拆分前单日用量
L7 访问流量6.56GB
L7 请求数18.32 万次
图5:media、en 和 admin 尚未拆分时,EdgeOne 单日产生了 6.56GB 流量和 18.32 万次请求
图5:media、en 和 admin 尚未拆分时,EdgeOne 单日产生了 6.56GB 流量和 18.32 万次请求

按照 31 天计算,一个月预计产生:

Plaintext
流量:
6.56GB × 31天
≈ 203.36GB

请求:
18.32万次 × 31天
≈ 567.92万次

1. 未拆分时的流量成本

个人版包含 50GB,需要使用流量包:

Plaintext
203.36GB - 50GB
≈ 153.36GB

流量包实际成本为:

Plaintext
153.36GB × 0.1995元/GB
≈ 30.60元

2. 未拆分时的请求成本

个人版包含 300 万次,需要使用请求包:

Plaintext
567.92万次 - 300万次
≈ 267.92万次

请求包实际成本为:

Plaintext
267.92万次 × 0.034元/万次
≈ 9.11元

3. 未拆分时的月度总成本

项目预计实际成本
EdgeOne 个人版9.90 元
流量包实际消耗约30.60 元
请求包实际消耗约9.11 元
合计约49.61 元

因此,如果 media、en 和 admin 都没有迁出 EdgeOne,一个完整月份的实际成本大约为:

约49.6元

八、拆分前后的实际成本对比

场景月度实际成本
三个域名全部保留在 EdgeOne约49.61 元
只保留 www 域名约22.22 元
每月节省约27.39 元

成本降幅约为:

Plaintext
27.39元 ÷ 49.61元
≈ 55.2%

按照一年计算,预计可以节省:

Plaintext
27.39元 × 12个月
≈ 328.68元

也就是说,完成三个域名拆分后,EdgeOne 的长期实际成本预计降低了一半以上。

九、流量和请求分别减少了多少

除了费用变化之外,还可以直接比较迁移前后的资源消耗。

每月流量

迁移前预计:

Plaintext
203.36GB

迁移后预计:

Plaintext
85.94GB

每月减少:

Plaintext
203.36GB - 85.94GB
≈ 117.42GB

流量降幅约为:

Plaintext
117.42GB ÷ 203.36GB
≈ 57.7%

每月请求

迁移前预计:

Plaintext
567.92万次

迁移后预计:

Plaintext
451.36万次

每月减少:

Plaintext
567.92万次 - 451.36万次
≈ 116.56万次

请求降幅约为:

Plaintext
116.56万次 ÷ 567.92万次
≈ 20.5%

可以看出,这次拆分对流量的影响远大于对请求数的影响。

这也比较符合实际情况:

  • media 主要承载图片等静态资源,是流量消耗的重要来源;
  • en 承担英文站页面访问;
  • admin 的流量占比相对较小,但拆出后可以避免后台操作继续消耗 www 的 EdgeOne 资源。

十、为什么仍然选择加量包

虽然个人版每月只有 50GB 流量和 300 万次请求,但加量包有几个比较明显的优势:

  • 有效期为 12 个月;
  • 未使用额度可以继续跨月使用;
  • 流量包和请求包可以根据实际消耗逐步使用;
  • 不需要为了某个月的短期波动,立即升级到价格更高的套餐;
  • 实际成本可以按照使用比例进行分摊。

以拆分后的数据计算:

  • 每月大约消耗 35.94GB 流量包;
  • 每月大约消耗 151.36 万次请求包;
  • 100GB 流量包大约可以覆盖 2.78 个月的额外流量;
  • 1000 万次请求包大约可以覆盖 6.61 个月的额外请求。

因此,对于当前的网站流量规模,继续使用个人版,再配合流量包和请求包,比直接升级更符合我的实际需求。

十一、最终结论

当前计费周期属于域名拆分过程中的过渡周期,预计实际成本约为:

26.2元

从下一个完整周期开始,只保留 www 域名后的月度实际成本预计为:

22.2元左右

如果没有将 media、en 和 admin 迁出 EdgeOne,月度实际成本预计为:

49.6元左右

完成拆分后,每月预计可以节省约:

27.4元

整体成本降幅约为:

55%

这次调整并不是等到 50GB 套餐流量彻底耗尽后才开始进行,而是在套餐运行几天后,根据消耗速度提前判断个人版无法支撑整个月,于是开始逐步拆分域名。

从最终数据来看,这个判断是正确的。

媒体资源、英文站和 WordPress 后台拆分后,EdgeOne 可以更集中地为中文主站提供加速。对我当前的网站规模来说,继续使用个人版,并通过有效期一年的流量包和请求包补充额度,是现阶段更合适的成本控制方案。

WordPress 多域名架构暂停复盘:en、admin、W3TC 与多 CDN 的可维护性重新评估

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

评论

发表回复

您的邮箱地址不会被公开。 必填项已用 * 标注

这个站点使用 Akismet 来减少垃圾评论。了解你的评论数据如何被处理