Flooded with 14k WordPress feed requests in under 5 mins from Cloudflare IP

I’m trying to cut down on the unnecessary bloat in the WordPress head section, so I’m experimenting by removing feeds, blocking access to xmlrpc, and similar tweaks. One of the side effects is that I’m getting massive spikes of around 14,000 requests for the various WordPress feeds (listed below). I don’t know why. I thought I fixed it yesterday, but I just noticed another wave a few hours ago.

The biggest clue that may be able to help someone understand what’s happening: The number of feed requests is almost exactly the same as the number of records in my wp_postmeta table. This can’t be a coincidence… but I don’t know how it relates.

All of these requests are from the United States (Cloudflare IP).

All requests have a cache status of “none” and a content type of “empty”.

All requests are served by Cloudflare and receive 301 (Moved Permanently) status code.

The number of redirected requests for the base / domain name suggests that these are http requests getting redirected to https. Most of the requested paths do actually exist in https (and the redirect from http is working), but some like the author feed are disabled. I did just recently switch this domain to https when I started using Cloudflare and APO. (~7 days ago)

I’m using flexible SSL mode. Caching level: standard. ‘Always use HTTPS’ + HTTPS rewrites + HSTS + TLS 1.3 enabled in Cloudflare. Opportunistic encryption disabled.

None of the requests trigger any firewall activity (but I’m sure Cloudflare whitelists its own IPs).

The top paths requested (path - requests):
/ - 2.82k
/author/admin/feed/ - 1.03k
/author/admin/ - 890
/feed/atom/ - 870
/comments/feed/ - 870
/feed/rdf/ - 860
/feed/ - 790
/feed/rss/ - 780

Cloudflare Diagnostic Center shows no related problems (I think), just these 3:
no_dnssec_found - The site does not have any DNSSEC records.
not_found_ds_record - The hostname has no DS records.
mx_does_not_exist - The domain doesn’t have an MX record.

Check cache analytics for the spiked in requests filtered by feed URL filter by HTTP method. You may find the empty cache status are for cache purges i.e. purge everything requests

1 Like

Ahhh… good idea. The requests are all PURGE (and cache status: none).

purge

I’m not manually requesting this many purges though. I think I did a ‘purge all’ one time, maybe twice, and it doesn’t line up with the spikes. Something else must be happening that causes purge requests to be sent. Maybe some kind of error reporting function in WordPress due to disabled feeds / xmlrpc?

But anyway, this purge discovery is narrowing it down, thanks. I will keep thinking about it… and anyone else, feel free to jump in. :sunglasses:

I noticed the purges as I have been working on my wordpress blog (non-APO) and hitting purge everything quite often :slight_smile:

Maybe APO is triggered to send these purge requests for some reason. I just can’t think of anything I was doing at the time that would cause it.

Do you think using flexible SSL mode could cause this? It seems to be requesting the http version of the feeds and base domain. But the redirects are working (either to https version of feed or to https base domain) and I’m not seeing the infinite redirects that are a known issue with flexible SSL. I guess full SSL mode is next on the list to setup.

How about now? I’ve had no purge requests at all in over 24 hours, or none that I can see in the same place as before (cache analytics). Have they filtered it by default?

I wouldn’t know what CF did on their end. But I do not see PURGE method in my cache analytics right now and I have been hitting purge all and purge by hostname a lot as I am setting up a new Wordpress blog

I have exactly the same problem, but request are coming from Luxembourg, and it’s hitting around 160k requests each day, for files I don’t even have/ever had installed on my Wordpress site, so exactly the same as yours:

Currently have a live support email with CF on this issue, and this was their reply this morning:

So hoping for some answers on this soonish.

Graham

Any luck tracking down an answer?

It was quiet for a while on my end but I still see these huge spikes about once per day for no reason that I can think of. I’m not that concerned with it since finding out they’re purge requests, but it would be nice to know why it’s looking for files that were never there.

I still think APO is too “automatic” and needs more adjustments.

BTW, does the ~150k spike match the number of records in your wp_postmeta table? It’s almost the same number for me, as you can see in the screenshots. It’s as if APO was trying to nuke the whole website from orbit… not just purge the cache.

It seems to be resolved as it was escalated to their tech gurus.

Basically APO purging from Luxembourg that shouldn’t of been showing up in my analytics.

The requests were not touching my host server as it was all internal CF activity.

Last few days I’ve not seen any of that behaviour, so it does seem to have been resolved.

2 Likes

It’s happening all over again, so am about to reopen my original support ticket, as it was meant to have been resolved by tech support.

Yes, still happening here. It doesn’t seem to happen as often but it’s probably best if Cloudflare just filters that out if it’s not a signal we can “use” to tell us something. (Seems to be out of our hands, so put it out of sight by default?)

This topic was automatically closed after 30 days. New replies are no longer allowed.