![[图4：EdgeOne 按 URL path 开始于 /en/ 筛选后的流量截图]](https://media.shuijingwanwq.com/2026/07/4-24.png)
![[Figure 1: Tencent Cloud EdgeOne product page, selecting “Start Now”]](https://media.shuijingwanwq.com/2026/07/1-13.png)
![[图2，EdgeOne 昨日 L7 访问流量，显示 6.56 GB]](https://media.shuijingwanwq.com/2026/07/2-20-1024x480.png)
Over the past few days, I have been investigating the traffic consumption issue after connecting my main WordPress site to Tencent Cloud EdgeOne.
In the previous article, I completed one important adjustment: I moved the WordPress /wp-content/uploads/ media library resources to media.shuijingwanwq.com, and routed that media subdomain through Cloudflare instead of EdgeOne.
Previous article:
This article is not about making another immediate change. Instead, it records a new cost-control decision: whether it is worth moving the English site from www.shuijingwanwq.com/en/ to en.shuijingwanwq.com/, and routing the English subdomain through Cloudflare to further reduce EdgeOne traffic consumption.
![[Figure 1: Traffic cost investigation in the previous EdgeOne article]](https://media.shuijingwanwq.com/2026/07/1-26.png)
1. Current architecture: uploads have been moved to Cloudflare, but www still handles many requests
First, it is important to clarify the current architecture.
The previous article did not move “all static resources to Cloudflare”. It only moved the WordPress uploads media library resources to the media subdomain.
A more accurate view of the current structure is:
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 等上传文件
In other words, media.shuijingwanwq.com does not handle all static resources of the WordPress site. It only handles the WordPress media library uploads directory.
This distinction matters.
After moving uploads away, EdgeOne indeed no longer shows a large amount of image and attachment traffic related to /wp-content/uploads/. However, www.shuijingwanwq.com still receives many requests for page HTML, theme CSS, plugin JS, wp-includes resources, sitemaps, feeds, category pages, tag pages, English pages, and other content.
So the question has changed from:
如何把 /wp-content/uploads/ 图片和附件从 EdgeOne 拆出去
to:
在 uploads 已经拆出去之后，是否还需要继续把 /en/ 英文页面流量从 EdgeOne 拆出去
2. Current problem: today’s EdgeOne traffic trend is still too high
This morning, I continued checking EdgeOne analytics.
By around 9 a.m., today’s L7 traffic was roughly:
1.4 GB
Using that pace for a rough estimate:
1.4 GB ÷ 9 小时 × 24 小时 ≈ 3.7 GB/天
Calculated over 30 days:
3.7 GB × 30 ≈ 111 GB/月
But my goal is to keep EdgeOne monthly traffic under:
50 GB/月以内
Converted to a daily budget, that is only about:
50 GB ÷ 30 ≈ 1.67 GB/天
In other words, the current trend is more than twice the target level.
This means that although moving uploads to Cloudflare has already reduced part of the EdgeOne traffic, the 50 GB monthly EdgeOne traffic target is still tight if the current architecture remains unchanged.
![[Figure 2: EdgeOne L7 traffic screenshot showing about 1.4 GB today]](https://media.shuijingwanwq.com/2026/07/2-25-1024x451.png)
3. Page caching is not the main issue right now
At first, I suspected that WordPress page HTML might not be cached properly by EdgeOne.
That was because the MISS ratio looked relatively high in EdgeOne’s cache status statistics.
Later, however, I tested with a Firefox private window and curl GET requests, and confirmed that page caching was actually working.
Test article page:
https://www.shuijingwanwq.com/2026/05/29/14108/
第 1 次：eo-cache-status: MISS
第 2 次：eo-cache-status: HIT
第 3 次：eo-cache-status: HIT
Test English homepage:
https://www.shuijingwanwq.com/en/
第 1 次：eo-cache-status: MISS
第 2 次：eo-cache-status: HIT
第 3 次：eo-cache-status: HIT
This shows that EdgeOne can cache WordPress page HTML.
The high MISS ratio in the dashboard is more likely caused by:
1. 历史文章、分类页、标签页很多，URL 非常分散；
2. Bot 会抓取大量不同页面，每个 URL 第一次访问都是 MISS；
3. EdgeOne 是边缘节点缓存，不同节点之间不是完全共享同一份缓存；
4. 页面 HTML 缓存 TTL 之前只有 10 分钟，过期后再次访问仍然会重新 MISS；
5. uploads 图片流量已经拆走后，EdgeOne 剩下的主要就是页面和非 uploads 资源，MISS 占比自然会更显眼。
So it does make sense to extend the HTML page cache TTL, for example from 10 minutes to 1 hour. But this kind of optimization mainly reduces:
EdgeOne → 源站
That means fewer origin requests, lower origin pressure, and faster page responses.
It does not necessarily reduce:
访问者 / Bot → EdgeOne
this part of L7 response traffic.
As long as a visitor or crawler downloads a page from EdgeOne, EdgeOne still generates response traffic. Whether the page is a HIT or MISS mainly affects whether EdgeOne needs to fetch from the origin, not whether EdgeOne sends downstream traffic.
Therefore, if the goal is to control EdgeOne plan traffic, improving the cache hit ratio alone cannot fully solve the problem.
4. Bot traffic exists, but blocking one User-Agent is not enough
The User-Agent ranking clearly shows a meaningful amount of bot traffic.
One obvious example is:
meta-externalagent/1.1
256.99 MB，占 18.4%
There are also:
curl/8.7.1
bingbot
SemrushBot
Baiduspider
Amazonbot
DotBot
Some of these User-Agents are search engine crawlers, some are SEO tool crawlers, and some may be AI or scraping-related crawlers.
![[Figure 3: EdgeOne User-Agent ranking screenshot]](https://media.shuijingwanwq.com/2026/07/3-24.png)
However, blocking only curl/8.7.1 would not help much. It accounted for roughly 5% of the traffic this morning. Even if it were fully blocked, it would still be difficult to bring the estimated 3.7 GB/day down to the target of 1.67 GB/day.
Bot handling should be a long-term strategy, not the only solution for the current problem.
A more reasonable bot strategy should be tiered:
保留：
Googlebot、Bingbot、Baiduspider
观察：
meta-externalagent
限制或拦截：
SemrushBot、DotBot、Amazonbot、GPTBot、ClaudeBot、curl、python-requests、Go-http-client、AhrefsBot、MJ12bot、PetalBot、Bytespider
But these rules may affect search indexing, social previews, and legitimate traffic. They also carry a risk of false positives. Without a complete strategy, large-scale blocking is not suitable yet.
So I continued looking for a more controllable traffic split.
5. Key finding: the /en/ English path accounts for about one-third of EdgeOne traffic
To decide whether the English site is worth migrating separately, I added a filter in EdgeOne analytics:
URL path / 开始于 /en/
After filtering, I could see that from midnight to around 9 a.m. today, traffic related to /en/ was:
486.14 MB
Today’s total traffic was about:
1.4 GB
So the English /en/ path accounted for roughly:
486 MB ÷ 1434 MB ≈ 33.9%
In other words, the English path is currently consuming about one-third of EdgeOne traffic.
![[Figure 4: EdgeOne traffic screenshot filtered by URL path starting with /en/]](https://media.shuijingwanwq.com/2026/07/4-24-1024x664.png)
/en/]This is already a significant share.
If I move:
https://www.shuijingwanwq.com/en/*
to:
https://en.shuijingwanwq.com/*
and route en.shuijingwanwq.com through Cloudflare instead of EdgeOne, then in theory EdgeOne traffic could drop by about one-third.
Based on the current trend:
当前预计：3.7 GB/天
去掉 /en/ 约 34%：3.7 × (1 - 0.34) ≈ 2.44 GB/天
Converted to monthly traffic:
2.44 GB × 30 ≈ 73 GB/月
This still does not bring the traffic below 50 GB/month, but it is a clear reduction from the original estimate of 111 GB/month.
So migrating the English site is not the final answer, but it is a clear, controllable, and high-impact intermediate step.
6. Why the English site is a good candidate for a subdomain split
The main reason I use EdgeOne for the primary site is to maintain a better access experience from mainland China.
But the English site is mainly intended for overseas readers. For that part of the audience, continuing to route through EdgeOne is not the only option.
If the English site is moved to:
en.shuijingwanwq.com
and routed through Cloudflare, the structure would become:
www.shuijingwanwq.com
↓
EdgeOne
↓
中文主站 + 非 uploads 资源 + 仍保留在 www 下的请求
media.shuijingwanwq.com
↓
Cloudflare
↓
WordPress uploads 媒体库资源
en.shuijingwanwq.com
↓
Cloudflare
↓
英文站页面
The benefits would be:
1. EdgeOne 继续服务中文主站，优先保障中国大陆访问体验；
2. 英文站主要面向海外用户，交给 Cloudflare 更合理；
3. EdgeOne 的访问流量可以直接减少一部分；
4. 中文站、英文站、媒体资源的流量边界更清晰；
5. 后续更容易分别观察各自的缓存、Bot、流量成本。
Of course, there are costs as well:
1. 中国大陆用户访问英文站可能会慢一些；
2. 需要处理 /en/* 到 en 子域名的 301；
3. 需要确认 WordPress / Polylang 多语言配置是否支持这种结构；
4. 需要处理 sitemap、canonical、hreflang、站内链接；
5. 需要避免大量旧标签规则和新迁移规则发生冲突。
So this is not a simple DNS adjustment. It is a full URL architecture migration.
7. The complexity of the existing 301 rules
The site currently has a large number of 301 rules in Nginx, roughly around 8,000 entries.
These rules are mainly used for:
1. 中文标签 slug 合并；
2. 英文路径下中文标签 slug 翻译为英文 slug；
3. 部分旧专题路径合并到新专题路径。
The current configuration is similar to this:
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/";
}
Then it is executed inside the server block:
if ($new_tag_uri != "") {
return 301 $new_tag_uri;
}
If I directly add a generic rule like this:
/en/* → https://en.shuijingwanwq.com/*
it may create two 301 redirects.
For example:
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/
The final destination would still be correct, but the extra 301 in the middle is not ideal.
The better result should be a single redirect to the final URL:
https://www.shuijingwanwq.com/en/tag/30-天试用/
→ https://en.shuijingwanwq.com/tag/30-day-trial-en/
Therefore, when migrating the English site, I cannot simply place a broad /en/* redirect rule at the top.
8. Recommended 301 handling logic
A safer approach is to keep the existing 8,000 map rules unchanged, and add one additional layer of “final destination conversion” before the actual redirect.
The overall logic is:
第一步：
旧标签 / 旧专题规则先把旧 URL 映射为标准路径。
第二步：
如果标准路径以 /en/ 开头，则最终跳转到 en.shuijingwanwq.com，并去掉 /en/ 前缀。
第三步：
如果标准路径不是 /en/ 开头，则继续跳转到 www.shuijingwanwq.com。
The expected results should be:
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/
The advantages of this approach are:
1. 不用手工修改 8000 条旧规则；
2. 英文旧标签可以一次跳转到最终英文子域名；
3. 中文标签合并逻辑仍然保留在 www 主域名；
4. 普通 /en/ 文章页、分类页、标签页可以统一迁移；
5. 可以避免大部分两次 301 的问题。
9. Things to confirm before migration
Before making the change in production, at least the following items need to be confirmed.
1. en.shuijingwanwq.com must not go through EdgeOne
This is the premise for reducing EdgeOne traffic.
If en.shuijingwanwq.com still routes through EdgeOne, then the migration only changes the URL structure and does not actually help with EdgeOne traffic cost.
The target should be:
en.shuijingwanwq.com
↓
Cloudflare
↓
英文站
2. Confirm whether WordPress / Polylang supports the English subdomain
After switching the English site to a subdomain, the following items need to work correctly:
英文首页
英文文章页
英文分类页
英文标签页
英文专题页
语言切换链接
canonical
hreflang
sitemap
站内链接
If Polylang is not configured correctly, internal links may still point to /en/, or canonical and hreflang tags may become inconsistent.
3. 301 redirects should go to the final URL in one step whenever possible
This is especially important for old English tag URLs like:
/en/tag/30-天试用/
The ideal result should be:
https://en.shuijingwanwq.com/tag/30-day-trial-en/
Instead of first redirecting to:
https://www.shuijingwanwq.com/en/tag/30-day-trial-en/
and then redirecting again to the English subdomain.
4. Search engines need the English site to be submitted again
After the migration, en.shuijingwanwq.com should be added as a new property in Google Search Console and Bing Webmaster Tools.
A new English sitemap should also be submitted, and the indexing migration should be monitored.
5. Slower mainland China access to the English site must be accepted
The core trade-off of this solution is:
中文主站继续走 EdgeOne，保障中国大陆访问体验；
英文站走 Cloudflare，降低 EdgeOne 流量成本，并更适合海外读者。
If users in mainland China access the English site more slowly, that is an acceptable side effect.
10. Recommended execution order
I will not execute this immediately. When I have time later, I can move forward in the following order.
Step 1: Prepare en.shuijingwanwq.com
First, add the DNS record for the English subdomain and confirm that it goes through Cloudflare.
Do not switch production traffic at the beginning. First make sure the subdomain can access the English site content.
Step 2: Confirm the WordPress multilingual configuration
Check whether Polylang or the current multilingual plugin supports:
中文：https://www.shuijingwanwq.com/
英文：https://en.shuijingwanwq.com/
Focus on verifying language switching, canonical tags, hreflang tags, and sitemaps.
Step 3: Adjust the Nginx 301 rules
Add final destination conversion on top of the existing map $uri $new_tag_uri logic.
The goal is to let the old-path correction rules take priority, with the English subdomain migration as the fallback.
Step 4: Test key URLs locally
At minimum, test the following paths:
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
Focus on checking:
是否 301
是否只跳一次
Location 是否为最终地址
是否保留查询参数
是否出现循环跳转
Step 5: Monitor EdgeOne traffic after launch
After the migration is complete, return to EdgeOne analytics and continue filtering by:
URL path / 开始于 /en/
The ideal result is that traffic under /en/ on www.shuijingwanwq.com drops significantly.
At the same time, monitor whether total EdgeOne traffic drops from the current estimate of:
约 3.7 GB/天
to:
约 2.4 GB/天左右
The actual result may be affected by bots, caching, and search engines recrawling the site, so it needs to be observed for a few days rather than judged only on the migration day.
11. Current decision
Based on the current data, the /en/ English path accounts for about one-third of today’s EdgeOne traffic.
This means moving the English site from:
https://www.shuijingwanwq.com/en/
to:
https://en.shuijingwanwq.com/
and routing the English subdomain through Cloudflare is a cost optimization plan worth taking seriously.
But it is not the final solution.
Based on the current estimate, even if /en/ is moved away from EdgeOne, monthly EdgeOne traffic may still be around 70 GB, which is still above the target of 50 GB/month. The next stages still need to address:
低价值 Bot
Meta/Facebook 爬虫流量
页面体积
主题和插件前端资源
HTML 缓存 TTL
异常路径请求
So this migration is more like the first stage of a larger traffic split:
第一阶段：
uploads 媒体库资源 → media.shuijingwanwq.com → Cloudflare
第二阶段：
英文站页面 → en.shuijingwanwq.com → Cloudflare
第三阶段：
中文主站继续走 EdgeOne，并进一步优化 Bot、缓存和页面体积
The current conclusion is:
可以迁移，但不要仓促迁移。
先形成方案，确认 Polylang、Cloudflare、Nginx 301、sitemap、canonical、hreflang 都没有问题后，再分步骤执行。
The core goal of this change is not simply to modify the URL structure. It is to redefine the traffic boundaries:
中文主站优先保障中国大陆访问体验；
英文站交给更适合海外访问的 Cloudflare；
uploads 媒体库继续由 media 子域名承接；
EdgeOne 流量尽量控制在可接受范围内。
In the long run, this architecture is clearer than putting everything behind www.shuijingwanwq.com + EdgeOne, and it should also make future cost control easier.
Linux Server Operations, Deployment & Production Troubleshooting
If your website or backend service runs on a Linux server and you are facing unstable access, Nginx configuration issues, MySQL / Redis errors, Docker service failures, full disk usage, or high CPU / memory usage, feel free to contact me for remote troubleshooting.
Ideal For:
✅ Website downtime or unstable access
✅ Nginx / PHP-FPM configuration issues
✅ MySQL / Redis performance or connection problems
✅ Docker service deployment and maintenance
✅ Server migration and environment setup
✅ CPU / memory / disk usage investigation
What I Offer:
✅ Linux environment inspection
✅ Website migration and deployment
✅ Nginx / PHP-FPM / MySQL / Redis troubleshooting
✅ Docker configuration and maintenance
✅ Server performance analysis
✅ Long-term remote operations support
Please contact me and mention: Linux Operations Consultation.
Contact Me:
Telegram: @shuijingwan
WeChat: 13980074657
Email: shuijingwanwq@gmail.com
Leave a Reply