Cloudflare caching issue?

[user96211]

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

Please wait while your request is being verified

I have 2 websites using Cloudflare. Right now both websites get stuck at a blank page with a single phrase: “Please wait while your request is being verified…” After a long time they both get redirected to a URL with the following pattern: domain.com/z0f76a1d14fd21a8fb5fd0d03e0fdc3d3cedae52f?wsidchk=[8-digit number] In place of domain.com there is of course each websites respective address. Is this a Cloudflare issue or not?

Randomly it appears the cache to my homepage (domain.com) gets corrupted with a redirect to:
domain.com/z0f76a1d14fd21a8fb5fd0d03e0fdc3d3cedae52f?wsidchk=########

Following the redirect (domain.com/z0f76a1d14fd21a8fb5fd0d03e0fdc3d3cedae52f?wsidchk=########) yields a 404.

When I enable developer mode in cloudflare and navigate to domain.com my page is served as expected. However, navigating to domain.com/z0f76a1d14fd21a8fb5fd0d03e0fdc3d3cedae52f still yields a 404 even though my server is setup to redirect to domain.com on 404s. Note that if I prepend or postpend a character to the “z0f76a1d14fd21a8fb5fd0d03e0fdc3d3cedae52f” string it redirects to domain.com 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 domain.com/z0f76a1d14fd21a8fb5fd0d03e0fdc3d3cedae52f it redirects to domain.com 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.

[CostasAthan]

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

[user96211]

Interesting. Pretty sure this is cloudflare related given the symptoms

[user96211]

Any other thoughts? Anyone from cloudflare able to comment?

[cbrandt]

@user96211

is this a Cloudflare specific literal?

No.

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;

Using Cloudflare “Cache Everything” with Imunify360

[CostasAthan]

@cbrandt

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.

[cbrandt]

@CostasAthan

I guess they were mistaken

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.

[CostasAthan]

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.