Firewall Rule stopped working on 7/13/21

I have one Firewall Rule that blocks requests with URI Paths that contain certain strings. Every day, I reconcile my server logs with the Firewall Events page to verify that the rule is working as expected, which it usually is.

On 7/13/21 the rule had stopped working and a flood of bad requests reached my server. When I tried to check the Firewall Events page, the events would not load. I figured it was a bug or hiccup and would resolve itself.

However, on 7/14/21 the rule is still not working, bad requests continue to hit my server. The Firewall Events page has this prompt: “No firewall events found matching your filters”

I checked the Firewall Rule and nothing has changed there.

Does anyone have any insight on what is happening here?

Thank you.

Did you double check these requests actually still go through the proxies? If they don’t, the firewall rule cannot fire either.

What’s the domain and what’s the rule?

How do I double check this?

The server logs show that the domain was called, if that’s what you mean. In other words, the requests are to, rather than or a raw ip address.

But maybe there’s something going on between my webhost and CF, and I need to contact them about it?

(I was going to PM answers to your other questions, but it looks like you have PM turned off. I don’t want to post that stuff publicly on this forum.)

I just checked my CF Overview page and the site has had ZERO traffic in the last 24 hours, so it definitely appears that traffic isn’t routing through CF for some reason.

I just verified that my domain host is pointing to the correct CF Nameservers, which makes sense because I never changed them.


(http.request.uri.path contains “.env”) or
(http.request.uri.path contains “.xsd”) or
(http.request.uri.path contains “.cgi”) or
(http.request.uri.path contains “.git”) or
(http.request.uri.path contains “.sql”) or
(http.request.uri.path contains “.asp”) or

(http.request.uri.path contains “ads.txt”) or
(http.request.uri.path contains “app-ads.txt”) or

(http.request.uri.path contains “wp”) or
(http.request.uri.path contains “wordpress”) or
(http.request.uri.path contains “php”) or
(http.request.uri.path contains “ajax”) or
(http.request.uri.path contains “ftp”) or

(http.request.uri.path contains “config”) or
(http.request.uri.path contains “settings”) or

(http.request.uri.path contains “/contact”) or
(http.request.uri.path contains “/admin”) or
(http.request.uri.path contains “/plugin”) or
(http.request.uri.path contains “/my-account”) or
(http.request.uri.path contains “/register”) or
(http.request.uri.path contains “/registration”) or
(http.request.uri.path contains “/signup”) or
(http.request.uri.path contains “/?author”)

Records are properly proxied, so you should definitely have traffic through Cloudflare. The question is just whether someone circumvents Cloudflare and connects directly to your server.

As for the page rule, yeah, it looks all right too, so any applicable request should fire it.

Which nameservers are listed in your account for that domain?


These are correct and you should have traffic listed in your dashboard. Still, if the firewall rules do not fire they will most likely connect directly.

Just for the sake of good order, you did not have the domain previously with some other provider who also used Cloudflare?

1 Like

This domain has always been with this domain host.

The website was previously on a different webhost, but that was many months ago. The CF CNAMEs were pointed at their servers. When I switched to the new webhost, I pointed CF’s CNAMEs to the new host’s servers, and the site has been running on its current webhost with no issues since then.

Does that answer your question?

Also, I just chatted with my domain host and they verified that this isn’t on their end, and I should contact CF.

The point is, often when you had the domain active with some other provider who used Cloudflare some of their configuration is still active and overrides your own, hence my question.

Can you post a screenshot of your entire firewall rule list as well as one of the rule itself?

I wonder if the And Or at the end of the last rule is a problem?


Didn’t catch that part of your question, here you go:

Looks all right as well. At this point you probably best open a support ticket and ask them to check that out. They will try to push you back to the community but that’s not anything the community can check out or fix.

IMHO something is stuck, either aforementioned previous configuration or something else, but again, only support has the proper insight here.

Just one last question, your DNS records are all proxied, right? It’s not like you configured the two addresses which are currently configured manually on :grey:? is proxied, TTL Auto
www is proxied, TTL Auto

I’m pretty sure I never configured any DNS stuff manually, just always used whatever defaults I was given.

Does that answer your question?

It does, I just wanted to double check that your records really go through Cloudflare.

In that case, pursue the path I earlier mentioned.

You can also link to this thread and point out that they need to look at it.

Thank you for your help @sandro . Much appreciated!