404 not found, openresty, wsidchk, Imunify360, and Cloudflare redirect error.

404 not found, openresty, wsidchk, Imunify360, and Cloudflare redirect error


( Share the Noogies )

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.

(Visited 1,542 times, 10 visits today)

( Share the Noogies )

About The Author

Leave a Review

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

Disclaimer

Technoogies.com has made every effort to ensure that the information provided is correct but is not advice. Technoogies will not accept any responsibility or liability for any errors or omissions. Technoogies Authors do not vouch for third party sites. Visit third party sites at your own risk. Technoogies is not directly partnered with any vendor or third party. This website uses cookies only for analytics and basic website functions. Technoogies does not accept any liability that might arise from accessing the data presented on this site. Links to internal pages promotes the content of Technoogies. This article does not constitute legal advice.

Disclosure of Affiliations

Technoogies.com is affiliated with Google, Amazon, and other advertisers. Running this site costs money and if it can’t sustain itself through ad's, it’ll go bye-bye. Please help me to keep that from happening with your patronage of ads that are of interest to you.

Scroll to Top