XF Bot Guard

XF Bot Guard 1.4.1

No permission to download
Overview FAQ Updates (41) Reviews (20) History Discussion
I completely understand your conclusion that Bot Guard is not generating the HTTP 429 responses itself.

However, I think we both agree on one important observation:

Almost all HTTP 429 responses on my entire origin logs are isolated to /bot-guard/collect.

So regardless of where the 429 originates, bypassing the collector for verified search engine crawlers would prevent them from ever reaching the component that is generating the 429.

From my perspective that would be an excellent practical solution, even if the underlying rate limiter exists elsewhere.

Thanks for your DM and kind support all time.
 
fionix said:
I completely understand your conclusion that Bot Guard is not generating the HTTP 429 responses itself.

However, I think we both agree on one important observation:

Almost all HTTP 429 responses on my entire origin logs are isolated to /bot-guard/collect.

So regardless of where the 429 originates, bypassing the collector for verified search engine crawlers would prevent them from ever reaching the component that is generating the 429.

From my perspective that would be an excellent practical solution, even if the underlying rate limiter exists elsewhere.

Thanks for your DM and kind support all time.
Click to expand...

Yes, this is something I am already considering and it's on the backlog. I am currently testing the next release version, but may fast-forward a change to exclude the collector for verified search crawlers in the next release. I do not currently have a firm ETA, but expect sometime in the next few weeks.
 
I miss some South-American countries and also in the country list is Singapore missing.

The last month my forum was plagued by countless annoying bots from Singapore!
That went so far that my forum was even severely slowed down.
 
fionix said:
Almost all HTTP 429 responses on my entire origin logs are isolated to /bot-guard/collect.

So regardless of where the 429 originates, bypassing the collector for verified search engine crawlers would prevent them from ever reaching the component that is generating the 429.
Click to expand...

