【宋词】《临江仙》 晁冲之：忆昔西池池上饮，年年多少欢娱。别来不寄一行书。寻常相见了，犹道不如初。安稳锦屏今夜梦，月明好度江湖。相思休问定何如。

永夜

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

Cloudflare Cache Hits Are Fast, but Misses Fluctuate: A Real Optimization for Origin Fetches to Alibaba Cloud Hangzhou

[Figure 3: Cloudflare Smart Tiered Cache enabled]

作者：

永夜

在

Post Views: 0

Recently, while maintaining the A Tour of Go multilingual project, I encountered a very typical problem:

The site is usually fast to access, and pages that have already achieved a Cloudflare cache HIT generally show no issues.

However, whenever I release a new version, clear the cache, or access a resource that hasn’t entered the cache yet, resulting in MISS, the request can suddenly slow down or even time out.

Most of my non-Chinese language sites currently use the free tier of Cloudflare, while the origin server remains located in Alibaba Cloud Hangzhou, mainland China.

The approximate link is:

Plaintext
User
  ↓
Cloudflare
  ↓
Alibaba Cloud Hangzhou origin server

When there is a cache HIT, the origin server might not even participate at all.

The real problem often only surfaces after a cold MISS requires a fetch from the origin.

During this troubleshooting process, I一度 had already considered migrating the origin server overseas, or switching all non-Chinese sites from Cloudflare back to EdgeOne.

Ultimately, I did neither.

What I finally enabled was Cloudflare Smart Tiered Cache.

And the improvement it brought was far more significant than I initially expected.

Initially, I was mainly focused on improving my own deployment success rate

This problem wasn’t something I suddenly discovered one day and solved in one go.

From the Git history, it can be seen that my early efforts were primarily focused on:

Making the Production workflow more tolerant of transient public network failures.

[Figure 1: Timeline for handling the Cloudflare cold cache problem]
[Figure 1: Timeline for handling the Cloudflare cold cache problem]

A series of consecutive changes included:

Plaintext
fix: Enhance transient fault tolerance for production public network acceptance
fix: Improve transient fault tolerance for production cold cache
fix: Execute multilingual production maintenance in stages
fix: Improve production recovery pre-check and CDN tunnel retry
fix: Enhance production browser error diagnostics
docs: Record Smart Tiered Cache production baseline

Initially, the purpose of these changes was actually very clear:

To increase the probability that my own Production release would complete successfully in one go.

For example:

  • Performing a bounded retry for transport timeouts like curl exit 28;
  • Allowing limited retries for brief network errors such as Cloudflare 522 and 525;
  • Adding limited convergence for browser navigation;
  • Adding recovery states for long-running tasks;
  • Retaining clearer network evidence upon failure.

These optimizations themselves were all valuable.

Assuming a release requires verifying 10 language sites, and one particular request happens to fail the first time due to public network fluctuations, causing the entire release to abort immediately is indeed unreasonable.

But as I progressed, I gradually realized:

These optimizations primarily solved the issue of “whether my deployment was prone to failure,” but they did not improve the actual access experience for real website users during a cold MISS.

For example, increasing the timeout from 15 seconds to 25 seconds gave the verifier a better chance of waiting for the request to eventually succeed.

But when a user opens the webpage:

They might still end up waiting for over 20 seconds.

My deployment script can:

Plaintext
First attempt fails
→ Wait 1 second
→ Retry once
→ Success

Thus, Production passes.

But ordinary users do not automatically get a better first-time access experience just because my deployment script has become smarter.

So, this actually needs to be broken down into two separate problems:

Plaintext
Deployment side:
How to prevent brief network fluctuations from causing the entire Production batch to fail?

User side:
How to genuinely improve the experience when a Cloudflare cold MISS fetches from the Alibaba Cloud Hangzhou origin?

The former can be improved through bounded retries.

The latter requires dealing with the actual network path.

