So, I thought about a shorter title, but it would have missed the mark. You’ve come to the right page if the URL path you’ve been redirected to looks like this and it seems to never go away:
https://example.com/z0f76a1d14fd21a8fb5fd0d03e0fdc3d3cedae52f?wsidchk=12345678
The Basics of the Problem
This is a tough one to explain, so just a few basics are necessary for the non-technical readers, but most looking into this will be tech savvy and can skip it.
Cache is in short, static files created of your website and stored in server memory, which speeds up the delivery of your site. See also What is caching? | How is a website cached? | Cloudflare for a simple yet detailed explanation.
TTL stands for “Time To Live” and represents the amount of time for cached data to remain valid before it should be recreated, requested again, or both. TTL for web pages is set in the page header and can cover several different points of storage, such as the Edge Server Cache or Browser Cache. These are the two types of cache that this 404 error is connected to.
For a detailed explanation of Cloudflare rules see, Technoogies.com – “The Definitive Guide For Cloudflare Free And Page Rules“
What is Edge Cache TTL
Cache Everything treats all content as static and caches all file types beyond the Cloudflare default cached content and respects cache headers from the origin web server unless Edge Cache TTL is also set in the Page Rule.
When combined with an Edge Cache TTL > 0, Cache Everything removes cookies from the origin web server response.
Here’s The Real Problem
The Imunify360 server firewall is running on your web hosting server and will intercede between Cloudflare edge servers and your origin server. When you see this bazaar URL in the address bar with the “404 Not Found” error page then you are likely using Cloudflare and have a Page Rule that has “Cache Everything” combined with “Edge Cache TTL”. It could be a false positive, but even if someone attacks your site, Imunify360 will intervene and Cloudflare will end up caching that output with the redirect causing the 404, so with the Edge Cache TTL controlled by Cloudflare and not the Imunify360 service, Cloudflare cache will not be changed for however long the Edge Cache TTL is set for.
The best explanation I found is in the Cloudflare Community by cbrandt from about a year ago, February 2022.
“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.”
So, not only is the Origin TTL header cache overridden by the Cloudflare Edge Cache TTL setting, but also the Imunify360 Edge Cache TTL header as well.
What to do?
The first thing to do is to clear cache from Cloudlflare. That should make your site accessible again. To fix the problem, not adding or setting Edge Cache TTL along with the Cache Everything option should fix it, so use Cache Everything, but remove the Edge Cache TTL part of your rule so that the Origin TTL is the default and the Imunify360 security pages TTL is not overridden by Cloudflare also.
- About the Author
- Latest Posts
- More info
Professional geek and early implementer of virtualization in 1998.
Small business owner and was once the network admin for Knight Transportation. Racquetball fanatic, but had to retire from it.