fionix said:
From my perspective that would be an excellent practical solution, even if the underlying rate limiter exists elsewhere.
Click to expand...
While it would possibly be a pragmatic solution (and may be useful anyway) for your issue it is basically avoiding to see the symptoms of an issue your setup clearly has (and that might hit you again in other areas, even in areas where you don't see the symptoms as easily). So it would possibly be worth digging through your setup nevertheless to find out what causes these error codes - it does seem somewhat strange that these seem to change and only do so for the Google crawler.

fionix said:
Did you check GWT and HOST STATUS as well as the error messages there ? or don't you use Google Webmaster Tools?
Click to expand...

zeeb0t said:
fionix provided the additional log analysis I requested. The important finding is that his origin logs show 0 HTTP 5XX responses for /bot-guard/collect.

They do show a large number of HTTP 429 responses. Google can treat repeated 429 responses as an overload/rate-limit signal, similar to 5XX/503 responses for crawl-rate and host-availability purposes, so those responses are absolutely worth investigating.

However:

This does not appear to be a Bot Guard collector response.

The Bot Guard collector endpoint does not intentionally return HTTP 429. Valid collector submissions return 200, invalid collector submissions generally return 400, direct wrong-method requests return 405, and the rare hash-unavailable failure path would return 503 (of which there were none).

So the next question is where those 429 responses are being generated: XenForo Cloud, the web-server/proxy layer, Cloudflare, Precursor/Bot Management/rate limiting, or some other platform rule.

Given that this has not been reported on non-XenForo Cloud installs, and my own Search Console does not show the issue, this currently looks like an environment/platform-specific interaction rather than Bot Guard itself returning server errors.
Click to expand...
Isn't it interesting how we have become Google slaves? Google does weird things, acts completely intransparently, created a load of tools that primarily serve Google and we are in fear how Google "might" interpret failure codes wrongly - and jump through loops to avoid that and to make the life as easy as possible for Google while at the same time Google does not give a damn and makes our life complicated and expects us to comply with whatever it demands to stay visible. I think it is really time to get rid of "Google-fear" (which has become quite pathologic).

As this issue only seems to happen for Google one could assume that it is caused by Google as well (however this happens), so they are the ones that should work on their systems to get rid of issues.
 
Abraham54 said:
I miss some South-American countries and also in the country list is Singapore missing.

The last month my forum was plagued by countless annoying bots from Singapore!
That went so far that my forum was even severely slowed down.
Click to expand...
Waves come and go and they seem to change targets regularly. While some see massive waves atm it has been very calm for me lately. Don't be sad, they will come back sooner or later. ;)
 
I have just caught up with the current stream of inbox and forum replies... I think! I hope! If I missed you, let me know. I may need to think about a ticket system as the add-on grows in popularity. p.s., it's great to see users are really starting to customise the settings and experience Bot Guard delivers. Keep going! :)
 
zeeb0t updated XF Bot Guard with a new update entry:

Minor Release: v1.4.1

XF Bot Guard 1.4.1

Important upgrade notes for existing customers:

When XF Bot Guard is enabled, XenForo ACP one-click upgrades now check the live XF Bot Guard support declaration before the XenForo upgrade download begins. If the target XenForo version is above the currently declared supported version, or the declaration cannot be checked or parsed, the form shows a warning and requires explicit confirmation. Manual file-upload upgrades and CLI upgrades are not gated...
Click to expand...

Read the rest of this update entry...
 
What's coming next in 1.4.2? XF Bot Guard Pro! 🚀

XF Bot Guard Pro is an upcoming optional paid layer for administrators who want to take XF Bot Guard further on larger, busier, or more heavily targeted communities.

The core XF Bot Guard add-on remains the same product customers already use. Pro is not about taking existing protection away. It is about adding advanced capabilities that need deeper compatibility work, more specialised tuning, or managed intelligence.

XF Bot Guard Pro is currently in development and testing for XF Bot Guard 1.4.2, with three Pro features expected to be released together.

XenForo native guest page-cache compatibility

Guest page caching can be excellent for performance, but bot protection makes it tricky. Each request may need fresh browser validation, challenge state, crawler handling, runtime output, or a safe fallback.

XF Bot Guard Pro’s native guest page-cache compatibility is designed to work safely with XenForo’s own internal guest page cache. Where a request can confidently be served from XenForo’s native guest cache, XF Bot Guard can allow that. Where the request needs protection logic that must run live, it falls back to the normal protected request flow.

The goal is simple: help eligible guest pages stay fast without weakening the protection model.

Route pressure score multiplier

Not all abuse hits a forum evenly. Sometimes the pressure is concentrated on a specific area, such as registration, login, contact forms, or another protected route.

The route pressure score multiplier is designed to detect when challenged traffic on a protected route is performing badly, such as when very few visitors are successfully passing CAPTCHA. When that happens, XF Bot Guard Pro can increase the effective risk score for that route.

This gives the add-on a way to respond more strongly to targeted abuse without making the entire forum harsher for everyone. The feature is designed to be bounded and configurable, so administrators stay in control.

Managed community bot intelligence feed

The third Pro feature in development is a managed community intelligence feed for detected bot fingerprints and abusive IP/network indicators.
XF Bot Guard installations can help build a wider picture of automated abuse patterns. Pro installations can then benefit from that managed intelligence, recognising known hostile fingerprints and network activity earlier instead of having to learn every pattern from scratch on each individual forum.

That matters for both protection and performance. The more confidently XF Bot Guard can identify known bad traffic early, the less work a forum has to spend on repeated checks, challenges, and uncertainty.

This feature will have its own proper announcement with more detail before release, including how the feed is managed, what data is used, and how privacy and security are handled.

More soon

All three XF Bot Guard Pro features are being developed and tested for XF Bot Guard 1.4.2.

More details will be shared as XF Bot Guard Pro gets closer to release.
 
Have there been any changes to the recommended settings in the past few updates? We've been under a bot attack the past few days and since the upgrade to 1.4.1 our guest and bot numbers seem suspiciously low while page loads are extremely slow.
 
Apt Irrelevance said:
Have there been any changes to the recommended settings in the past few updates? We've been under a bot attack the past few days and since the upgrade to 1.4.1 our guest and bot numbers seem suspiciously low while page loads are extremely slow.
Click to expand...

Please send me the support bundle by DM and I'll take a look if there is anything off.
 
@zeeb0t

Yet again, awesome work. About time i made a contribution!!

All I need now is VPN blocking and i can ditch a number of other apps and just use this one! (unless ive missed something!) :D

Seriously though - Thank you for all the hard work you have put into this.
Looking forward with interest to 1.4.2!
 
Paul said:
@zeeb0t

Yet again, awesome work. About time i made a contribution!!

All I need now is VPN blocking and i can ditch a number of other apps and just use this one! (unless ive missed something!) :D

Seriously though - Thank you for all the hard work you have put into this.
Looking forward with interest to 1.4.2!
Click to expand...

Thank you! Appreciate it very much! Also, if you'd like to leave a review (if you haven't already) that would be great... same goes for anyone else reading along. Thanks again! https://xenforo.com/community/resources/xf-bot-guard.10508/rate
 