A cold MISS once waited about 21.8 seconds

What really made me take the origin fetch link seriously was a single cold MISS.

It was once observed in formal Production that:

A request finally succeeded after approximately 21.8 seconds.

[Figure 2: The cold MISS observed at the time that took about 21.8 seconds to succeed]
[Figure 2: The cold MISS observed at the time that took about 21.8 seconds to succeed]

It was precisely because of this actual result that I later adjusted the single-request limit for some Production readiness checks to 25 seconds.

This is a place where it is easy to misunderstand.

Raising the timeout does not mean:

It is acceptable for a website request to take 25 seconds to return.

It is only to prevent the Production verifier from prematurely judging a request as failed at the 15th second when the actual request succeeds at the 21.8th second.

This solves the problem of false negatives in automated verification.

It does not solve the actual access speed problem.

From this point onward, I increasingly made a clear distinction between:

Plaintext
HIT speed

and:

Plaintext
MISS origin fetch speed

If what is opened normally is an already cached page, Cloudflare might return it very quickly.

This does not prove at all that:

The actual origin fetch path from Cloudflare to Alibaba Cloud Hangzhou is equally fast.

Fast HIT does not mean fast origin fetch

During a cache HIT, it can be very roughly understood as:

Plaintext
User
 ↓
Cloudflare Edge
 ↓
Cache
 ↓
User

The Alibaba Cloud Hangzhou origin server might not have received this request at all.

However, without Tiered Cache, a cold MISS is closer to:

Plaintext
User
 ↓
Cloudflare Edge
 ↓
Local cache MISS
 ↓
Alibaba Cloud Hangzhou
 ↓
Cloudflare
 ↓
User

What is truly unstable is likely:

Plaintext
A specific Cloudflare Edge
→
Alibaba Cloud Hangzhou

So what I was seeing at the time was a very typical phenomenon:

Plaintext
Cache is already warm:
Very fast

Just purged:
Might be very slow

First access to a niche Angular partial:
Might be very slow

Subsequent access:
Fast again

If just doing a daily refresh of an already HIT homepage, it is easy to mistakenly think:

That the website has no problems at all.

At that point, I had already started considering two larger solutions

Reaching this point, I was actually no longer just thinking about adjusting timeouts.

If the link from Cloudflare back to the mainland China origin server is inherently unstable long-term, then the more direct approach is to change the architecture.

I was mainly considering two options at the time.

Option 1: Migrate the origin server to overseas zgocloud

The first idea was:

To directly migrate the Production origin from Alibaba Cloud Hangzhou to an overseas zgocloud.

This would fundamentally change:

Plaintext
Cloudflare
→
Mainland China origin server

This cross-region origin fetch path.

From a network perspective, it is very straightforward.

But it is not just changing a configuration; it is migrating the entire Production origin.

It involves:

Plaintext
Nginx
systemd
release directory
deployment process
certificates
backups
security
monitoring
disaster recovery

And there was another issue I hadn’t clearly confirmed at the time:

ICP filing and access provider relationships.

Current Ministry of Industry and Information Technology regulations explicitly require that non-commercial internet information services provided within the People’s Republic of China must undergo filing procedures in accordance with the law. (Ministry of Industry and Information Technology)

But if I migrated the existing actual origin overseas while still retaining some domestic infrastructure, I was not entirely sure how to handle the existing ICP filing, the access provider, and subsequent changes.

Therefore, I was unwilling to directly introduce a whole new set of policy and architectural uncertainties just for a CDN cold MISS problem.

Option 2: Switch all non-Chinese sites back to EdgeOne

The other option was:

Since the origin server is already in Alibaba Cloud Hangzhou, should the non-Chinese language sites also stop using Cloudflare and switch entirely back to EdgeOne?

This option is also technically very natural.

The Chinese site was already using EdgeOne.

If everything was changed to a CDN architecture more suited for a mainland China origin server, it might be possible to directly bypass the current Cloudflare origin fetch path.

