Host blocked IP due to 21,000+ requests in a 25 minute period

Further info from Siteground: It appears that, since I left the Dashboard for Burst Statistics open on a work machine overnight, it apparently was running that rash of processing requests during that time… perhaps there is something automated within your plugin’s encoding that caused that spike, and thereby got my computer’s IP address blocked for excessive activity (bordering on malicious)?

@3cstudio sorry to hear you ran into issues with Burst! Thanks for reporting the issue here.

The only thing that is recurring on the dashboard, is the “live” visitors view. It refreshes only every 5 seconds or so, so doesn’t explain the flood of requests. It sounds like an infinite loop was created somehow, but don’t know at the moment how that could happen.

I’ll see if I can reproduce it, by leaving open the dashboard for a long time, and see if something similar happens.

@3cstudio I’ve checked this, it’s not the live visitors section: that path is not /track, but /live-visitors. If I have the dashboard open, I see 2 requests each 5 seconds. This adds up to about 600 requests in 25 minutes. I’ll add a limit to that anyway, but this did not cause your issue.

As the requests did not result in any hits in the dashboard, I suspect it is the endpoint test which was somehow failing.

I can’t reproduce it yet, but what might have happened, is that the “last test time” did not update because the test itself never completed, because of a timeout. So maybe the server became a bit slow for several minutes, which caused the test to start over and over.

For this to happen

– the WordPress heartbeat probably triggered the server every x seconds.
– The test response needs to time out on the server for some reason.
– Then the last test time may not be updated, causing the test to start again when wordpress heartbeat triggers again.

I have moved the saving of the last test time to before the test, to prevent this from happening again.

I’ll do some more digging to see if I can find more on this. The above improvement will be shipped with one of the coming updates.

I’ll keep you posted if I find anything else.

@rogierlankhorst thanks so much for the update. Glad you were able to make use of my info to squash the issue. ?? We’ll keep an eye out for the Update. Thanks again.

@rogierlankhorst another issue: yesterday, Siteground issued a CPU threshold warning for this same website — it alone had caused Program Executions to average 19,000/hr (!) from 9am to 4pm yesterday (11/20). That caused an 80% quota reach (for the month!) for that entire shared server. I’m currently shutting it down because the numbers are spiking once again as I type this. Please advise. If you need to connect directly to setup a troubleshoot session, I’m available to do so — corralling some runaway process would be good for all involved? Thanks in advance.

Steve C.
3Cstudio

Here’s a sample entry from the error-log:

2024-11-12 13:07:56 UTC [apache][authz_core:error] [pid 48987] [client 35.209.107.231:12136] AH01630: client denied by server configuration: /home/customer/www/anchorpointchristian.org/public_html/wp-content/plugins/burst-statistics/endpoint.php

Another indicator to consider is Behavior > Page Views… the leader in files (BY FAR) is:

anchorpointchristian.org/wp-admin/admin-ajax.php (320018)

with the (DISTANT) second Page Views being:

anchorpointchristian.org/wp-json/burst/v1/track/ (1147)

then the homepage of the website is 3rd at (604)

HTH.

@3cstudio thanks for sharing your info. Two things I noticed:

– The call to admin-ajax.php is a strange one, as Burst does not do anything with admin-ajax.php. So this request has to originate somewhere else.

– the request to the endpoint.php is blocked by the server. My recommendation would be to unblock this, as tracking through the endpoint uses less resources, and is faster than the rest api. As the endpoint is blocked, it will fallback to the rest api.

Please note that each page visit will also trigger a separate track hit. So you will always have at least as much burst/v1/track hits as your combined pageviews of all pages.

But the above means that something else is triggering the admin-ajax.php calls. To find what is triggering them, you could add a snippet like this, to log all calls:

add_action('admin_init', function () {
    if (defined('DOING_AJAX') && DOING_AJAX) {
        error_log('Ajax call');
        error_log(print_r($_POST, true));
    }
});

This should tell us more about the requests.