XF Bot Guard

XF Bot Guard 1.4.1

No permission to download
  • Exception: Job XF\Job\Cron: Zee\BotGuard\Service\CronRunBudget::fromMaxSeconds(): Implicitly marking parameter $timeProvider as nullable is deprecated, the explicit nullable type must be used instead in /xxxx/src/addons/Zee/BotGuard/Service/CronRunBudget.php:69
  • src/XF/Job/Manager.php:352
  • Generado por: Cuenta desconocida
  • 16/08/2026 a las 19:39

Seguimiento​

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

Estado de la solicitud​

array(4) {
["url"] => string(8) "/job.php"
["referrer"] => string(95) "xxxxxxxxx"
["_GET"] => array(0) {
}
["_POST"] => array(0) {
}
}
 
  • Exception: Job XF\Job\Cron: Zee\BotGuard\Service\CronRunBudget::fromMaxSeconds(): Implicitly marking parameter $timeProvider as nullable is deprecated, the explicit nullable type must be used instead in /xxxx/src/addons/Zee/BotGuard/Service/CronRunBudget.php:69
  • src/XF/Job/Manager.php:352
  • Generado por: Cuenta desconocida
  • 16/08/2026 a las 19:39

Seguimiento​

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

Estado de la solicitud​

array(4) {
["url"] => string(8) "/job.php"
["referrer"] => string(95) "xxxxxxxxx"
["_GET"] => array(0) {
}
["_POST"] => array(0) {
}
}

Yes, thank you. As previously stated, there are a number of this type of issue which are identified and will be patched in the next release.
 
I noticed that with the plugin enabled, the log shows a lot of errors like this:
2026/08/19 16:55:19 [warn] 1202#1202: *31853 upstream sent duplicate header line: "Expires: 0", previous value: "Expires: 0", ignored while reading response header from upstream, client:

Is the mod trying to block caching on more than just its own pages?
 
I just installed the add-on, and the results are impressive. The user count dropped from 4,500 to around 200. Thanks! (y)


However, I did notice three issues right away:

1. Load times seem a tad slower, though it fluctuates. Most of the time, they are just as good and fast as they were before the installation. That said, I’ve only had the add-on running for an hour, so it’s far too early to complain about this.

2. In the online list, I currently only see guests labeled as "Validating Browser." Shouldn't I be able to see which page they are accessing? Or are these all bots being turned away?

3. A bigger problem: tested on an Android smartphone and the Microsoft browser - internal links (latest threads, etc.) unfortunately aren't working. "Forbidden - You don't have permission to access this resource."
--> I was able to locate and resolve the problem myself. It was related to an entry in my .htaccess file. :)

4. I have a question about the bots listed in the "Who is Online" list: is there any way to disable the display of bots, or at least configure it based on user groups? It bothers me a bit that my "Who is Online" list still spans well over 100 pages, making it look very bloated and cluttered—at least when viewing more than just the members.


Best regards,
Silmarillion
 
Last edited:
I noticed that with the plugin enabled, the log shows a lot of errors like this:


Is the mod trying to block caching on more than just its own pages?

Thanks for reporting this.

XF Bot Guard is only trying to prevent caching where it needs to: Bot Guard’s own validation endpoints and protected public HTML responses. It is not intended to broadly disable caching for unrelated assets or unprotected responses.

The nginx warning appears to be caused by the same Expires: 0 cache-safety header being sent twice on some protected responses. Because both values are identical, this should not change the actual browser/proxy behaviour, so it is not a breaking issue. That said, the warning is avoidable, and I’ll tidy this up so the cache-shield headers are applied idempotently and each header is only sent once.
 
I just installed the add-on, and the results are impressive. The user count dropped from 4,500 to around 200. Thanks! (y)


However, I did notice three issues right away:

1. Load times seem a tad slower, though it fluctuates. Most of the time, they are just as good and fast as they were before the installation. That said, I’ve only had the add-on running for an hour, so it’s far too early to complain about this.

2. In the online list, I currently only see guests labeled as "Validating Browser." Shouldn't I be able to see which page they are accessing? Or are these all bots being turned away?

3. A bigger problem: tested on an Android smartphone and the Microsoft browser - internal links (latest threads, etc.) unfortunately aren't working. "Forbidden - You don't have permission to access this resource."
--> I was able to locate and resolve the problem myself. It was related to an entry in my .htaccess file. :)

4. I have a question about the bots listed in the "Who is Online" list: is there any way to disable the display of bots, or at least configure it based on user groups? It bothers me a bit that my "Who is Online" list still spans well over 100 pages, making it look very bloated and cluttered—at least when viewing more than just the members.