But this option also had a very practical issue:

Cost.

These non-Chinese community locales currently use the free tier of Cloudflare.

As the number of languages continues to grow:

Plaintext
10 sites
20 sites
30 sites
……

If all were switched to a CDN that continuously incurs actual costs, the long-term operating costs would increase proportionally.

And currently, the advertising revenue for the A Tour of Go multilingual project remains very low.

Aside from that, the current:

Plaintext
Cloudflare Cache Rule
hostname purge
shared assets
Production verifier
new locale Production baseline

have all formed stable workflows around the Cloudflare community locales.

Switching entirely back to EdgeOne also means the existing Production architecture would need to be migrated again.

So, I first looked for a smaller solution within Cloudflare itself

The actual choice at that point became:

Plaintext
Option A:
Migrate to an overseas origin
→ Largest change
→ ICP filing and access boundaries need confirmation

Option B:
Switch entirely back to EdgeOne
→ Technically feasible
→ Higher long-term CDN costs

Option C:
Continue using Cloudflare
→ Prioritize optimizing Cloudflare's own origin fetch topology

Before actually making the first two major changes, I decided to try the third option first.

So I started looking seriously into:

Smart Tiered Cache.

What exactly does Smart Tiered Cache change?

In the Cloudflare Dashboard:

Plaintext
Cache
→ Tiered Cache

I ultimately enabled:

Plaintext
Smart Tiered Cache

It currently shows:

Plaintext
Tiered Cache Topology: Active
[Figure 3: Cloudflare Smart Tiered Cache enabled]
[Figure 3: Cloudflare Smart Tiered Cache enabled]

Cloudflare’s official explanation for Tiered Cache is:

It divides data centers into a lower tier and an upper tier.

If the lower tier does not have the content, it does not immediately access the origin; instead, it first queries the upper tier.

Only if the upper tier also lacks the content will the upper tier access the actual origin. (Cloudflare Docs)

So the link becomes:

Plaintext
User
 ↓
Lower-tier Edge
 ↓
Upper Tier
 ↓
Origin

It looks like it adds an extra layer compared to before.

This was also what confused me the most at first:

Why does going through an additional node actually make it faster?

Why might a three-layer network be faster than a two-layer one?

Without Tiered Cache, a MISS might be:

Plaintext
User
 ↓
A specific Cloudflare Edge
 ↓
Alibaba Cloud Hangzhou

What truly determines the quality of the origin fetch is:

Plaintext
This Edge
→
Alibaba Cloud Hangzhou

If the quality of this path is poor, having fewer nodes is meaningless.

After enabling Smart Tiered Cache, the path might become:

Plaintext
User
 ↓
Lower Tier
 ↓
Cloudflare network
 ↓
Selected Upper Tier
 ↓
Alibaba Cloud Hangzhou

Although there is an extra hop, what is added is primarily a segment within Cloudflare’s own network.

More importantly:

The node that is actually qualified to access the origin is consolidated to the upper tier.

Smart Tiered Cache also does not just randomly select an upper tier.

Cloudflare’s official documentation states that it uses its own performance and routing data, and collects the latency of each data center when accessing the origin, to dynamically select an upper tier with lower connection latency for the origin. (Cloudflare Docs)

Therefore:

Plaintext
Fewer nodes

does not equal:

Plaintext
necessarily faster

What truly matters for the network is:

Plaintext
The quality of the entire path

If what is added is a segment of Cloudflare’s internal network, but it changes:

Plaintext
Arbitrary Edge → Alibaba Cloud Hangzhou

into:

Plaintext
An Upper Tier better suited for accessing this origin → Alibaba Cloud Hangzhou

Then the overall performance could very well be faster instead.

More importantly: Lower Tier MISS no longer equals Origin MISS

This is actually what I later considered the most important point of Tiered Cache.

Once enabled, a request might be:

Plaintext
Lower Tier: MISS
       ↓
Upper Tier: HIT
       ↓
Direct return

In this case:

Alibaba Cloud Hangzhou would not receive the request at all.

Cloudflare’s official documentation also explicitly states that one of the goals of Tiered Cache is to have lower tier MISSes query the upper tier first, thereby increasing the overall cache hit rate and reducing requests that actually reach the origin. (Cloudflare Docs)

What’s more interesting is:

If the lower tier itself does not have the cache, but the upper tier already has a HIT, what the end user sees for:

Plaintext
CF-Cache-Status

can still directly be:

Plaintext
HIT

Cloudflare’s official documentation explicitly mentions that when populating the local data center cache from the upper tier for the first time, the response can show HIT; this HIT reflects an upper-tier hit, not that this local Edge already had the cache. The first such response might not even have Age yet, which only appears later when there is a true local cache hit. (Cloudflare Docs)

This implies a very important distinction:

Plaintext
Local Edge MISS
≠
Origin MISS

Previously, when a specific Edge accessed a certain URL for the first time, it likely meant:

Plaintext
Accessing Alibaba Cloud Hangzhou once again

Now, it might just be:

Plaintext
Lower Tier MISS
→ Upper Tier HIT
→ Alibaba Cloud Hangzhou is not accessed at all

Does a URL only need one true MISS?

In an ideal scenario, it can be understood this way, but with caveats.

Assuming:

  • The cache key is exactly the same;
  • The content is still fresh;
  • The upper tier has not been evicted;
  • There has been no purge;
  • Smart Tiered Cache’s upper-tier assignment has not changed;

Then the following might occur:

Plaintext
First request:

Tokyo Lower Tier MISS
→ Upper Tier MISS
→ Alibaba Cloud Hangzhou
→ User sees MISS

Subsequently, when another region accesses it for the first time:

Plaintext
Los Angeles Lower Tier MISS
→ Upper Tier HIT
→ User sees HIT

Germany:

Plaintext
Germany Lower Tier MISS
→ Upper Tier HIT
→ User sees HIT

France:

Plaintext
France Lower Tier MISS
→ Upper Tier HIT
→ User sees HIT

Thus, from the origin’s perspective:

For the same cache key in this cache lifecycle, it might only need to fetch from Alibaba Cloud Hangzhou the very first time.

Although different lower-tier Edges subsequently experience their own local MISSes, they can retrieve content directly from the upper tier.

This is exactly why Tiered Cache can drastically reduce origin requests. (Cloudflare Docs)

Of course, this does not mean a URL will only ever have one true MISS.

The following situations could all trigger a true origin fetch again:

  • Manual purge;
  • TTL expiration;
  • Upper tier cache eviction;
  • Cache key change;
  • Upper tier assignment changes;
  • Origin / DNS / topology changes.

Cloudflare also explicitly states that if Smart Tiered Cache reselects an upper tier, the new upper tier needs to repopulate its cache, which might temporarily increase the MISS rate. (Cloudflare Docs)

This also explains why my own Production suddenly became much faster

My Production verifier is not an ordinary user.

It requests from the formal public network runner:

Plaintext
Homepage
Course pages
Angular partials
105 URLs in the sitemap
Cache status
Browser pages

Without Tiered Cache, it might have been:

Plaintext
verifier
 ↓
A specific Cloudflare Edge
 ↓
MISS
 ↓
Direct fetch to Alibaba Cloud Hangzhou

So every time it encountered a new Edge / cold object, it might have to re-experience an unstable cross-region origin fetch.

After enabling Smart Tiered Cache, there are two possible scenarios.

The first:

Plaintext
Lower Tier MISS
→ Upper Tier HIT
→ Hangzhou is not accessed at all

The second:

Plaintext
Lower Tier MISS
→ Upper Tier MISS
→ The selected Upper Tier fetches from Hangzhou

