@revhtree - You know Software Engineering is what I do, have been for 20 years now. I couldn't help myself and researched last night based on what I can see is running the forum (Community platform by XenForo) and this is what I have found and could maybe help troubleshoot the issue and mitigate it.
What’s likely happening
1) Bot/Integrity checks + missing cookies/JS on the first hit
Many WAF/CDNs (especially Cloudflare) will do a quick “is this a browser?” check. If the first request looks “odd” (no cookies yet, privacy extensions, prefetch request, unusual headers), it can trip a block/challenge. After refresh, the browser now has the right cookies/headers and it passes.
Fixes to try
- If Cloudflare: turn off or reduce Browser Integrity Check and/or lower Bot Fight Mode sensitivity.
- Make sure you’re not blocking based on cf.client.bot, “Known Bots only”, or overly strict “Super Bot Fight Mode” settings.
2) Rate limiting or “burst” detection on the homepage
Home (/) often gets hit by:
- browser prefetch
- multiple tabs opening
- redirect chains (/ → /forums/ → /…)
- addons doing extra AJAX calls immediately
One request triggers a rate rule, then the next squeaks through because the burst window resets or the second request hits a cached route.
Fixes to try
- If you have rate limits, loosen them for normal GET traffic to / and XenForo “bootstrap” endpoints.
- Ensure rate limiting is not counting static assets + HTML together.
3) A false positive WAF rule triggered by the first request only
Example: the first request includes a query string (from the menu link, tracking params, or a redirect) like:
- /?_xfToken=...
- /?utm_source=...
- /?something= that matches a rule pattern
Refresh loads clean / without the suspicious query string, so it works.
Fixes to try
- Inspect what URL the “Home” link actually points to in the HTML (is it truly / or does it include parameters?).
- Check if any JS adds tracking params on click.
- If Cloudflare/WAF logs show a managed rule hit, add an exception for that specific rule on / (or strip/ignore the offending query params).
4) CDN edge inconsistency
Sometimes one edge node blocks due to a temporary rule/cache state, and refresh routes to a different edge that allows it. This happens more with:
- Anycast networks
- mobile carriers
- users behind large NATs
Fix
- Again: check the WAF/CDN security logs with the event ID/Ray ID.
The fastest way to pinpoint it
Next time someone gets blocked, have them grab the
bottom of the block page. If it’s Cloudflare it will show a
Ray ID.
Then you can do:
- Cloudflare Dashboard → Security → Events
- Filter by Ray ID or their IP
- It will tell you exactly: WAF Managed Rule, Rate Limit, Bot, or Custom Rule and the rule name/ID.
Without that, you’re guessing.
Practical, safe mitigations (even before you identify the exact rule)
If this is happening to legit users:
- Prefer “challenge” over “block” for suspicious traffic (Cloudflare lets you do this per rule).
- Add an exception so GET requests to / don’t get outright blocked (but keep protections on POST/login endpoints).
- Make sure your WAF isn’t blocking requests just because of common forum patterns (cookies, headers, long URLs, etc.).
One very specific XenForo angle to check
If your Home tab routes to something like “Latest posts” or an add-on landing page that makes extra background requests, the WAF may see it as “automation.” Try temporarily pointing Home to a dead-simple route like /forums/ and see if the problem drops.
