First instinct, if it’s not working - you can disable it for the site. This is covered in the docs and toggleable under shield,enabled as well as per-site curves.
If the IP is whitelisted, there’s a separate log entry indicating it and the transactional event is preempted -
ap_log_rerror(APLOG_MARK, APLOG_DEBUG, 0, r, "page entry found for id: %s (count: %d)", id, data.meta.count);
if (++data.meta.count > config->page_count) {
ap_log_rerror(APLOG_MARK, APLOG_INFO, 0, r, "page limit (%d) exceeded for id: %s - %s", config->page_count,
id, config->canonicalize ? r->parsed_uri.path : r->uri);
if (is_whitelisted(r->useragent_addr, config)) {
ap_log_rerror(APLOG_MARK, APLOG_INFO, APR_SUCCESS, r, "Bypassing block. IP is whitelisted: %s", ip);
cache->provider->remove(cache->instance_page, r->server, (unsigned char*)id, strlen(id), r->pool);
return DECLINED;
}
apr_time_t osave = data.origin;
if (prior && prior->generation) {
// pulled earlier in block_qaccess
data.meta.generation = prior->generation;
}
char *oldid = strdup(id);
APPLY_BLOCK(cache, data, r);
data.origin = osave;
log_block_action(r, &data);
cache->provider->remove(cache->instance_page, r->server, (unsigned char *)oldid, strlen(oldid), r->pool);
free(oldid);
return config->http_reply;
That happens before blocking logic applies, which in turn gets picked up by fail2ban.
If the client is still experiencing blocking events, then likely Happy Eyeballs algo prevails and they’re blocked on both IPv4 + IPv6 while reporting IPv4. This would require whitelisting both IPv4 + IPv6 addresses.
I’d look at evaluating status code flow. 404, even if invisible trackers, flow through to dispatcher with WordPress charging more CPU time than necessary. Status codes were discussed in the initial thread.
It smells like an IPv6 problem on my end and you’re chasing the wrong symptoms.