High server activity and IP blocking on WordPress Multisite

  • Resolved oraev

    (@oraev)


    1 month ago

    Hello,

    I am experiencing an issue where my hosting provider blocks my IP address when Koko Analytics is active. This happens because when multiple pages are opened, the plugin sends a high volume of tracking requests, which the server misinterprets as a DDoS or virus attack.

    I have a few questions regarding how to optimize this:

    Custom Endpoint: I suspect that creating a koko-analytics-collect.php file in the site root might help. However, I am running a WordPress Multisite (subdomain setup) where all sites share the same root directory. Do I need to create only one such file for the entire network?

    Rate Limiting: Will using the custom PHP endpoint actually reduce the “viral” nature of these requests, or will the frequency remain high enough to trigger the host’s firewall?

    Throttling & Buffering: Are there any specific settings or constants I can define to throttle the tracking requests or use a buffer to reduce the immediate load on the server when a user navigates through multiple pages quickly?

    I would appreciate any advice on how to keep the tracking active without triggering my host’s security filters.

    Best regards.

Viewing 5 replies - 1 through 5 (of 5 total)
  • Plugin Author Danny van Kooten

    (@dvankooten)

    1 month ago

    Hi @oraev,

    That is an interesting issue and the solution depends a bit on how exactly your host has implemented this rate-limiting feature. Is it one of the big hosts, e.g. WPEngine or Kinsta?

    To be able to work with pages served from cache, Koko Analytics initiates a non-cachable request for every pageview that your site receives. So the viral nature will remain and is technically necessary.

    That said, usually hosts will limit this rate-limiting to a specific URL, for example /wp-admin/admin-ajax.php (what the tracking script currently uses if not using the optimized endpoint). We could try changing this to simply use the page URL with a query argument instead. This is an easy change in the plugin, I can send you a beta version to test on Monday if you wish to help test this.

    Best,
    Danny

    Thread Starter oraev

    (@oraev)

    1 month ago

    Hi Danny,

    Thank you! I’ve just received a log from my host confirming your suspicion.

    The server firewall triggers a “http-generic-403-bf” (Brute Force) rule because of the high frequency of POST requests to:
    /wp-admin/admin-ajax.php?action=koko_analytics_collect

    Moving the tracking to the page URL with a query argument should indeed solve this, as it will bypass the strict Brute Force filters applied to admin-ajax.php.

    I’m ready to test the beta version on my Multisite setup whenever you’re ready to send it.

    Best regards,

    Plugin Author Danny van Kooten

    (@dvankooten)

    4 weeks, 1 day ago

    Hi @oraev,

    That would be awesome! Can you please give the version from the following URL a try:

    https://e.pcloud.link/publink/show?code=XZs3QGZwozx56KMwGXBnoiTyD7nohArqDtV

    You can upload it using WP Admin > Plugins > Add New or simply replace the files in /wp-content/plugins/koko-analytics with the files from the ZIP package to update to the beta version. You may have to clear any caches you’re using on your site for the change to go into effect.

    Does that version still suffer from being rate-limited by your host?

    Thank you!

    Thread Starter oraev

    (@oraev)

    4 weeks, 1 day ago

    Hi Danny,

    Great news! I’ve managed to verify the tracking after a deep cache clear.

    I checked the Network tab, and I can see that the tracking request is now being sent to the page URL (using the ping method) instead of admin-ajax.php.

    This is exactly what we were aiming for. Since the requests no longer hit the administrative endpoints, they don’t trigger the host’s “Brute Force” firewall rules. I’ve also confirmed that the stats are being recorded correctly in the dashboard for the Multisite subdomains.

    Thank you so much for your help and for providing this custom build!

    Best regards,

    Plugin Author Danny van Kooten

    (@dvankooten)

    4 weeks, 1 day ago

    That’s great news @oraev. The change will be included in the next plugin release, so you can safely update when you see the update notification show up. Thanks for helping test that out and bringing this issue to the surface!

Viewing 5 replies - 1 through 5 (of 5 total)

You must be logged in to reply to this topic.