Quote Originally Posted by marcopolo View Post
If it had been a session rate limiting block, that would show up as a permanent Deny from <IP> entry in the .htaccess under the AbuseIPDB section. Since you don’t see their IP there, it wasn’t SRL.

You can see exactly what the customer would have seen by using the plugin’s Test Mode—that forces the “Access Denied” message regardless of score.

Another possibility is that the customer was on a VPN or mobile network where IPs tend to rotate. Those often carry higher AbuseIPDB scores and can be blocked even if you’re not using country flood.

To be sure, I’d recommend turning on logging in the plugin. That way you can look up their IP and see whether it was caught by:

Score block (exceeded your confidence threshold)

Octet flood (2- or 3-octet prefix got busy during the scrape)

Or if it was just your host’s server-level range ban

A couple other good practices from the README:

Whitelist trusted customer IPs if needed.

Keep an eye on the Who’s Online shields—they’ll show if it was score, blacklist, flood, or country that triggered.

Remember the Score-Safe rule: even if a flood threshold is hit, an IP still needs to meet the minimum score before blocking occurs. That helps avoid catching bursts of legit traffic like newsletters or sales.

If you’re not sure which feature bit, the log files are your best friend (abuseipdb_blocked_*, abuseipdb_session_blocks.log, etc.).

And yes—all of this is outlined in the README, so it’s worth a quick re-read whenever you’re tracking down one of these cases.
Thanks so much for your reply! I just checked the customer account today, and it seems it is a different IP login than it was yesterday. They said not on VPN, so must be a mobile network. Both were BT. I didn't realise VPN would be high score rated sometimes. I guess some VPNs are more questionable than others. Perhaps I could increase threshold score from 41.