Purging cache. Many times.
Waiting for a week. Then purging cache.
What are the steps to reproduce the issue?
Ever since our website overhaul 2 weeks ago, Cloudflare REFUSES to update its cache.
It serves stale cache which breaks the website.
You can easily tell by looking at the website features and the layout (they’re all in the old arrangement and not working).
The steps to reproduce this issue are to simply open the website.
It doesn’t work.
When Cloudflare cache is purged or development mode is enabled, it temporarily works right.
Please do not gaslight us by suggesting to look at server cache. It’s clearly Cloudflare’s side. We’ve been malding for days and trying everything.
Is there a way to make sure Cloudflare makes new cache?
Or are we cursed with ancient cache forever?
When Cloudflare cache is purged or development mode is enabled, it temporarily works right.
It does NOT happen with Cloudflare developer mode enabled.
Purging the cache also temporarily fixes it, but Cloudflare serves stale cache instead of making a new one.
I’m looking at the front page, and the “Crafts” section is blank. Which resource (specific .js/.css/html) is responsible for that content?
Based on your description of the behavior, your site is dynamically generating resources, which then quickly end up out of sync because it’s cached at Cloudflare beyond its usefulness.
It also looks like you have at least one cache rule. What Edge Cache TTL(s) are you setting for your content?
In checking my browser’s DevTools, I’m seeing what looks like Cloudflare WAF activity. widget-login.css returns a 403 block by the WAF. That should show up in your Firewall Events Log.
I’m seeing other responses from challenges.cloudflare.com.
At one point, I saw a main.js redirect to what looked like a firewall challenge.
I suggest you:
Review your firewall settings and firewall events log. Some settings may be over-sensitive.
Yes, for some reason it reverts to OLD stale cache.
From what we know, cloudflare is supposed to make a new cache after it’s purged, but that’s not happening in our case.
We were wondering if we can get cf to create new cache by force.
We’ll disable relevant WAF rules to see if this continues to happen.
For some reason, a lot of bots like attacking our website.
Purge Everything should force a refresh of everything. If you look in your browser’s Dev Tools, you’ll see cf-cache-status and the age header. Age header should show you how long that resource has been in Cloudflare cache.
Just to eliminate other possibilities, please make sure Tiered Caching and Cache Reserve are disabled. That will help isolate where the cached responses are coming from, and ensure that the Age header for a HIT is completely accurate.
You didn’t mention which specific resources (URLs of .js/.css/etc) are stale. That’s the most important part to look into for what’s causing the site to break.
“New users can only embed 1 media per post” error isn’t allowing us to post everything.
So we just broke the embeds. We hope you can view them still in a preview mode of the message.
You can easily tell it’s stale by this arrangement of buttons in the homepage: (3 buttons equally spaced)
image|689x287](upload://hVyGajXNB9QbT3cEntrkgWIe0j3.jpeg)
So for a simple case we can look at where the css for that is coming from, right?
image|465x111](upload://o6tSEXPWZgzPPjyd89jLRAZyU3B.png)
image|411x282](upload://2qDNKRCLJhHWvCHNlEcpSh65G4Z.png)
To comment on what is seen, some insanely long-named UCSS is used (which is disabled in litespeed and has been for a week now).
Now for the fresh version of the buttons (achieved after Cloudflare purge): (all 3 buttons collected in the center)
image|690x284](upload://2She7IfDmBEAlJLR98dymi30s7e.jpeg)
image|517x127](upload://rJlCCpaaW4iHt7auNiywzVvOHzs.png)
image|316x500](upload://eQHQImnXb7CXBd6rmu30Cj6hM4o.png)
To comment on what is seen, frontend.min.css?ver=3.28.4 is applied.
Proof UCSS has long been disabled in Litespeed cache.
image|690x224](upload://33RhqZlhaIchKciMQS6sIv8I62f.png)
It looks like you’ve set cache to bypass, so I can’t take at look at the frontend.min.css?ver=3.28.4 you mentioned.
When I reload, the site is hanging, so I can’t double-check some observations, but I see it’s trying to load content from Litespeed cache. At one time, I used to use Litespeed’s options to combine JS and CSS, and all their other optimizations, but I did have a lot of trouble using that and Cloudflare cache at the same time. I’ve since disabled those optimizations in Litespeed.
It also looks like you have Email Obfuscation enabled. I’m not a fan of that, since it’s just one more thing to load, /may/ cause issues in HTML due to the rewrites, and I almost never expose an email address on my sites.
I will have to say that I’m 99.99999% sure that after you purge Cloudflare cache, that content is gone forever. I think your site frequently regenerates some resources, which quickly go out of sync, and Cloudflare Edge Cache TTL is too high to refresh those changes.
Also, be super sure you don’t have “Ignore Query Strings” in any of your cache settings.
It looks like you’re still making changes. There are some issues with the .js and .css your site is attempting to reference. The HTML is a MISS, so that’s coming from your server. But it’s referencing some .js and .css that are returning 404s:
The BYPASSes may be due to cookies returned from your server. (Edit: or maybe I had browser set to bypass cache, or the response had no-cache in the cache-control header. On the upside, a BYPASS should ensure fresh content.)
I do not know. I don’t think I ever encountered that specific behavior. That only happened if I cached the HTML at Cloudflare for too long, and the referenced .js/.css no longer existed in Cloudflare cache.
My main recommendation for now is to disable all of Litespeed’s JS and CSS optimization. That caused me nothing but trouble when I was caching the full site at Cloudflare, and it was too much trouble to try to find a way to coordinate all of Litespeed’s optimization and cache settings with Cloudflare’s cache settings.
I don’t even let Litespeed cache my HTML. It’s such a small hit to have those occasional requests come through Cloudflare to update HTML cache when it expired. I set a low default TTL in my first Cache Rule, and a high TTL for js/css/images in my second Cache Rule.
Trying with a new browser’s incognito mode and a VPN, I myself don’t see 404s.
The website also seems to be functioning. This issue is driving me insane.
It’s been 4 hours and the issue has not returned.
It usually appears after an hour or so… then we’ll assume it’s solved for now…
To those who may stumble upon this post one day, the way we fixed was by:
1- Loosening WAF: Allowing a little more access to php files, allowing some more known bots, disallowing less of the abnormal user agents.
2- Disabling css/js/html minifcation in OpenLiteSpeed settings.
3- Disabling Email Address Obfuscation & Hotlink Protection
