Cloudflare caching issue?

Looks like someone else is experiencing a similar problem to what I’m seeing here:

Randomly it appears the cache to my homepage ( gets corrupted with a redirect to:

Following the redirect ( yields a 404.

When I enable developer mode in cloudflare and navigate to my page is served as expected. However, navigating to still yields a 404 even though my server is setup to redirect to on 404s. Note that if I prepend or postpend a character to the “z0f76a1d14fd21a8fb5fd0d03e0fdc3d3cedae52f” string it redirects to as desired… but when I use that exact string (z0f76a1d14fd21a8fb5fd0d03e0fdc3d3cedae52f) I get a 404 (with local caching disabled). When I enable “pause cloudflare on site” and navigate to it redirects to as I intend.

Seems like there’s some special behavior for z0f76a1d14fd21a8fb5fd0d03e0fdc3d3cedae52f. is this a cloudflare specific literal? I find no references to that string on my host.

My problem was resolved by rebooting the router. I guess that means it was ISP or router related.

Interesting. Pretty sure this is cloudflare related given the symptoms

Any other thoughts? Anyone from cloudflare able to comment?

This topic was automatically closed 15 days after the last reply. New replies are no longer allowed.


One of my websites had the very same problem, and after digging in a bit I found out with help from other Community MVPs that this path /z0f76a1d14fd21a8fb5fd0d03e0fdc3d3cedae52f?wsidchk=123456 is returned by a firewall service that some hosting providers are adopting In my case, it was A2 Hosting.

The Imunify360 / Webshield firewall will stand between Cloudflare edge and your origin. You can talk with your hosting provider’s support for more info on its behavior, but as far as Cloudflare is concerned, that means if you have a “cache everything” Page Rule you may need to adjust it somehow.

When Imunify360 detects a malicious activity, it intercepts the request and sends an interstitial page with a 200 HTTP status code. That page has a JavaScript redirect that points to that path, which then gets a 404 as there’s no such page on your server. The problem is that with Edge Cache TTL, the no-store directive set by the Cache Control header on the interstitial page is overridden, and that page is cached. After that, every visitor will get redirected to the 404 for as long as that interstitial page is not purged from cache.

Most users will create a Page Rule with a Cache Level: Cache Everything instruction coupled with a Edge Cache TTL. The problem is that Edge Cache TTL will override the Cache Control header set by the origin. So instead of using Edge Cache TTL, I’d suggest you try to set Browser Cache TTL: Respect Existing Headers on the Dashboard and leave the Page Rule with just Cache Everything, but not Edge Cache TTL.

Imunify360 even has a blog post about this issue;


I had contacted my hosting provider, x10hosting, which is also using Imunify360 for the same issue and according to them that was not an issue arising from the origin server. I guess they were mistaken.

1 Like

In my initial contact with A2 Hosting support, they also didn’t know much. After I opened a ticket with them, they then confirmed they were using Imunify360 on their shared hosting plans, and pointed to that blog post about Imunify360 and cache everything. In any case, this seems to be a recent addition, and they now even added a cPanel icon for Imunify360.

I had specifically mentioned Imunify360 when I contacted them, because I considered the firewall as a possible cause. They denied that the issue had anything to do with the origin server or any software they have installed on it.

They may very well be wrong though.

Searching online about the issue had given almost 0 results by the way, so probably the cause was not well known at that time.

1 Like

This topic was automatically closed 3 days after the last reply. New replies are no longer allowed.