Best regards,
Silmarillion

Thanks, and I’m glad the initial result is that dramatic.

On the load-time point, I’d give it a little more time before judging. During the first visits from fresh browsers, XF Bot Guard may serve a lightweight “Validating browser” interstitial before allowing the original page. That adds a short validation round trip for new/untrusted sessions, while protecting XenForo from rendering full pages for traffic that has not proven it can run a normal browser yet.

The “Validating Browser” entries in Who is Online are expected. They are visitors currently on Bot Guard’s browser-validation route, so XenForo shows that route rather than the originally requested page. They are not guaranteed to all be malicious bots; normal browsers should pass quickly and continue to the requested page, while simple automation often gets stuck there until the online timeout expires.

For the bot rows: XenForo’s Who is Online page has native tabs for Everyone, Members, Guests, and Robots. The Everyone tab includes robots by design. XF Bot Guard currently adjusts the totals and separates challenged/validating traffic into a Bots count, but it does not currently add a setting to hide robot rows from the full paginated Who is Online list or vary that by user group.

That’s good feedback. The Robots tab itself is XenForo’s native robot listing, so we probably should not bluntly hide all robots. The more useful improvement is to hide anonymous guests who are only sitting on XF Bot Guard’s own validation paths from the paginated Who is Online list. Those rows are mostly validation plumbing rather than meaningful page activity, and they can make the list look much noisier than the real human activity on the forum. I’ll look at adding an option for that while keeping the adjusted online counts and bot/challenge accounting intact.
 
Thanks, and I’m glad the initial result is that dramatic.

On the load-time point, I’d give it a little more time before judging. During the first visits from fresh browsers, XF Bot Guard may serve a lightweight “Validating browser” interstitial before allowing the original page. That adds a short validation round trip for new/untrusted sessions, while protecting XenForo from rendering full pages for traffic that has not proven it can run a normal browser yet.

The “Validating Browser” entries in Who is Online are expected. They are visitors currently on Bot Guard’s browser-validation route, so XenForo shows that route rather than the originally requested page. They are not guaranteed to all be malicious bots; normal browsers should pass quickly and continue to the requested page, while simple automation often gets stuck there until the online timeout expires.

For the bot rows: XenForo’s Who is Online page has native tabs for Everyone, Members, Guests, and Robots. The Everyone tab includes robots by design. XF Bot Guard currently adjusts the totals and separates challenged/validating traffic into a Bots count, but it does not currently add a setting to hide robot rows from the full paginated Who is Online list or vary that by user group.

That’s good feedback. The Robots tab itself is XenForo’s native robot listing, so we probably should not bluntly hide all robots. The more useful improvement is to hide anonymous guests who are only sitting on XF Bot Guard’s own validation paths from the paginated Who is Online list. Those rows are mostly validation plumbing rather than meaningful page activity, and they can make the list look much noisier than the real human activity on the forum. I’ll look at adding an option for that while keeping the adjusted online counts and bot/challenge accounting intact.

Thank you for your quick response. I would appreciate it if the issue regarding the "Who's Online" list could be addressed and a better solution found. :)

While my experience with your excellent add-on has been overwhelmingly positive so far, there is one issue I have unfortunately noticed: the rapidly increasing database load. I am using a managed server and have a limited amount of database storage available. If XF Bot Guard continues to consume database storage at such a rapid rate and in such large quantities, it will become a major problem for me. I am having this analyzed and logged by GPT.

---> ChatGPT:

One point deserves long-term attention: the database tables.

This is currently my biggest technical concern.

The counter is already at:

~488,945 rows / 218.1 MB

The event table:

~88,396 / 71.8 MB

Event details:

~83,198 / 94.6 MB

Canaries:

~28,770 / 47 MB

Best regards,
Silmarillion
 
Thank you for your quick response. I would appreciate it if the issue regarding the "Who's Online" list could be addressed and a better solution found. :)

While my experience with your excellent add-on has been overwhelmingly positive so far, there is one issue I have unfortunately noticed: the rapidly increasing database load. I am using a managed server and have a limited amount of database storage available. If XF Bot Guard continues to consume database storage at such a rapid rate and in such large quantities, it will become a major problem for me. I am having this analyzed and logged by GPT.

---> ChatGPT:

One point deserves long-term attention: the database tables.

This is currently my biggest technical concern.

The counter is already at:

~488,945 rows / 218.1 MB

The event table:

~88,396 / 71.8 MB

Event details:

