XF Bot Guard 1.4.1
- Thread starter zeeb0t
- Start date
If your XenForo ACP has upload file limits, then your best bet is to upload the add-on manually. It is fairly straight-forward.
Follow this guide: https://thestockexchange.com.au/docs/xf-bot-guard.html#section-6-1
bug report, getting a "validating browser..." for internal links within the forum. This is part of an automated PM sent to every new forum user....oddly, the 3rd link in the same PM doesn't generate the same message....
I am on the most current Bot Guard version. My settings are "cautious" with the SEO Overlay. I'm not running Cloudflare, DNS thru Constellix, private server.
As I browse thru my forum-based Admin info threads, some resolve correctly, others have "validating browser...." ....within the same post, sometimes consecutive posts. Not seeing a consistent yay/nay to why some are showing the message and others aren't.
I am on the most current Bot Guard version. My settings are "cautious" with the SEO Overlay. I'm not running Cloudflare, DNS thru Constellix, private server.
As I browse thru my forum-based Admin info threads, some resolve correctly, others have "validating browser...." ....within the same post, sometimes consecutive posts. Not seeing a consistent yay/nay to why some are showing the message and others aren't.
Last edited:
Please enable: "Enable light valid responses for selected URL unfurl user agents"
And then in "User-agent patterns for light valid responses" add another user agent at the bottom:
Code:
XenForo/2.*So, unexpected result... the DM has 3 internal links...
Initial report: Links 1 and link 2 displayed "validating browser" and link 3 unfurled as expected.
NOW....Link 1 still displays "validating browser" and links 2 and 3 unfurl as expected
I have checked a few other internal links, and some are now unfurling, and some aren't....no consistency that I can see.
Initial report: Links 1 and link 2 displayed "validating browser" and link 3 unfurled as expected.
NOW....Link 1 still displays "validating browser" and links 2 and 3 unfurl as expected
I have checked a few other internal links, and some are now unfurling, and some aren't....no consistency that I can see.
I updated from 1.2,6 to 1.2.7 about 8 hours ago. I recall copying the files over as I usually do and then going to the Add-ons admin page where I would usually do the manual update to the 1.2.7 but in this case it seemed it was already at 1.2.7. I don't recall seeing that with any other add-ons. It seemed to be working however, but all stats were at 0. I waited for a couple hours and manually ran the Bot Guard related crons but still all are 0s / unavailable. Any suggestions?
---
XF Bot Guard redacted support bundle
Generated at: 2026-06-12 23:10:14 UTC
Redaction: Sensitive values are redacted before display. Review before sending.
Environment
Configuration
"visitors_fingerprints_ips": 24,
"sessions": 24,
"counters": 24,
"dashboard_snapshots": 17520,
"zero_signal_ips": 720
}
- event_detail_write: {
"mode": "automatic",
"mode_label": "Automatic under DB pressure",
"buffer_enter_pct": 70,
"buffer_exit_pct": 50,
"buffer_min_seconds": 120,
"buffer_grace_seconds": 120,
"buffer_shard_count": 8,
"flush_max_rows": 5000,
"flush_max_seconds": 20,
"flush_rows_per_insert": 500
}
- cloudflare_edge: {
"enabled": "Yes",
"dry_run": "No",
"raw_ip_storage": "Yes"
}
Health checks
Warning/error health rows
Recent event summaries
Current page context
- source: health
---
XF Bot Guard redacted support bundle
Generated at: 2026-06-12 23:10:14 UTC
Redaction: Sensitive values are redacted before display. Review before sending.
Environment
- xenforo_version: 2.3.10
- xenforo_version_id: 2031070
- php_version: 8.3.31
- php_version_id: 80331
- xf_bot_guard_version: 1.2.7
- xf_bot_guard_version_id: 1020770
Configuration
- enabled: Yes
- observe_only: No
- scope: guests
- protected_areas: threads_forums
- selected_routes: forums, threads
- selected_content_types: forum, node, thread
- custom_paths: None
- excluded_paths: 21 configured
- threshold: 70
- logging: Yes
- low_value_logging: No
- low_value_allow_sample_rate: 0%
- retention_hours: {
"visitors_fingerprints_ips": 24,
"sessions": 24,
"counters": 24,
"dashboard_snapshots": 17520,
"zero_signal_ips": 720
}
- event_detail_write: {
"mode": "automatic",
"mode_label": "Automatic under DB pressure",
"buffer_enter_pct": 70,
"buffer_exit_pct": 50,
"buffer_min_seconds": 120,
"buffer_grace_seconds": 120,
"buffer_shard_count": 8,
"flush_max_rows": 5000,
"flush_max_seconds": 20,
"flush_rows_per_insert": 500
}
- cloudflare_edge: {
"enabled": "Yes",
"dry_run": "No",
"raw_ip_storage": "Yes"
}
Health checks
- Source: Stored/local diagnostics only. Building this bundle does not run a live Cloudflare API check.
- [ok] Add-on toggle: Enabled - Bot Guard is enabled.
- [ok] JavaScript collector: Enabled - The bundled collector is configured to load.
- [ok] CAPTCHA configuration: Cloudflare Turnstile - XenForo CAPTCHA appears configured.
- [ok] Secure random generator: Available - PHP random_bytes() is available for Bot Guard token generation.
- [ok] PAGE_CONTAINER template modification: Enabled - The collector include is available on public pages.
- [ok] Collector JavaScript asset: Present - js/zee/botguard/botguard.js
- [ok] Bundled FingerprintJS asset: Present - js/zee/botguard/fingerprintjs/fp.min.js
- [ok] DigitalPoint Cloudflare guest page caching: Disabled - DigitalPoint Cloudflare guest page caching is disabled.
- [warning] Shared full-page cache probe: Not checked - No cached shared-cache probe result is available. Run the live cache probe action to test public HTML caching.
- [ok] Cloudflare Edge Enforcement: Enabled - Local edge candidate queueing is enabled.
- [ok] Cloudflare dry run: Disabled - Cloudflare sync can write managed list changes.
- [ok] Effective Cloudflare sync mode: Live writes enabled - Cloudflare sync can write managed list changes.
- [ok] Cloudflare managed setup: Configured - Cloudflare Edge Enforcement has the required local configuration.
- [ok] Active local candidate count: 27 - Local active edge candidate aggregate count.
- [ok] Pending sync backlog size: 0 - Aggregate number of local rows waiting to be added to or removed from Cloudflare.
- [ok] Failed sync row count: 0 - Aggregate local rows with recent sync failures. Detailed diagnostics require viewBotGuardSensitive.
- [ok] Last successful sync age: 2 minutes ago - Cloudflare sync has run.
- [ok] Audit event logging: Enabled - Security audit rows can be retained.
- [ok] Low-value audit rows: Suppressed by default - Ordinary allow/skip rows are suppressed unless sampled.
- [ok] Low-value allow sample rate: 0% - Sampled low-value rows are retained only when low-value logging is disabled and this is greater than zero.
- [ok] Event detail write mode: Automatic under DB pressure - Supplementary event detail rows write directly unless cached MySQL connection pressure is active.
- [ok] DB pressure mode: Normal - Connection pressure is not active.
- [ok] Connection usage: 8.9% (38/425, running 2) - Connection usage is based on cached Threads_connected / max_connections.
- [ok] Buffer path writable: Writable - The event detail buffer path is writable: [redacted-path]
- [ok] Pending detail files: 0 / 0 B - No pending event detail buffer files.
- [ok] Processing detail files: 0 - No detail files are currently processing.
- [ok] Failed detail files: 0 / 0 B - No failed detail buffer files.
- [ok] Last detail flush: 2026-06-12 23:09:46 / 5ms - Rows inserted last flush: 0. Rows failed last flush: 0.
- [ok] Event retention: 24 hours - Raw event rows older than this are removed by the cleanup cron.
- [ok] Visitor/fingerprint-IP retention: 24 hours - Inactive visitor rows and fingerprint/IP relationship rows use the same visitor retention window. Lower values reduce long-horizon relationship memory.
- [ok] Session retention: 24 hours - Inactive session rows older than this are removed by cleanup, while unexpired trusted sessions are preserved.
- [ok] Counter retention: 24 hours - Operational counter buckets are cleaned by the normal cleanup cron after the configured raw retention window.
- [ok] Dashboard snapshot retention: 17520 hours - Compact hourly dashboard report snapshots are retained independently from raw event/session/visitor/counter data.
- [ok] Raw cleanup batching: Enabled - Cleanup deletes run in bounded batches of up to 1,000 rows, with a hard 5,000-row query limit, a 50,000-row per-table run cap, and a 20-second cleanup run budget. Partial runs resume naturally on the next cron run.
- [ok] Last cleanup run: No run recorded - A cleanup summary will be shown here after the cleanup cron has completed at least once with this version.
- [ok] Zero-signal IP pruning: Enabled / 720 hours - Only stale xf_zee_botguard_ip rows with zero risk, zero reputation, no CAPTCHA history, no fingerprint/dynamic/protected-route activity, and NULL metadata are eligible for cleanup. Reputation-bearing or challenge-history IP rows are retained.
- [warning] Physical disk reclaim: 1 table(s), 85 MB reusable reported - Tables with notable reusable InnoDB space: xf_zee_botguard_ip (4 MB reusable). Bot Guard cleanup may remove old rows, but MySQL/InnoDB may not return disk space to the operating system until affected tables are rebuilt. Run OPTIMIZE TABLE or an equivalent online rebuild during a low-traffic maintenance window only if you need to reclaim disk immediately. Run one table at a time on large installs,
- [ok] Known crawler trust: Enabled - Known crawler header trust is enabled; runtime use also requires origin lockdown acknowledgement.
- [ok] Origin lockdown acknowledgement: Acknowledged - Trusted proxy-derived known crawler, country and ASN headers may be used when their own options and validation rules allow them.
- [ok] Verified crawler IP allowlist: Enabled - Official crawler/fetcher CIDR ranges are allowed when matched locally.
- [ok] Known crawler source table: 8 rows approx / 48 KB - Approximate metadata from information_schema; no full COUNT(*) was run.
- [ok] Known crawler range table: 2,558 rows approx / 2.4 MB - Approximate metadata from information_schema; no full COUNT(*) was run.
- [warning] Known crawler sources: 8 enabled sources / 8 refreshed successfully / 2,558 ranges - One or more enabled official sources last refreshed more than 48 hours ago: Applebot
- [ok] ASN range cache table: 0 rows approx / 80 KB - Approximate metadata from information_schema; no full COUNT(*) was run.
- [ok] ASN range cache: 0 configured ASNs - No decimal ASN entries are configured in the excluded or forced challenge network lists.
- [ok] Reverse DNS hosting cache table: 19,837 rows approx / 15.3 MB - Approximate metadata from information_schema; no full COUNT(*) was run.
- [warning] Reverse DNS hosting scoring: Enabled / 19,416 cached rows / 2,856 confirmed hosting matches / 1 recent resolver errors / 0 stale pending - Recent resolver errors are present. Requests fail open, and resolver errors are cached only briefly.
- [ok] Known Bots compatibility: Known Bots stats suppressed - Known Bots is active. Because XF Bot Guard is managing online/session activity statistics, Known Bots robot statistics are suppressed so XF Bot Guard remains the final authority for online visitor/challenge accounting. This does not disable Known Bots itself, its bot-list updates, user-agent storage, or admin tools. Disable XF Bot Guard’s online count adjustment option if you do not want this be
- [ok] Event table: 2,258,782 rows approx / 1.9 GB - Approximate metadata from information_schema; no full COUNT(*) was run.
- [ok] Event detail table: 2,482,312 rows approx / 1.5 GB - Approximate metadata from information_schema; no full COUNT(*) was run.
- [ok] Counter table: 4,328,957 rows approx / 2.1 GB - Approximate metadata from information_schema; no full COUNT(*) was run.
- [ok] Dashboard snapshot table: 142 rows approx / 368 KB - Approximate metadata from information_schema; no full COUNT(*) was run.
- [ok] Dashboard snapshot metric table: 137,929 rows approx / 103.4 MB - Approximate metadata from information_schema; no full COUNT(*) was run.
- [ok] Dashboard snapshot cron: Active hourly at :10 - Snapshot cron is configured and active.
- [warning] Latest dashboard snapshot: 2026-06-08 09:00 (109h behind) - Latest dashboard snapshot is more than 2 hours behind the latest eligible completed hour.
- [ok] Dashboard snapshot backfill: No gaps detected - No missing snapshot hours were detected between the oldest and newest snapshot.
- [warning] Dashboard snapshot integrity: Review needed - 1 non-ok snapshot rows waiting for rebuild; 99 metric hours are orphaned or attached to non-reportable snapshots. The snapshot cron should repair premature rows and rebuild non-ok hours automatically; dashboard aggregation ignores non-ok, premature and stale backfill current-state rows.
- [ok] Dashboard snapshot pruning: 17520 hours - Snapshot pruning is configured separately from raw cleanup and deletes metric rows before snapshot header rows.
- [ok] Hash secret / globalSalt: Available - Hashing is available for privacy-preserving identifiers.
Warning/error health rows
- [warning] Shared full-page cache probe: Not checked - No cached shared-cache probe result is available. Run the live cache probe action to test public HTML caching.
- [warning] Physical disk reclaim: 1 table(s), 85 MB reusable reported - Tables with notable reusable InnoDB space: xf_zee_botguard_ip (4 MB reusable). Bot Guard cleanup may remove old rows, but MySQL/InnoDB may not return disk space to the operating system until affected tables are rebuilt. Run OPTIMIZE TABLE or an equivalent online rebuild during a low-traffic maintenance window only if you need to reclaim disk immediately. Run one table at a time on large installs,
- [warning] Known crawler sources: 8 enabled sources / 8 refreshed successfully / 2,558 ranges - One or more enabled official sources last refreshed more than 48 hours ago: Applebot
- [warning] Reverse DNS hosting scoring: Enabled / 19,416 cached rows / 2,856 confirmed hosting matches / 1 recent resolver errors / 0 stale pending - Recent resolver errors are present. Requests fail open, and resolver errors are cached only briefly.
- [warning] Latest dashboard snapshot: 2026-06-08 09:00 (109h behind) - Latest dashboard snapshot is more than 2 hours behind the latest eligible completed hour.
- [warning] Dashboard snapshot integrity: Review needed - 1 non-ok snapshot rows waiting for rebuild; 99 metric hours are orphaned or attached to non-reportable snapshots. The snapshot cron should repair premature rows and rebuild non-ok hours automatically; dashboard aggregation ignores non-ok, premature and stale backfill current-state rows.
Recent event summaries
- #2854963 2026-06-12 23:10:16 UTC decision=observe event_type=error_route risk=0 route=bot-guard/collect
- #2854962 2026-06-12 23:10:16 UTC decision=observe event_type=edge_export_suppressed_verified_crawler risk=0 route=bot-guard/collect
- #2854961 2026-06-12 23:10:16 UTC decision=observe event_type=collector_nonce_expired risk=0 route=bot-guard/collect
- #2854960 2026-06-12 23:10:16 UTC decision=observe event_type=error_route risk=0 route=bot-guard/collect
- #2854959 2026-06-12 23:10:16 UTC decision=observe event_type=edge_export_suppressed_verified_crawler risk=0 route=bot-guard/collect
- #2854958 2026-06-12 23:10:16 UTC decision=observe event_type=collector_nonce_reused risk=0 route=bot-guard/collect
- #2854957 2026-06-12 23:10:16 UTC decision=observe event_type=error_route risk=0 route=bot-guard/collect
- #2854956 2026-06-12 23:10:16 UTC decision=observe event_type=edge_export_suppressed_verified_crawler risk=0 route=bot-guard/collect
- #2854953 2026-06-12 23:10:16 UTC decision=observe event_type=collector_nonce_expired risk=0 route=bot-guard/collect
- #2854955 2026-06-12 23:10:15 UTC decision=observe event_type=error_route risk=0 route=threads/havent-talked-to-my-dad-in-a-long-time-totally-dysfunctional-fathers-day-thread.101020/xpoa1
Current page context
- source: health
so....the first link is internal....but the URL has changed since the Registration DM was created. It DOES auto-redirect to the correct URL, but perhaps because it's no longer correct explains the oddity.
OLD: https://domain.com/forums/announcements-testing.16/ (and what is still displaying as "validating browser....")
CURRENT: https://domain.com/forums/announcements-forum-help.16/
XF automatically handles this stuff, but the plugin is throwing a wrench into the process.
OLD: https://domain.com/forums/announcements-testing.16/ (and what is still displaying as "validating browser....")
CURRENT: https://domain.com/forums/announcements-forum-help.16/
XF automatically handles this stuff, but the plugin is throwing a wrench into the process.
So, unexpected result... the DM has 3 internal links...
Initial report: Links 1 and link 2 displayed "validating browser" and link 3 unfurled as expected.
NOW....Link 1 still displays "validating browser" and links 2 and 3 unfurl as expected
I have checked a few other internal links, and some are now unfurling, and some aren't....no consistency that I can see.
This might be a matter of cache on the XenForo unfurl system.
I would retry with different post URLs and see if it consistently works.
I'll monitor for a day/three and see if things iron out. My site registers 30+ users a day, and I regularly get replies from the auto-DM.
I also have an Admin thread where post 1 has two internal links that unfurl correctly. The first reply is ALSO an internal link, to a post later in that same thread, but displays the "validating browser..." Stay tuned
I'll monitor for a day/three and see if things iron out. My site registers 30+ users a day, and I regularly get replies from the auto-DM.
I also have an Admin thread where post 1 has two internal links that unfurl correctly. The first reply is ALSO an internal link, to a post later in that same thread, but displays the "validating browser..." Stay tuned
The results are indeed cached by XenForo, rather than wait, you could try either of:
Removes all unfurl cache:
SQL:
TRUNCATE TABLE xf_unfurl_result;Removes specific unfurl cache per domain:
SQL:
DELETE FROM xf_unfurl_result
WHERE url LIKE '%example.com%';Thanks, the bundle helps.
Good news first: I don’t see Bot Guard itself being disabled or the collector failing to load. Recent Bot Guard events are still being recorded, and Cloudflare sync is running.
What does look wrong is the dashboard snapshot/reporting layer. Your latest trusted dashboard snapshot is stuck at 2026-06-08 09:00 UTC, about 109 hours behind, and health reports one non-ok snapshot row plus orphaned/non-reportable metric hours. In 1.2.7 the dashboard uses current-format hourly snapshots, so if the snapshot cron can’t rebuild trusted rows, the dashboard can show 0 / unavailable even while the raw event log and protection path are still active.
Could you please check two things?
1. In the XenForo server error log, immediately after manually running the Bot Guard dashboard snapshot cron, look for entries starting with:
Code:
XF Bot Guard dashboard snapshot build failed:
XF Bot Guard dashboard snapshot cron failed:2. If you are comfortable running SQL, please send the output of:
SQL:
SELECT FROM_UNIXTIME(snapshot_hour) AS snapshot_hour_utc,
snapshot_version, status, message, is_backfill, is_empty,
FROM_UNIXTIME(generated_at) AS generated_at_utc,
FROM_UNIXTIME(refreshed_at) AS refreshed_at_utc
FROM xf_zee_botguard_report_snapshot
WHERE status <> 'ok'
ORDER BY snapshot_hour DESC
LIMIT 10;That should tell us why the snapshot rebuild is stuck. At this stage I’d avoid clearing any Bot Guard tables manually; the useful clue is likely in that non-ok snapshot row or the matching server error log.
Also, it is fine to try the XenForo Add-ons -> XF Bot Guard -> Rebuild action if it is available. That should re-import the add-on data and refresh XenForo’s add-on caches/cron/template/phrase state. It should not delete Bot Guard logs, counters, sessions, snapshots, or Cloudflare candidate data.
The one caveat is that Rebuild is not the same as running a missed upgrade step, so if there is an actual database/schema upgrade issue it may not repair that by itself. Still, it is safe enough to try before deeper troubleshooting, and then please re-run the Bot Guard dashboard snapshot cron and check whether the dashboard snapshot health warnings change.
Last edited:
Thanks for the suggestions.
The Bot Guard dashboard snapshot cron ran quickly but I didn't see anything in the Xenforo error log.
I did run the SQL but it returned:
Empty set (0.013 sec)
In the healthcheck I see:
Warning Latest dashboard snapshot 2026-06-08 20:00 (100h behind) Latest dashboard snapshot is more than 2 hours behind the latest eligible completed hour.
OK Dashboard snapshot backfill No gaps detected No missing snapshot hours were detected between the oldest and newest snapshot.
Warning Dashboard snapshot integrity Review needed 88 metric hours are orphaned or attached to non-reportable snapshots. The snapshot cron should repair premature rows and rebuild non-ok hours automatically; dashboard aggregation ignores non-ok, premature and stale backfill current-state rows.
Thanks, that is actually improvement, and that fits the upgrade/catch-up picture.
1.2.7 changed the dashboard snapshot format, so the dashboard is only trusting the current-format hourly snapshots. Older snapshot rows are treated as needing rebuild, and the snapshot cron is regenerating them from the retained raw event/counter/detail data.
The good sign is that it is moving: the latest trusted snapshot went from 2026-06-08 09:00 UTC to 2026-06-08 20:00 UTC, and the orphan/non-reportable metric count dropped from 99 to 88. That suggests it rebuilt about 11 hours of dashboard history in that run.
The dashboard may still look empty because recent ranges like 1h/6h/24h/48h are ahead of the newest trusted snapshot. Please try the 7-day range, or a custom range around 2026-06-08 to 2026-06-09. If data appears there, that confirms the dashboard is working and just catching up.
This is deliberately conservative: the cron only spends a bounded amount of time rebuilding snapshots per run so it does not hammer large Bot Guard tables or slow the site. If it continues at roughly 11 rebuilt hours per run, it may need around 9-10 more hourly runs to fully catch up, or fewer if you manually run the dashboard snapshot cron a few more times.
That was it, I ran the Dashboard cron several times and eventually got data in last 7 days. Now each time I run it it seems to be one hour of data added each time so should eventually catch up. Thanks!
Edit: May be an odd bug in XenForo, when I click the cron 'Run now' button it doesn't appear to do anything so I click it again and it quickly ends. If I just let it go, even though the button is still visible, it finishes a few minutes later and I see a few hours added on to the log.
Also I started getting a 500 error when attempting to view 7 day data, in the webserver error log:
Got error 'PHP message: PHP Fatal error: Allowed memory size of 268435456 bytes exhausted (tried to allocate 20480 bytes) in ... /web/src/addons/Zee/BotGuard/Repository/DashboardSnapshot/SelectionAggregationTrait.php on line 167; PHP message: PHP Fatal error: Allowed memory size of 268435456 bytes exhausted (tried to allocate 20480 bytes) in ... /src/vendor/aws/aws-sdk-php/src/Endpoint/PartitionEndpointProvider.php on line 121', referer: .... admin.php?range=48h&custom_from=&custom_to=&_xfRoute=bot-guard-dashboard%2F
Last edited:
Great, thanks. That confirms the dashboard is working and the snapshot rebuild is catching up.
The “Run now” behaviour sounds like the first click is still processing even though the button remains visible. If you click again while it is running, the second request likely exits quickly because the snapshot lock is already held. Best to click once, wait a minute, then refresh/check health.
The 500 on the 7-day view is separate. That looks like Bot Guard loading too many snapshot metric rows into memory while rendering a wider range, and PHP is hitting the 256 MB limit. For now, use shorter/custom ranges while it catches up.
I’ll treat the 7-day memory exhaustion as a dashboard aggregation issue to optimise on my side.
All looking good, the Dashboard cron has caught up and now finishes quickly. I notice the Bot Guard cleanup cron takes time to run similar to Dashboard previously so looks like it's catching up. Not too urgent. I don't see what's being cleaned up on a quick look.
Great news. re: clean ups, it is routine - it may take a while as it queries the table based on less efficient indexes like date/timestamps and so on - but it is doing it's job. There are a number of tables it keeps tamed.
Btw, I have identified a few areas that will decrease the memory footprint on dashboard - so hopefully even with large data, you can query longer date ranges without running out of memory.