Although the second scenario still accesses the origin server, it is no longer an arbitrary lower-tier Edge making the access, but rather the upper tier chosen by Cloudflare for this origin.

So the Production verifier itself directly benefits.

However, I do not want to assert based on existing evidence that:

The reason it became faster is primarily because the Upper Tier was completely HIT.

I do not have sufficient evidence for each individual request to calculate:

Plaintext
How many requests were Upper Tier HITs
How many requests were true origin fetches by the Upper Tier

What can be confirmed is:

After enabling Smart Tiered Cache, the performance of similar fresh MISSes improved significantly.

After enabling: the previously failing fresh MISS became 10/10 successful

After enabling Smart Tiered Cache, I retested the previously problematic Angular partial fresh MISS.

Result:

Plaintext
10/10 HTTP 200

Single request took approximately:

Plaintext
0.3～0.4 seconds
[Figure 4: Official record after Smart Tiered Cache optimization]
[Figure 4: Official record after Smart Tiered Cache optimization]

This contrasts sharply with the previously observed:

Plaintext
Success after about 21.8 seconds

Later, I officially recorded Smart Tiered Cache into the current Production baseline.

However, a boundary still needs to be maintained here:

21.8 seconds was an anomalous cold MISS that actually occurred previously;

0.3～0.4 seconds is the result of the 10 fresh MISS retests after enabling it.

This is enough for me to judge:

Smart Tiered Cache is highly worth keeping.

But it cannot be written as:

Smart Tiered Cache permanently optimized access latency from 21.8 seconds to 0.3 seconds.

This is not a strictly controlled variable benchmark.

I did not configure an Alibaba Cloud Cloud Region Hint

Cloudflare now also supports setting a cloud region hint for certain public cloud origins.

This directly tells Smart Tiered Cache:

Which cloud provider and which region the origin belongs to.

But the providers currently listed in Cloudflare’s official documentation are:

  • AWS
  • GCP
  • Azure
  • Oracle Cloud

Alibaba Cloud is not listed. (Cloudflare Docs)

So my Alibaba Cloud Hangzhou origin server was not configured with:

Plaintext
Alibaba Cloud Hangzhou

or any similar region hint.

Currently, it just lets Smart Tiered Cache use the latency / routing data collected by Cloudflare itself to select the upper tier.

From the actual results so far, this is already sufficient.

Smart Tiered Cache does not eliminate MISSes

After enabling it, real Production releases can still show:

Plaintext
CDN /: MISS -> HIT -> HIT PASS
CDN /tour/welcome/1: MISS -> HIT -> HIT PASS
[Figure 5: MISS → HIT → HIT in a real Production environment]
[Figure 5: MISS → HIT → HIT in a real Production environment]

This is completely normal.

After every new release, I officially purge the corresponding hostname cache.

Cloudflare’s official documentation states that after purging by hostname, subsequent requests will usually show MISS again; when using Tiered Cache, EXPIRED might also appear, depending on the status of the lower tier, upper tier, and where the request lands. (Cloudflare Docs)

So:

Plaintext
MISS
→ HIT
→ HIT

in itself does not mean Tiered Cache is not working.

What really needs attention is:

Whether this MISS actually reached the origin.

With Tiered Cache enabled:

Plaintext
Lower Tier MISS

can no longer be simply understood as:

Plaintext
Must fetch from Alibaba Cloud Hangzhou

Why does a curl exit 28 still occur after enabling Smart Tiered Cache?

What’s more interesting is:

Even after Smart Tiered Cache was enabled, a real Production run today still experienced:

Plaintext
curl exit 28
HTTP-000

It occurred during the sitemap verification for the Dutch site nl-NL.

[Figure 6: A transient timeout still occurring after enabling Smart Tiered Cache]
[Figure 6: A transient timeout still occurring after enabling Smart Tiered Cache]

First attempt:

Plaintext
attempt=1/5
reason=curl-exit-28
HTTP-000

