![[图4：EdgeOne 按 URL path 开始于 /en/ 筛选后的流量截图]](https://media.shuijingwanwq.com/2026/07/4-24.png)
![[图2，EdgeOne 昨日 L7 访问流量，显示 6.56 GB]](https://media.shuijingwanwq.com/2026/07/2-20-1024x480.png)
最近几天，我一直在排查 WordPress 主站接入腾讯云 EdgeOne 之后的流量消耗问题。
前一篇文章中，我已经完成了一次比较关键的调整：将 WordPress 的 /wp-content/uploads/ 媒体库资源迁移到 media.shuijingwanwq.com，并让这个 media 子域名走 Cloudflare，而不是继续走 EdgeOne。
前置文章地址：
这篇文章不是继续做具体操作，而是先整理一个新的成本控制决策方案：是否有必要将英文站从 www.shuijingwanwq.com/en/ 迁移到 en.shuijingwanwq.com/，并让英文子域名走 Cloudflare，从而进一步减少 EdgeOne 的流量消耗。
![[图1：前置文章的 EdgeOne 流量成本排查]](https://media.shuijingwanwq.com/2026/07/1-26.png)
一、当前架构前提：uploads 已经拆到 Cloudflare，但 www 仍然承接大量请求
这里需要先把当前架构说清楚。
前一篇文章完成的并不是“把所有静态资源都迁移到 Cloudflare”，而是仅将 WordPress uploads 媒体库资源迁移到了 media 子域名。
更准确的当前结构应该是：
www.shuijingwanwq.com
↓
EdgeOne
↓
WordPress 主站请求
包括：
- 首页
- 文章页
- 分类页
- 标签页
- /en/ 英文路径页面
- sitemap
- feed
- WordPress 主题、插件、wp-includes 下的 CSS / JS
- 其他非 /wp-content/uploads/ 的资源与动态请求
media.shuijingwanwq.com
↓
Cloudflare
↓
WordPress uploads 媒体库资源
仅包括：
- /wp-content/uploads/ 下的图片
- /wp-content/uploads/ 下的附件
- ZIP / PDF / PNG / JPG / WebP 等上传文件
也就是说，media.shuijingwanwq.com 并不是承接整个 WordPress 站点的所有静态资源，而只是承接 WordPress 媒体库 uploads 目录。
这个区别很重要。
因为 uploads 分流后，EdgeOne 中确实已经基本看不到 /wp-content/uploads/ 相关的大量图片和附件流量了。但是，www.shuijingwanwq.com 上仍然有大量页面 HTML、主题 CSS、插件 JS、wp-includes 资源、sitemap、feed、分类页、标签页、英文页等请求。
所以当前问题已经从：
如何把 /wp-content/uploads/ 图片和附件从 EdgeOne 拆出去
变成了：
在 uploads 已经拆出去之后，是否还需要继续把 /en/ 英文页面流量从 EdgeOne 拆出去
二、当前问题：EdgeOne 今日流量趋势仍然偏高
今天早上，我继续查看 EdgeOne 指标分析。
截止早上 9 点左右，今日 L7 访问流量大约是：
1.4 GB
按照这个速度粗略估算：
1.4 GB ÷ 9 小时 × 24 小时 ≈ 3.7 GB/天
如果按照 30 天计算：
3.7 GB × 30 ≈ 111 GB/月
而我希望尽量将 EdgeOne 月流量控制在：
50 GB/月以内
折算到每天，大约只能消耗：
50 GB ÷ 30 ≈ 1.67 GB/天
也就是说，当前趋势大约是目标值的 2 倍以上。
这说明，虽然 uploads 分流到 Cloudflare 已经有效降低了一部分 EdgeOne 流量，但如果继续保持当前结构，EdgeOne 的 50 GB 月度流量目标仍然比较吃紧。
![[图2：EdgeOne 今日 L7 访问流量截图，显示约 1.4 GB]](https://media.shuijingwanwq.com/2026/07/2-25-1024x451.png)
三、页面缓存不是当前最主要矛盾
一开始，我怀疑是不是 WordPress 页面 HTML 没有被 EdgeOne 正常缓存。
因为在 EdgeOne 的缓存状态统计里，MISS 占比明显偏高。
但后来通过 Firefox 隐私窗口和 curl 的 GET 请求测试，确认页面缓存其实是生效的。
测试文章页：
https://www.shuijingwanwq.com/2026/05/29/14108/
第 1 次：eo-cache-status: MISS
第 2 次：eo-cache-status: HIT
第 3 次：eo-cache-status: HIT
测试英文首页：
https://www.shuijingwanwq.com/en/
第 1 次：eo-cache-status: MISS
第 2 次：eo-cache-status: HIT
第 3 次：eo-cache-status: HIT
这说明 EdgeOne 对 WordPress 页面 HTML 是可以缓存的。
后台看到 MISS 占比高，主要原因更可能是：
1. 历史文章、分类页、标签页很多，URL 非常分散；
2. Bot 会抓取大量不同页面，每个 URL 第一次访问都是 MISS；
3. EdgeOne 是边缘节点缓存，不同节点之间不是完全共享同一份缓存；
4. 页面 HTML 缓存 TTL 之前只有 10 分钟，过期后再次访问仍然会重新 MISS；
5. uploads 图片流量已经拆走后，EdgeOne 剩下的主要就是页面和非 uploads 资源，MISS 占比自然会更显眼。
所以，适当延长 HTML 页面缓存 TTL 是有意义的，比如从 10 分钟调整到 1 小时。但这类优化主要减少的是：
EdgeOne → 源站
也就是减少回源、降低源站压力、提高页面响应速度。
它不一定能明显减少：
访问者 / Bot → EdgeOne
这一段的 L7 访问流量。
因为只要访问者或爬虫从 EdgeOne 下载了页面，EdgeOne 仍然会产生响应流量。页面是 HIT 还是 MISS，主要影响的是是否回源，而不是 EdgeOne 是否产生下行流量。
因此，如果目标是控制 EdgeOne 套餐流量，单纯提高缓存命中率并不能完全解决问题。
四、Bot 流量确实存在，但单独处理某一个 UA 意义有限
从 User-Agent 排行看，Bot 流量确实不低。
其中比较明显的是：
meta-externalagent/1.1
256.99 MB，占 18.4%
另外还有：
curl/8.7.1
bingbot
SemrushBot
Baiduspider
Amazonbot
DotBot
这些 User-Agent 里，有些是搜索引擎爬虫，有些是 SEO 工具爬虫，有些可能是 AI 或采集类爬虫。
![[图3：EdgeOne User-Agent 排行截图]](https://media.shuijingwanwq.com/2026/07/3-24.png)
不过，如果只限制 curl/8.7.1，意义并不大。它今天上午占比大约 5% 左右，即使完全拦截，也很难把预计 3.7 GB/天降到目标值 1.67 GB/天以内。
Bot 处理应该是后续的长期策略，而不是当前唯一方案。
更合理的 Bot 策略应该是分级处理：
保留：
Googlebot、Bingbot、Baiduspider
观察：
meta-externalagent
限制或拦截：
SemrushBot、DotBot、Amazonbot、GPTBot、ClaudeBot、curl、python-requests、Go-http-client、AhrefsBot、MJ12bot、PetalBot、Bytespider
但这类规则涉及搜索收录、社交预览、误伤风险，需要慢慢观察，不适合在还没有形成完整策略时一次性大规模封禁。
所以我继续寻找更可控的流量拆分方案。
五、关键发现：/en/ 英文路径占了约三分之一 EdgeOne 流量
为了判断英文站是否值得单独迁移，我在 EdgeOne 指标分析中增加了筛选条件：
URL path / 开始于 /en/
筛选后可以看到，今天 0 点到 9 点左右，/en/ 相关流量为：
486.14 MB
而今日总流量大约是：
1.4 GB
所以 /en/ 英文路径占比大约为：
486 MB ÷ 1434 MB ≈ 33.9%
也就是说，当前英文路径大约消耗了 EdgeOne 三分之一的流量。
![[图4：EdgeOne 按 URL path 开始于 /en/ 筛选后的流量截图]](https://media.shuijingwanwq.com/2026/07/4-24-1024x664.png)
/en/ 筛选后的流量截图]这个比例已经不低了。
如果将：
https://www.shuijingwanwq.com/en/*
迁移到：
https://en.shuijingwanwq.com/*
并且让 en.shuijingwanwq.com 走 Cloudflare，而不是 EdgeOne，那么理论上可以让 EdgeOne 流量下降约三分之一。
按照当前趋势估算：
当前预计：3.7 GB/天
去掉 /en/ 约 34%：3.7 × (1 - 0.34) ≈ 2.44 GB/天
折算到月流量：
2.44 GB × 30 ≈ 73 GB/月
这仍然没有达到 50 GB/月以内，但已经比原来的 111 GB/月明显下降。
所以英文站迁移不是最终答案，但它是一个比较明显、可控、收益较大的阶段性方案。
六、为什么英文站适合拆到子域名
我当前的主站主要使用 EdgeOne，是为了兼顾中国大陆访问体验。
但英文站的目标用户更多是海外读者。对这部分访问来说，继续走 EdgeOne 并不是唯一选择。
如果将英文站迁移到：
en.shuijingwanwq.com
并让它走 Cloudflare，那么结构会变成：
www.shuijingwanwq.com
↓
EdgeOne
↓
中文主站 + 非 uploads 资源 + 仍保留在 www 下的请求
media.shuijingwanwq.com
↓
Cloudflare
↓
WordPress uploads 媒体库资源
en.shuijingwanwq.com
↓
Cloudflare
↓
英文站页面
这样做的好处是：
1. EdgeOne 继续服务中文主站，优先保障中国大陆访问体验；
2. 英文站主要面向海外用户，交给 Cloudflare 更合理；
3. EdgeOne 的访问流量可以直接减少一部分；
4. 中文站、英文站、媒体资源的流量边界更清晰；
5. 后续更容易分别观察各自的缓存、Bot、流量成本。
当然，代价也存在：
1. 中国大陆用户访问英文站可能会慢一些；
2. 需要处理 /en/* 到 en 子域名的 301；
3. 需要确认 WordPress / Polylang 多语言配置是否支持这种结构；
4. 需要处理 sitemap、canonical、hreflang、站内链接；
5. 需要避免大量旧标签规则和新迁移规则发生冲突。
所以这不是一个简单的 DNS 调整，而是一次完整的 URL 架构迁移。
七、现有 301 规则的复杂点
目前站点 Nginx 中已经有大量 301 规则，大约 8000 条左右。
这些规则主要用于：
1. 中文标签 slug 合并；
2. 英文路径下中文标签 slug 翻译为英文 slug；
3. 部分旧专题路径合并到新专题路径。
当前配置类似这样：
map $uri $new_tag_uri {
default "";
~^/tag/权限/?$ "/tag/permission/";
~^/en/tag/权限/?$ "/en/tag/permission/";
~^/tag/菜单/?$ "/tag/menu/";
~^/en/tag/菜单/?$ "/en/tag/menu/";
~^/tag/30-天试用/?$ "/tag/30-day-trial/";
~^/en/tag/30-天试用/?$ "/en/tag/30-day-trial-en/";
~^/tag/在线商店/?$ "/tag/online-store/";
~^/en/tag/在线商店/?$ "/en/tag/online-store-en/";
~^/series/15-year-backend-dev-survival-notes-in-ai-era/?$ "/series/ai-era-developer-monetization-system/";
~^/en/series/15-year-backend-dev-survival-notes-in-ai-era-en/?$ "/en/series/ai-era-developer-monetization-system-en/";
}
然后在 server 中执行：
if ($new_tag_uri != "") {
return 301 $new_tag_uri;
}
如果直接新增一条通用规则：
/en/* → https://en.shuijingwanwq.com/*
就可能导致两次 301。
例如：
https://www.shuijingwanwq.com/en/tag/30-天试用/
→ https://www.shuijingwanwq.com/en/tag/30-day-trial-en/
→ https://en.shuijingwanwq.com/tag/30-day-trial-en/
这个结果虽然最终地址是对的，但中间多了一次 301，不够理想。
更好的结果应该是一次跳转到最终地址：
https://www.shuijingwanwq.com/en/tag/30-天试用/
→ https://en.shuijingwanwq.com/tag/30-day-trial-en/
所以迁移英文站时，不能简单粗暴地把 /en/* 通用跳转规则放到最前面。
八、推荐的 301 处理逻辑
更稳的做法是保留现有 8000 条 map 规则不动，然后在最终跳转前增加一层“目标地址转换”。
整体逻辑是：
第一步：
旧标签 / 旧专题规则先把旧 URL 映射为标准路径。
第二步：
如果标准路径以 /en/ 开头，则最终跳转到 en.shuijingwanwq.com，并去掉 /en/ 前缀。
第三步：
如果标准路径不是 /en/ 开头，则继续跳转到 www.shuijingwanwq.com。
预期结果应该是：
https://www.shuijingwanwq.com/en/tag/30-天试用/
→ https://en.shuijingwanwq.com/tag/30-day-trial-en/
https://www.shuijingwanwq.com/en/tag/30-day-trial-en/
→ https://en.shuijingwanwq.com/tag/30-day-trial-en/
https://www.shuijingwanwq.com/tag/30-天试用/
→ https://www.shuijingwanwq.com/tag/30-day-trial/
https://www.shuijingwanwq.com/en/2026/07/08/19083/
→ https://en.shuijingwanwq.com/2026/07/08/19083/
这种方式的好处是：
1. 不用手工修改 8000 条旧规则；
2. 英文旧标签可以一次跳转到最终英文子域名；
3. 中文标签合并逻辑仍然保留在 www 主域名；
4. 普通 /en/ 文章页、分类页、标签页可以统一迁移；
5. 可以避免大部分两次 301 的问题。
九、迁移前需要确认的事项
正式执行前，至少要确认以下事项。
1. en.shuijingwanwq.com 必须不走 EdgeOne
这是整个方案能否降低 EdgeOne 流量的前提。
如果 en.shuijingwanwq.com 仍然走 EdgeOne，那么这次迁移只是换了 URL 结构，对 EdgeOne 流量成本没有实际帮助。
目标应该是：
en.shuijingwanwq.com
↓
Cloudflare
↓
英文站
2. WordPress / Polylang 是否支持英文子域名
需要确认英文站切到子域名后，以下内容是否正常：
英文首页
英文文章页
英文分类页
英文标签页
英文专题页
语言切换链接
canonical
hreflang
sitemap
站内链接
如果 Polylang 配置不正确，可能会出现站内链接仍然指向 /en/，或者 canonical/hreflang 混乱的问题。
3. 301 必须尽量一次跳转到最终地址
尤其是这种旧英文标签路径：
/en/tag/30-天试用/
理想结果应该是：
https://en.shuijingwanwq.com/tag/30-day-trial-en/
而不是先跳到：
https://www.shuijingwanwq.com/en/tag/30-day-trial-en/
再跳到英文子域名。
4. 搜索引擎需要重新提交英文站
迁移后，en.shuijingwanwq.com 应该在 Google Search Console 和 Bing Webmaster Tools 中作为新站点添加。
同时需要提交新的英文 sitemap，并观察索引迁移情况。
5. 需要接受中国大陆访问英文站变慢
这个方案的核心取舍是：
中文主站继续走 EdgeOne，保障中国大陆访问体验；
英文站走 Cloudflare，降低 EdgeOne 流量成本，并更适合海外读者。
如果中国大陆用户访问英文站变慢一些，这是可以接受的副作用。
十、后续执行顺序建议
这次先不直接执行，后续有时间时可以按下面顺序推进。
第一步：先准备 en.shuijingwanwq.com
先添加英文子域名 DNS，并确认它走 Cloudflare。
不要一开始就切换正式流量，可以先让子域名能够访问英文站内容。
第二步：确认 WordPress 多语言配置
检查 Polylang 或当前多语言插件是否支持：
中文：https://www.shuijingwanwq.com/
英文：https://en.shuijingwanwq.com/
重点确认语言切换、canonical、hreflang 和 sitemap 是否正确。
第三步：调整 Nginx 301 规则
在现有 map $uri $new_tag_uri 的基础上增加最终跳转地址转换。
目标是让旧路径纠正规则优先，英文子域名迁移作为兜底。
第四步：本地测试关键 URL
至少测试下面这些路径：
https://www.shuijingwanwq.com/en/
https://www.shuijingwanwq.com/en/2026/07/08/19083/
https://www.shuijingwanwq.com/en/tag/30-天试用/
https://www.shuijingwanwq.com/en/tag/30-day-trial-en/
https://www.shuijingwanwq.com/tag/30-天试用/
https://www.shuijingwanwq.com/en/category/...
https://www.shuijingwanwq.com/en/post-sitemap.xml
重点检查：
是否 301
是否只跳一次
Location 是否为最终地址
是否保留查询参数
是否出现循环跳转
第五步：上线后观察 EdgeOne 流量
迁移完成后，回到 EdgeOne 指标分析，继续筛选：
URL path / 开始于 /en/
理想结果是，www.shuijingwanwq.com 下的 /en/ 流量明显下降。
同时观察 EdgeOne 总流量是否从当前预计的：
约 3.7 GB/天
下降到：
约 2.4 GB/天左右
实际结果可能会受到 Bot、缓存、搜索引擎重新抓取等因素影响，所以需要观察几天，而不是只看迁移当天。
十一、当前决策结论
从当前数据看，/en/ 英文路径占 EdgeOne 今日流量约三分之一。
这说明，把英文站从：
https://www.shuijingwanwq.com/en/
迁移到：
https://en.shuijingwanwq.com/
并让英文子域名走 Cloudflare，是一个值得认真执行的成本优化方案。
但它不是最终解决方案。
按照当前估算，即使把 /en/ 从 EdgeOne 拆出去，EdgeOne 月流量可能仍然在 70 GB 左右，距离 50 GB/月以内还有差距。后续仍然需要继续处理：
低价值 Bot
Meta/Facebook 爬虫流量
页面体积
主题和插件前端资源
HTML 缓存 TTL
异常路径请求
所以这次迁移更像是第一阶段的大流量拆分：
第一阶段：
uploads 媒体库资源 → media.shuijingwanwq.com → Cloudflare
第二阶段：
英文站页面 → en.shuijingwanwq.com → Cloudflare
第三阶段：
中文主站继续走 EdgeOne，并进一步优化 Bot、缓存和页面体积
当前结论是：
可以迁移，但不要仓促迁移。
先形成方案，确认 Polylang、Cloudflare、Nginx 301、sitemap、canonical、hreflang 都没有问题后，再分步骤执行。
这次调整的核心目标不是单纯改变 URL 结构，而是重新划分流量边界：
中文主站优先保障中国大陆访问体验；
英文站交给更适合海外访问的 Cloudflare；
uploads 媒体库继续由 media 子域名承接；
EdgeOne 流量尽量控制在可接受范围内。
从长期看，这种架构比所有内容都压在 www.shuijingwanwq.com + EdgeOne 上更清晰，也更容易继续做成本控制。
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
发表回复