XF Bot Guard 1.4.1
- Thread starter zeeb0t
- Start date
zeeb0t updated XF Bot Guard with a new update entry:
Release: v1.1.1
Read the rest of this update entry...
Release: v1.1.1
Read the rest of this update entry...
rDNS will be in a future release, yes. I will add to my list of things to be able to support # comments also. Both presently not supported, however.
When did you install? You probably need to give it some time - the visitors / bots need to browse around and get caught out.
Just installed (1.1.0 and now 1.1.1). Fair enough, I'll give it time
After a while, if you are still concerned - send me through a message with your config screenshot, I will take a look and perhaps recommend anything that might be better set for a forum that needs to have more aggressive settings. I can see it is ticking up, though
I had installed BotGuard 1.0.8 last night and left it running, after a few hours started getting a lot of errors in the XenForo log such as:
XF Bot Guard failed open: MySQL query error [1205]: Lock wait timeout exceeded; try restarting transaction
I tried updating to 1.1.1 but was still having issues, disabled for now. According to Claude:
Issue: Under high bot traffic, XF Bot Guard's per-request DB writes caused a lock cascade on MariaDB — blocking all site queries and spiking the InnoDB history list to 500,000+ (normal <1,000), making the site unresponsive.
Suggestion: Consider a write buffer or fail-silent mode that skips DB writes under load. For sites already using edge-level bot mitigation (e.g. Cloudflare), the per-request DB overhead may be unjustifiable during attack conditions.
XF Bot Guard failed open: MySQL query error [1205]: Lock wait timeout exceeded; try restarting transaction
I tried updating to 1.1.1 but was still having issues, disabled for now. According to Claude:
Issue: Under high bot traffic, XF Bot Guard's per-request DB writes caused a lock cascade on MariaDB — blocking all site queries and spiking the InnoDB history list to 500,000+ (normal <1,000), making the site unresponsive.
Suggestion: Consider a write buffer or fail-silent mode that skips DB writes under load. For sites already using edge-level bot mitigation (e.g. Cloudflare), the per-request DB overhead may be unjustifiable during attack conditions.
Last edited:
Thanks for the report. Is this running in default options? e.g., guest only, no low value logging, etc.
Yes I had just set it up, just with default options. I use it in conjunction with XF Surge Guard 1.0.4. A little info on my case, I see increasing number of guests in the last several months similar to other reports and mostly have the issues mitigated with CloudFlare rules but sometimes load still does increase. In the past around 400 or 500 guests are normal, I'll see times where there are regularly 3,000 to 6,000 sometimes it shoot up to 12,000.
So the work on the add-ons is appreciated as it does seem the attacks vary at different times and change. When I first installed Bot Guard, guests dropped from 2,000 to around 75, I thought all was good. Then a couple hours later it did go back up to 6,000, site was still ok but then eventually a couple hours later the database errors started.
I just checked your forum again this morning.
It still has a very large guest count, but I can also see there are very few registered members, so it may be that your forum is genuinely very human guest-heavy. That said, I don’t want to guess.
The right way to verify it is to look at the XF Bot Guard logs and check the fingerprints, scores, routes, IP/session patterns, and challenge outcomes for those guests. That should show whether they look like normal visitors, repeat automated traffic, scrapers, or something else.
If you’re comfortable, send me a private message and we can arrange either temporary admin access so I can review the Bot Guard logs directly, or you can send me screenshots/exported examples. Don’t post anything sensitive publicly.
Once I can see the actual log patterns, I’ll be able to give you a proper answer rather than guessing from the members-online count alone.
Got it... so the bots come and go, and when they come - they come in very large waves?
Under the addon listing, there's a "logs" button. I don't think it's added to the logs panel.
Try this link:
/admin.php?bot-guard-log/
Go to add-ons, find XF Bot Guard - and it will have a link to it's logs from there (at the bottom, there is a list of links). Also - please send me the output of the Health Check too. Thank you!
Right, recently that seems to be the pattern but varies, sometimes it will be at 3000 for several days and then suddenly drop to 300. I guessed that these bot farms are using AI to vary their patterns, according to Claude it's a known type:
---
It's called a HTTP flood or Layer 7 DDoS. The burst pattern you saw specifically is often called a pulse wave DDoS — coordinated bursts of traffic that spike, back off, then spike again rather than sustained high volume.
The technique:
- A botnet controller sends a signal to thousands of compromised machines simultaneously
- They all flood the target at once, overwhelming it
- When Cloudflare challenges/blocks them, they back off
- The controller waits, rotates IPs or switches to residential proxies, then surges again
The reason for the pulsed pattern rather than sustained attack is specifically to evade rate limiting and DDoS detection — sustained attacks are easier for Cloudflare to fingerprint and block automatically. Short bursts from rotating IPs are harder to distinguish from legitimate traffic spikes.
Thanks for the detailed follow-up - yes, that pattern does sound consistent with a Layer 7 / HTTP flood style event, especially if the traffic is arriving in waves rather than as a steady continuous stream. I wouldn’t want to say with certainty that AI is driving the behaviour without seeing the raw request patterns, but rotating IPs, residential proxies, challenge/back-off cycles, and pulsed bursts are all very plausible in this sort of scenario.
I have prepared a pre-release build of XF Bot Guard 1.1.2 which specifically targets the database contention issue you ran into. The goal of this change is not to weaken or bypass Bot Guard’s protection, but to make its routine identity tracking much lighter under heavy traffic. Security-critical behaviour - challenge decisions, fingerprint collection, CAPTCHA attempts, passes, failures, and trust handling - remains active, but routine request tracking has been changed so it no longer performs unnecessary per-request updates to the same database rows.
In practical terms, this should make XF Bot Guard much less likely to amplify a bot surge into a MariaDB/InnoDB lock cascade, while still allowing it to operate normally and continue protecting the forum. It will not replace Cloudflare or edge-level mitigation for a Layer 7 attack, but it should make the add-on significantly more resilient when hostile traffic still reaches PHP/MySQL.
I’ve attached the pre-release 1.1.2 build here. If you’re comfortable testing it, I’d be very interested to know whether it prevents the lock contention from reaching the point where the forum becomes unresponsive. The main things to watch would be whether the previous Lock wait timeout exceeded errors stop or reduce substantially, whether the InnoDB history list remains under control, and whether XF Bot Guard continues challenging/allowing traffic as expected during the next traffic wave.
As this is a pre-release, I’d recommend testing it at a time where you can monitor the site closely and roll back if needed. That said, the change is intentionally narrow and aimed directly at the contention pattern you reported.
P.S. I’m currently running the 1.1.2 pre-release in my own production environment as well, so your testing would be very helpful as a second real-world confirmation of the performance improvement under heavier load conditions.
Thanks for the quick and detailed response! I have downloaded 1.1.2 and will test it out in a few hours and monitor. I'll post here anything I find.