Second attempt:

Plaintext
attempt=2/5 PASS

Final result:

Plaintext
sitemap URLs: 105/105
host mismatch: 0
HTTP failure: 0

PRODUCTION MACHINE ACCEPTANCE: PASS

This perfectly illustrates:

Smart Tiered Cache is not a magic switch for network stability.

The Internet can still experience:

Plaintext
Connection establishment timeouts
Brief packet loss
Transient node anomalies
Routing changes
Internal CDN fluctuations

Therefore, the bounded retries I implemented previously have not lost their meaning.

It’s just that they and Smart Tiered Cache solve problems at two completely different levels.

Smart Tiered Cache and bounded retry are two completely different levels of optimization

Now I am more inclined to understand them this way.

The first level:

Improving the network architecture that real users also experience.

Smart Tiered Cache:

Plaintext
Reducing the number of Edges that can actually access the origin
+
Increasing the Upper Tier HIT probability
+
Having an Upper Tier better suited for the origin handle the true origin fetch

The second level:

Allowing Production automation to tolerate unavoidable transient errors.

bounded retry:

Plaintext
Brief failure
→ Limited number of retries
→ Continue if recovered
→ Fail closed if exhausted

The former can genuinely improve the experience for website users facing a cold MISS.

The latter mainly improves the success rate of my own deployments and verifications.

The two cannot replace each other.

Why didn’t I keep increasing the timeout indefinitely?

In theory, there is another simplest solution:

Plaintext
25 seconds is not enough
→ Change to 60 seconds

5 retries are not enough
→ Change to 10

There is always a chance of success.

But I increasingly dislike this approach.

If the actual problem is:

Plaintext
CDN misconfiguration
Origin server down
Certificate error
Nginx anomaly
Release error

Waiting longer does not increase reliability.

It only delays the exposure of the real failure.

So the current principle remains:

Plaintext
bounded timeout
+
bounded retry
+
fail closed

Transient errors can be absorbed.

Deterministic errors cannot be glossed over by endlessly retrying.

Why did I ultimately neither migrate the server nor change the CDN?

In retrospect, this was actually a very typical engineering trade-off.

I had originally been considering:

Plaintext
A. Migrate the origin server to overseas zgocloud

B. Switch all non-Chinese language sites from Cloudflare back to EdgeOne

These two options were not wrong solutions.

In some cases, they might even be the ultimate solution.

But for my current project:

Migrating to an overseas origin involves too many changes, and also touches on ICP filing and access provider issues that I haven’t fully clarified;

Switching entirely back to EdgeOne means giving up the cost advantage of the current Cloudflare Free tier, and as the number of languages increases, long-term CDN costs will continue to rise.

In comparison:

Plaintext
Keep the current architecture
+
Enable Smart Tiered Cache

Hardly changed my Production baseline.

And the actual results have already significantly improved the cold MISS that troubled me the most.

So at least at this stage, there is no need for me to immediately undertake a larger architectural migration for this problem.

Why is this problem particularly easy to ignore in daily monitoring?

I think the most worthwhile thing to record this time is not just the Smart Tiered Cache toggle.

It is:

CDN makes origin server network issues very inconspicuous.

Assuming the vast majority of website requests are:

Plaintext
HIT

What is seen daily might always be:

Plaintext
HTTP 200
Very fast
Very stable

But what truly affects:

Plaintext
After a release
After a cache purge
First access to a new URL
First access to a niche resource
After natural cache expiration

is the MISS.

So now, if I want to determine whether a CDN architecture is truly stable, I won’t just test:

Plaintext
An already HIT homepage

I will also specifically observe:

Plaintext
fresh MISS

Because the two are fundamentally not testing the exact same thing.

HIT is more about testing:

Plaintext
Cloudflare Edge's ability to serve existing cache

MISS is what can truly expose:

Plaintext
The entire Cloudflare cache hierarchy
+
The path from Cloudflare to my real origin

