There is no problem not worth solving, and no technology not worth learning!

Cloudflare Cache Rules Adjustment After Migrating WordPress Media to a CDN

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

作者:

WordPress CDN & Global Acceleration Practice

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

(1) Complete migration combat record from Alibaba Cloud DNS to Cloudflare global acceleration

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

(2) CloudFlare SSL/TLS and Cache Rules configuration combat

图12:评论实时生效

(3) WordPress + CloudFlare Recommended Configuration with Cache Rules Practical Optimization (SSL/API/Cached Closed Loop Full Record)

CDN上线后的boce数据

(4) Performance comparison before and after CDN launch: WordPress cache misjudgment correction and real acceleration effect verification

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

(5) Is Cloudflare Free Suitable for a Mainland China WordPress Site? A Real-World Test from Cache HIT to Gray-Cloud Direct Aliyun ECS

[Figure 1: Tencent Cloud EdgeOne product page, selecting “Start Now”]

(6) Migrating a WordPress Main Site from Cloudflare Free to Tencent Cloud EdgeOne: A Real-World CDN Acceleration Setup for China and Overseas Traffic

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

(7) How Much Faster Is EdgeOne After Migrating from Cloudflare Free? A Three-Stage WordPress CDN Test with boce and WebPageTest

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

(8) EdgeOne Traffic Cost Troubleshooting: Moving WordPress Uploads Static Assets to a Cloudflare Media Subdomain

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

(9) Troubleshooting Persistent EdgeOne 301 Requests After Moving WordPress Images to a Media Subdomain

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

(10) Cloudflare Cache Rules Adjustment After Migrating WordPress Media to a CDN

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:

Plaintext
整个 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:

Plaintext
用户访问网站

        |
        |
        +--------------------------------+
        |                                |
        ↓                                ↓

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
  • PDF
  • ZIP
  • document attachments
  • other uploaded files

These assets originally lived under:

Plaintext
/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.

Figure 1: Existing Cloudflare Cache Rules configuration
Figure 1: Existing Cloudflare Cache Rules configuration

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:

Plaintext
www.shuijingwanwq.com



Cloudflare



整个 WordPress 网站

But now:

Plaintext
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:

Plaintext
/wp-content/uploads/

Expression:

Plaintext
starts_with(http.request.uri.path, "/wp-content/uploads/")
Figure 2: Original uploads path cache rule
Figure 2: Original uploads path cache rule

But the access path has now changed.

Before:

Plaintext
www.shuijingwanwq.com/wp-content/uploads/2026/07/example.jpg

Now:

Plaintext
media.shuijingwanwq.com/2026/07/example.jpg

Request path:

Plaintext
/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:

Plaintext
media.shuijingwanwq.com

the new rule should no longer rely on the old path.

Instead, it should match directly by Host:

Condition:

Plaintext
Hostname equals media.shuijingwanwq.com

Expression:

Plaintext
http.host eq "media.shuijingwanwq.com"
Figure 3: New cache rule for the media subdomain
Figure 3: New cache rule for the media subdomain

With this setup:

Only:

Plaintext
media.shuijingwanwq.com/*

will enter the Cloudflare cache.

It will not affect:

Plaintext
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:

Plaintext
media.shuijingwanwq.com/2026/07/example.jpg

Later:

Plaintext
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:

Plaintext
忽略缓存控制标头,使用此 TTL

1 年

Browser TTL

Set:

Plaintext
1个月

Figure 4: Cloudflare Edge TTL and Browser TTL settings
Figure 4: Cloudflare Edge TTL and Browser TTL settings

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
Figure 5: Cloudflare Cache Rules after disabling old rules
Figure 5: Cloudflare Cache Rules after disabling old rules

In the end, Cloudflare only keeps:

Plaintext
media.shuijingwanwq.com



上传资源长期缓存

7. Verifying the Cloudflare Cache Result

After the adjustment, I verified the result with curl:

Bash
curl -I https://media.shuijingwanwq.com/2026/06/9-22-1024x480.png

Response:

Plaintext
server: cloudflare

cf-cache-status: HIT

Figure 6: Verifying Cloudflare HIT with curl
Figure 6: Verifying Cloudflare HIT with curl

This shows that:

static asset requests are now being served through Cloudflare cache.

Access flow:

Plaintext
用户



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:

Plaintext
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:

Plaintext
整个网站 CDN

Now, Cloudflare is:

Plaintext
静态资源 CDN

Once the responsibility changes, the caching strategy also needs to be updated.


9. Final CDN Architecture

The final architecture is as follows:

Plaintext
WordPress 网站访问:

www.shuijingwanwq.com



EdgeOne



WordPress 主站资源

(除 uploads 外)


静态资源访问:

media.shuijingwanwq.com



Cloudflare



uploads 目录全部资源

Final responsibilities:

HostnameCDNResponsibility
www.shuijingwanwq.comEdgeOnemain WordPress site and non-uploads assets
media.shuijingwanwq.comCloudflareuploads 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.

Troubleshooting Persistent EdgeOne 301 Requests After Moving WordPress Images to a Media Subdomain

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

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.