In the previous article, I documented the process of moving WordPress uploaded assets to the dedicated media.shuijingwanwq.com subdomain and letting Cloudflare handle static asset delivery.
Previous article:
This follow-up adjustment was made after the migration was already complete.
During the migration, the site’s CDN architecture changed, but the existing Cloudflare Cache Rules were not updated at the same time.
So I needed to reorganize the Cloudflare caching strategy and make it match the new CDN architecture.
1. Current WordPress CDN Architecture
Before:
整个 WordPress 网站
|
↓
Cloudflare
Cloudflare was responsible for:
- HTML pages
- CSS
- JS
- Images
- uploaded attachments
That is why the Cache Rules contained many WordPress-specific rules.
After the migration, the site now uses a split-asset architecture:
用户访问网站
|
|
+--------------------------------+
| |
↓ ↓
www.shuijingwanwq.com media.shuijingwanwq.com
| |
↓ ↓
EdgeOne Cloudflare
| |
↓ ↓
WordPress 主站资源 uploads 目录资源
（除 uploads 外） （所有上传文件）
More specifically:
www.shuijingwanwq.com
Accelerated through EdgeOne:
- WordPress page HTML
- CSS
- JavaScript
- theme files
- plugin files
- WordPress core files
- other assets outside the uploads directory
media.shuijingwanwq.com
Accelerated through Cloudflare:
- Images
- ZIP
- document attachments
- other uploaded files
These assets originally lived under:
/wp-content/uploads/
directory.
2. Legacy Cloudflare Cache Rules Found After the Migration
After the migration, I checked the Cloudflare configuration and found that:
The Cache Rules originally designed for the main WordPress site were still there.
These rules included:
- bypassing cache for the WordPress admin area
- bypassing cache for the WordPress login page
- bypassing cache for the WordPress REST API
- HTML page caching
- CSS/JS static asset caching
- uploads static asset caching
Those rules made sense before.
At that time:
www.shuijingwanwq.com
↓
Cloudflare
↓
整个 WordPress 网站
But now:
www.shuijingwanwq.com
↓
EdgeOne
no longer goes through Cloudflare.
So these rules no longer match the current architecture.
3. The Old uploads Cache Rule No Longer Works
The previous Cloudflare static asset cache rule:
Matched:
/wp-content/uploads/
Expression:
starts_with(http.request.uri.path, "/wp-content/uploads/")
But the access path has now changed.
Before:
www.shuijingwanwq.com/wp-content/uploads/2026/07/example.jpg
Now:
media.shuijingwanwq.com/2026/07/example.jpg
Request path:
/2026/07/example.jpg
As a result, the original rule can no longer match the request.
4. Redesigning the Cloudflare Media CDN Cache Rule
Since Cloudflare is now only responsible for:
media.shuijingwanwq.com
the new rule should no longer rely on the old path.
Instead, it should match directly by Host:
Condition:
Hostname equals media.shuijingwanwq.com
Expression:
http.host eq "media.shuijingwanwq.com"
With this setup:
Only:
media.shuijingwanwq.com/*
will enter the Cloudflare cache.
It will not affect:
www.shuijingwanwq.com
5. Setting a Long-Term Caching Strategy
Files in the uploads directory have several useful characteristics:
- they rarely change after being uploaded
- their URLs include date-based paths
- new files do not overwrite old files
For example:
media.shuijingwanwq.com/2026/07/example.jpg
Later:
media.shuijingwanwq.com/2026/08/new.jpg
is treated as a new asset.
So these assets are suitable for long-term caching.
Edge TTL
Set:
忽略缓存控制标头，使用此 TTL
1 年
Browser TTL
Set:
1个月
With this setup:
- Cloudflare edge nodes can keep these assets for a long time
- browsers will not keep old assets forever
6. Disabling the Old WordPress Cache Rules
Since the main WordPress site is now handled by EdgeOne, the following Cloudflare rules are no longer needed:
- bypassing cache for the WordPress admin area
- bypassing cache for the WordPress login page
- bypassing cache for the WordPress REST API
- CSS/JS static asset cache optimization
- HTML page caching
I did not delete these rules. I disabled them instead.
Reason:
- keep the historical configuration
- make it easier to restore the rules if the architecture changes again
- reduce the risk of accidental misconfiguration
In the end, Cloudflare only keeps:
media.shuijingwanwq.com
↓
上传资源长期缓存
7. Verifying the Cloudflare Cache Result
After the adjustment, I verified the result with curl:
curl -I https://media.shuijingwanwq.com/2026/06/9-22-1024x480.png
Response:
server: cloudflare
cf-cache-status: HIT
This shows that:
static asset requests are now being served through Cloudflare cache.
Access flow:
用户
↓
Cloudflare Edge Cache
↓
源站 uploads 文件
8. Why Cache Rules Are Easy to Miss During a Migration
The root cause of this issue was:
A site migration is not just a DNS change.
Especially when using a multi-CDN architecture, several things must be reviewed together:
DNS
↓
域名规划
↓
CDN 接入
↓
源站配置
↓
资源路径
↓
缓存规则
↓
安全策略
During this migration, I focused on:
- creating the media subdomain
- migrating the uploads directory
- connecting the CDN
- access verification
But I missed:
- the existing Cloudflare Cache Rules
The reason was:
Previously, Cloudflare was:
整个网站 CDN
Now, Cloudflare is:
静态资源 CDN
Once the responsibility changes, the caching strategy also needs to be updated.
9. Final CDN Architecture
The final architecture is as follows:
WordPress 网站访问：
www.shuijingwanwq.com
↓
EdgeOne
↓
WordPress 主站资源
（除 uploads 外）
静态资源访问：
media.shuijingwanwq.com
↓
Cloudflare
↓
uploads 目录全部资源
Final responsibilities:
| Hostname | CDN | Responsibility |
|---|---|---|
| www.shuijingwanwq.com | EdgeOne | main WordPress site and non-uploads assets |
| media.shuijingwanwq.com | Cloudflare | uploads static assets such as images and attachments |
Summary
This adjustment was not a new CDN migration. It was a refinement of the existing architecture.
The previous article solved this problem:
how to split the WordPress uploads directory into a dedicated media subdomain.
This article solves the next problem:
after the split is complete, how to adjust Cloudflare Cache Rules so they fit the new static asset CDN architecture.
For a long-running website, CDN optimization is not only about:
- DNS
- CNAME
- CDN nodes
It also includes:
- cache rules
- TTL settings
- hostname matching scope
- asset responsibility boundaries
Only when these settings stay aligned can a hybrid CDN architecture run reliably over the long term.