and what happens.

Going from “two layers” to “three layers” actually made me rethink network optimization

I used to naturally think that:

Plaintext
User → Edge → Origin

is definitely more direct than:

Plaintext
User → Lower Tier → Upper Tier → Origin

and therefore should be faster.

After this experience, I increasingly feel:

That this understanding is too simplistic.

What truly matters for network performance is not:

Plaintext
How many nodes are traversed in total

but rather:

Plaintext
The quality of each path segment
Where the worst path is
Whether the worst path can be avoided entirely

If the newly added hop primarily occurs within Cloudflare’s own network, but replaces an unstable quality path like:

Plaintext
Arbitrary Edge → Alibaba Cloud Hangzhou

Then having an extra hop could very well be faster.

And if the Upper Tier already has a HIT:

Plaintext
Origin requests might even disappear entirely

This is what makes Tiered Cache truly interesting.

Finally: Lower Tier MISS does not mean the origin was definitely accessed

If I were to distill two takeaways from this troubleshooting, I would now choose:

Fast Cloudflare HIT does not mean Cloudflare origin fetches are equally stable.

And:

After enabling Tiered Cache, Lower Tier MISS no longer equals Origin MISS.

My actual process was roughly:

Plaintext
Cloudflare HIT:
Looks completely normal in daily life

cold MISS:
Once took about 21.8 seconds to succeed

Continuously increasing retries:
Improved my own Production success rate
But could not genuinely improve the website user experience

Considering migrating to an overseas origin:
Large changes, and ICP filing / access provider issues need confirmation

Considering switching entirely to EdgeOne:
Technically feasible, but higher long-term costs

Final outcome:
Continue using Cloudflare Free
Enable Smart Tiered Cache

After enabling:

Plaintext
The previously problematic Angular partial fresh MISS
→ 10/10 HTTP 200
→ Single request about 0.3～0.4 seconds

And the changes brought by Tiered Cache are not just:

Plaintext
Reducing the number of Edges that fetch directly from the origin

They also include:

Plaintext
Lower Tier MISS
→ Upper Tier HIT
→ User still sees HIT
→ Origin does not participate at all

As well as:

Plaintext
Lower Tier MISS
→ Upper Tier MISS
→ The Upper Tier selected by Smart Tiered Cache
→ Actually accesses Alibaba Cloud Hangzhou

Of course, it still won’t make the Internet forever free of failures.

In real Production, you will still occasionally see:

Plaintext
curl exit 28
→ bounded retry
→ recovered

So what I ultimately retained is a three-layer approach:

Plaintext
Smart Tiered Cache
Improves origin fetch architecture

bounded retry
Absorbs brief public network fluctuations

fail closed
Ensures real errors are not masked by automation

For my current multilingual project using “Cloudflare Free + Alibaba Cloud Hangzhou origin server in mainland China,” this has been an optimization with very minimal changes, almost unchanged costs, but very significant actual results.

系列导航

需要长期技术维护或远程问题排查？

我是拥有 15+ 年经验的 PHP / Go 后端工程师，长期关注已有系统维护、Bug 修复、性能优化、服务器排查、WordPress 网站维护和小功能迭代。

如果你的项目遇到以下情况，可以先从一次小问题排查开始合作：

  • ✅ PHP / Laravel / Yii2 老项目无人维护
  • ✅ Go / Gin 后端接口需要排查或优化
  • ✅ WordPress 网站访问慢、报错或插件冲突
  • ✅ Nginx / MySQL / Redis / Linux 服务器异常
  • ✅ CDN / Cloudflare / DNS / HTTPS 配置问题
  • ✅ 需要长期远程技术支持或兼职维护

更多介绍请查看：关于我 & 合作

微信：13980074657
邮箱：shuijingwanwq@gmail.com
Telegram：@shuijingwan
GitHub：https://github.com/shuijingwan

更多文章