~83,198 / 94.6 MB

Canaries:

~28,770 / 47 MB

Best regards,
Silmarillion

This is what Light-DB mode was created for :) check it out and let me know if you have questions.
 
This is what Light-DB mode was created for :) check it out and let me know if you have questions.
Forgive my ignorance, zeebOt. What is this "Light-DB" all about? Where can I find it, and what do I need to do, or perhaps keep in mind, regarding it?
 
Forgive my ignorance, zeebOt. What is this "Light-DB" all about? Where can I find it, and what do I need to do, or perhaps keep in mind, regarding it?

Under the XF Bot Guard menu (in ACP) click Quick settings. Then under Light-DB runtime mode, click through to attempt to enable it. It will conduct checks to see if it can. If it all checks out, you can enable it.

What it does is drastically reduce the use of DB by leveraging your XenForo enabled cacher.
 
Under the XF Bot Guard menu (in ACP) click Quick settings. Then under Light-DB runtime mode, click through to attempt to enable it. It will conduct checks to see if it can. If it all checks out, you can enable it.

What it does is drastically reduce the use of DB by leveraging your XenForo enabled cacher.
Wow, you really seem to think of everything. Amazing! I’m genuinely becoming more and more impressed. I’m going to test this out right away and provide some feedback afterwards. Thanks for this impressive add-on and your top-notch support. :)
 
You're welcome... if there is any issue, let me know :)
Thank you. I really appreciate that. :)

I’ve enabled Light DB mode now, and everything seems to be working. I’ll keep an eye on how things go over the next few days and give you some feedback.

I just noticed something in the settings: "Cloudflare Edge Enforcement dry run."

I don’t use Cloudflare, so I should probably disable that, right?
 
Thank you. I really appreciate that. :)

I’ve enabled Light DB mode now, and everything seems to be working. I’ll keep an eye on how things go over the next few days and give you some feedback.

I just noticed something in the settings: "Cloudflare Edge Enforcement dry run."

I don’t use Cloudflare, so I should probably disable that, right?

Dry run mode is enabled by default and should be left that way, until such time as you configure Cloudflare settings - so in your circumstance, that won't be happening... in other words, just leave it alone 😀

P.s. the old DB records created will stick around until eventually being pruned by the system automatically. For now, with Light-DB mode enabled, you should find the DB growth slows right down to barely anything.
 
The Robots tab itself is XenForo’s native robot listing, so we probably should not bluntly hide all robots. The more useful improvement is to hide anonymous guests who are only sitting on XF Bot Guard’s own validation paths from the paginated Who is Online list. Those rows are mostly validation plumbing rather than meaningful page activity, and they can make the list look much noisier than the real human activity on the forum. I’ll look at adding an option for that while keeping the adjusted online counts and bot/challenge accounting intact.
I'd also be in favor of hiding anonymous guests in the Who's Online list, or keeping them in a separate tab away from everything else and not even listing them under "everyone" if that's possible. Just last night we had a situation where there were a couple dozen users online and under a thousand bots, but the number of guests was fluctuating between 20k-50k, and almost all of them stuck on the browser validation page.

I like to think most users who view the Who's Online list would prefer not to see the anonymous guest rows at all, but then there's me who occasionally likes to skim through the anonymous guest IP addresses to see who's currently attacking the site.
 
I'd also be in favor of hiding anonymous guests in the Who's Online list, or keeping them in a separate tab away from everything else and not even listing them under "everyone" if that's possible. Just last night we had a situation where there were a couple dozen users online and under a thousand bots, but the number of guests was fluctuating between 20k-50k, and almost all of them stuck on the browser validation page.

I like to think most users who view the Who's Online list would prefer not to see the anonymous guest rows at all, but then there's me who occasionally likes to skim through the anonymous guest IP addresses to see who's currently attacking the site.

Nice... well the feature just completed development... 😉 you'll see it in the next version.
 
Update: The number of 'regular users' has risen significantly again. After dropping well below 1,000 immediately following the installation, the figure now fluctuates between 1,400 and 1,800. This is nowhere near the traffic levels seen prior to the AI bot invasion. Could this be linked to the fact that I enabled Light-DB yesterday?
Overall, there are currently nearly 5,000 "guests" online, including the detected bots. On balance, this actually exceeds the numbers seen before the add-on was deployed.
Nevertheless, I believe and hope that XF Bot Guard is reducing server load.

That said, server load fortunately wasn't an issue even before the add-on was installed.

