I've been trying out Bot Guard on
our forum for the past week or so with pretty standard settings and things seemed to be working fine, but then everything went to hell last night. For the past week we had been running Bot Guard 1.1.5 and it was only displaying about 50-100 guests online. I'm sure there were more than that as at minimum we're used to seeing at least 1000 guests online, and the past few days page loads started to get noticeably slower at certain times throughout the day. Last night it was so bad that I shut the board down and upgraded to Bot Guard 1.2.7, then about 20 minutes later we were seeing this:
View attachment 339829
This number of bots isn't new for us. We've been getting slammed with numbers this high every so often ever since the new Star Wars movie premiered about a month ago. However, with Bot Guard and Surge Guard running, the server was completely overwhelmed. Page loads were taking 30+ seconds with constant timeouts and 500 errors. When I tried disabling these two add-ons, pages started loading closer to normal again despite the bot traffic. This leads me to believe that the massive amount of logging is what slowed everything down. Am I correct? How would we go about fixing this? The amount of settings and data this add-on provides is pretty overwhelming so I'm not sure where to start.
Not using Cloudflare or IP Thread Manager. We're on a VPS running PHP8.3 / MySQL8.0 / NGINX 1.28. We're using the NGINX bot blocker and Fail2ban jails as the first line of defense.
EDIT: I don't mean to sound like I'm blaming this add-on for my problems. This is great software and I'm thankful to zee for creating it. I'm just hoping there's something we can do to make it work for us.
No worries at all. I don’t read this as blaming the add-on. This is exactly the kind of real-world pressure case where the limits between server-level blocking and application-level handling become very obvious.
At that volume, the first line of defence really does need to be NGINX, Fail2ban, or another edge/server-level blocker. If tens of thousands of bot sessions are suddenly reaching PHP/XenForo, Bot Guard can help classify, challenge, and reduce some bad traffic, but it cannot make that amount of application-layer traffic cheap.
So yes, the extra logging/detail writes may have contributed to the slowdown, especially during a storm like that. But the bigger issue is that the huge volume of bot traffic was suddenly reaching the application layer at all. Disabling Bot Guard and Surge Guard reduced the amount of work being done per request, which is why the site felt better, but it doesn’t mean the traffic became safe or cheap.
The immediate blunt Bot Guard settings I’d try are:
Log low-value allow/skip audit events
Code:
zeeBotGuardLogLowValueEvents = Off
Low-value allow audit sample rate
Code:
zeeBotGuardLogAllowSampleRate = 0
Log browser validation allow events
Code:
zeeBotGuardLogBrowserValidationAllows = Off
Tracked browser validation bootstraps per 10 minutes
Code:
zeeBotGuardBootstrapRequestsPer10Min = 0
Event detail write handling
Code:
zeeBotGuardEventDetailWriteMode = Buffered
That keeps the lower-value/supplementary logging down without fully removing the minimum level of audit/context that Bot Guard relies on to track suspicious behaviour across page loads.
The last option only buffers supplementary event detail, not every Bot Guard database write, but it can reduce some synchronous DB work during heavy traffic. After enabling it, keep an eye on the event detail buffer health/status so failed or stale files do not start building up.
For longer-term recurring waves, I’d also review the raw retention settings. The goal is to keep enough recent evidence for Bot Guard to make useful decisions, without retaining storm-volume data for weeks when the site is repeatedly under pressure.
The broad recommendation would be: keep raw event, counter, and session data shorter during recurring waves; keep compact dashboard snapshots longer; and avoid verbose logging unless you are actively diagnosing something.
Settings I’d review:
Event retention hours
Code:
zeeBotGuardEventRetentionHours
I’d suggest somewhere around
72 to
168 hours during recurring waves.
Visitor retention hours
Code:
zeeBotGuardVisitorRetentionHours
If possible, I’d keep this longer than event logs, for example
168 to
336 hours, because it affects longer-term visitor reputation/state.
Session retention hours
Code:
zeeBotGuardSessionRetentionHours
I’d suggest around
72 to
168 hours.
Counter retention hours
Code:
zeeBotGuardCounterRetentionHours
I’d suggest around
72 to
168 hours. Counters are used for operational reporting and recent scoring/rate signals, so I would not set this extremely low unless database pressure is severe.
Dashboard snapshot retention hours
Code:
zeeBotGuardDashboardSnapshotRetentionHours
This can usually stay longer, because snapshots are compact compared with raw rows.
Zero-signal IP retention hours
Code:
zeeBotGuardIpZeroSignalRetentionHours
This only applies to stale IP rows with no useful signal. Lowering it can help prune low-value state, but the minimum is higher than the raw log settings.
Beyond that, if the server still cannot weather that kind of traffic without Cloudflare or another edge layer, the realistic option inside Bot Guard would be something intentionally blunt: when guest/bot pressure crosses a configured threshold, start returning early
429 or
503 responses to guests before doing the heavier XenForo/Bot Guard work.
That could be based on guest count, Bot Guard counters, server load, response timing, or DB pressure.
The trade-off is that it would hurt real human guests too. But, to be fair, if the alternative is the site being down or unusable for everyone, then “temporarily and intelligently unavailable for visitors we do not know yet” may be a reasonable compromise. In that scenario, the priority is protecting the people the site already trusts - members, known-good visitors, and established sessions - so the forum can keep running for them instead of PHP/MySQL falling over completely.
So I do think there is probably a useful feature in there, as long as it is framed honestly. It would be an origin survival mode, not a clean bot-detection feature.
I’m actually interested in what you and other users think of that as a possible fallback feature.
Something like:
- disabled by default
- guest-only / excludes known and accepted bots / unknown-visitor focused
- configurable thresholds
- returns early
429 or 503 once the site is under extreme pressure
- protects members and already-trusted visitors and bots first
- intended purely as a “keep the origin alive” mode, not as normal bot detection
It would not replace proper edge/server-level mitigation, but it could give smaller VPS-hosted forums a last-resort survival option during bot floods.