New error. I'm not using Cloudflare:

  • Exception: Job XF\Job\Cron: Zee\BotGuard\Repository\CloudflareConfig::tokenDecryptable(): Implicitly marking parameter $config as nullable is deprecated, the explicit nullable type must be used instead in /XXXX/src/addons/Zee/BotGuard/Repository/CloudflareConfig.php:150
  • src/XF/Job/Manager.php:352
  • Generado por: XXXX
  • 12/08/2026 a las 20:04

Seguimiento​

#0 [internal function]: XF\Job\Manager->handleShutdown()
#1 {main}

Estado de la solicitud​

array(4) {
["url"] => string(8) "/job.php"
["referrer"] => string(122) "XXXXXXX/"
["_GET"] => array(0) {
}
["_POST"] => array(0) {
}
}
 
PhineasD said:
Exception: Job XF\Job\Cron: Zee\BotGuard\Repository\CloudflareConfig::tokenDecryptable(): Implicitly marking parameter $config as nullable is deprecated, the explicit nullable type must be used instead in /XXXX/src/addons/Zee/BotGuard/Repository/CloudflareConfig.php:150
Click to expand...
@zeeb0t I've been using these two regex's to locate this sort of php 8.4 compatibility issue;
Code: 
\bfunction\b[^();]*\(([^),]*,)?\s*(?!mixed|null|\?)[\w\\]+(\s*\|\s*((?!null)[\w\\]+))*\s+(&\s*)?\$\w+\s*=\s*null\b
function.*\([^\?\)]+\s*[\w]+\s*(&\s*)?\$[\w]+\s*=\s*null.*?\)

They target slightly different syntax variations, and I never did get around to merging the two of them as it isn't like I need to run these often.
 
PhineasD said:
New error. I'm not using Cloudflare
Click to expand...

Thank you for the bug report. This will be resolved in the next release.

Xon said:
I've been using these two regex's to locate this sort of php 8.4 compatibility issue
Click to expand...

Thanks for that! With your suggestion, and some manual scanning, there are a few other areas that will be resolved in the next release for PHP 8.4
 
NickH said:
Has anybody had any issues with redis guest page caching not working when this is enforcing?
Click to expand...

Guest page cache is unsupported / should be switched off whilst Bot Guard is running. The add-on will disable XenForo guest page cache itself, to make sure it doesn't break the install.

There is an upoming release which makes guest page cache possible again. But for now, this is basically expected behaviour.
 
You must log in or register to reply here.

Similar threads

zeeb0t
Gauging interest: optional paid bot access using x402 / Bot Guard
Replies
15
Views
270
akok
akok
Back
Top Bottom