Furthermore, I have noticed that the database continues to grow, even with Light-DB enabled—though the rate of growth is much more manageable. If this trend continues long-term, I will still face storage space issues down the line.

Does XF Bot Guard delete database entries that are no longer needed? If not, what is the best way for me to handle this myself?

Best regards,
Silmarillion
 
Update: The number of 'regular users' has risen significantly again. After dropping well below 1,000 immediately following the installation, the figure now fluctuates between 1,400 and 1,800. This is nowhere near the traffic levels seen prior to the AI bot invasion. Could this be linked to the fact that I enabled Light-DB yesterday?

It won't have anything to do with Light-DB mode.

Furthermore, I have noticed that the database continues to grow, even with Light-DB enabled—though the rate of growth is much more manageable. If this trend continues long-term, I will still face storage space issues down the line.

It will grow, but, at a much lower rate. Because the heaviest parts are moved into XenForo cacher.

Does XF Bot Guard delete database entries that are no longer needed? If not, what is the best way for me to handle this myself?

It will automatically prune and manage the database in accordance with the prune settings. If you wish to change them, you can do so in the advanced options. However, with the reduced rate of growth, you may just wish to leave it 'as is'.

Regarding the overall bot volumes - most forums see this fluctuating all the time... it is the nature of scraping. If you are seeing them validating browser or being challenged, then it is doing what it is meant to do. If you like, you can DM me your forum URL and I will take a look also.
 
Hello zeeb0t! :) It's me again. ;)

I have ChatGPT analyze my log files and the XF Bot Guard Support Bundle daily.

The AI gave me the following question for you today. (Overall, it's very satisfied with your addon 👍)

I'm running XF Bot Guard 1.4.1 with Light-DB runtime mode enabled. Light-DB is working very well so far and has significantly reduced DB usage. However, I've noticed that the contextual canary registry table is growing quite rapidly under our unusually heavy bot traffic. It has grown from roughly 29,000 rows / 47 MB to 98,000 / 136 MB and now to approximately 184,000 rows / 236 MB within a short period. Is this expected behaviour, and is there a specific retention/cleanup mechanism for the contextual canary registry? At what table size, if any, would you consider this something worth addressing?

Another question:

My XenForo database has a hard 15 GB limit from my hosting provider, and increasing it further is not possible. In the past the database already hit its former 5 GB limit and the forum became unavailable, so database growth is critical for me.

Light-DB is working very well and has stopped the rapid growth of the normal event/counter telemetry tables. However, the contextual canary registry has grown from roughly 29k rows / 47 MB to 98k / 136 MB and now around 184k rows / 236 MB within a few days.

What retention/cleanup policy applies specifically to the contextual canary registry? Is there a recommended setting or safe way to cap/prune this table for installations with a strict database size limit without materially reducing Bot Guard protection?

Last but not least. ;)

One additional data point which may be relevant: my hosting provider reports the total database size. Yesterday the database was at 8.83 GB of its 15 GB hard limit. Today it is already at 9.09 GB, so the total database has increased by approximately 260 MB in about one day.

Because exceeding the 15 GB limit would make the forum unavailable, I need to be fairly careful here.

Could the rapidly growing contextual canary registry account for a significant part of this increase? More importantly, does the contextual canary registry have a retention/cleanup mechanism that will eventually make its size plateau, or can it continue growing under sustained bot traffic?

Is there a safe way to reduce its retention or cap its growth without disabling contextual canaries entirely?

Best regards,
Chris
 
Last edited:
Hello zeeb0t! :) It's me again. ;)

I have ChatGPT analyze my log files and the XF Bot Guard Support Bundle daily.

The AI gave me the following question for you today. (Overall, it's very satisfied with your addon 👍)



Another question:



Last but not least. ;)



Best regards,
Chris

Hey Chris,

What retention/cleanup policy applies specifically to the contextual canary registry? Is there a recommended setting or safe way to cap/prune this table for installations with a strict database size limit without materially reducing Bot Guard protection?

In the advanced settings, there are a number of DB-related retention settings. For contextual canary, you can configure these also. Similarly, you can switch the feature off, if you like.

Essentially, to answer each of your questions which centre around the same point: there are controls you can use to reduce the data retention settings entirely. What I recommend is: give your AI the documentation file (e.g. https://yourforum.com/docs/xf-bot-guard.html) and ask it, based on your situation, what retention settings it recommends - and then, you could try those out by setting it in the advanced options.

Just make sure the suggestion "makes sense" from an operational and practical perspective. Keeping in mind, the defaults are designed to try balance DB-growth alongside persistence of detection over time.
 
Back
Top Bottom