IniLerm

Hi @wpbluefox,
Thanks for your suggestion; we will work on it for future versions.
In the meantime, we have created a short guide that might be useful for the community.

https://advaipbl.com/application-scheme-rules-priority/

• This reply was modified 2 months ago by IniLerm.

Hi @wpbluefox ,

Thank you so much for the 5-star rating! 

Hi @wpbluefox! Thanks again for sharing your experience and your feedback.

You’ve touched on a very important topic: the execution order of security layers.

The reason why Global URL Exclusions worked for your payment signal while others didn’t is entirely by design. The plugin’s execution priorities (hooked very early into the WordPress init lifecycle) are strictly managed according to advanced security standards and WordPress.org guidelines.

Every module is prioritized in a highly specific order to prevent internal conflicts, avoid breaking core WordPress functionalities, and ensure no malicious payload bypasses the firewall. For instance, Global URL Exclusions are processed at the very absolute beginning (Priority 1) because their purpose is to provide a “hard bypass” for critical external communications like payment webhooks (Stripe, PayPal, etc.) before any other security engine even wakes up. On the other hand, the WAF and Advanced Rules are evaluated slightly later in the lifecycle, once the request data has been initially parsed and sanitized.

While we are continuously researching and developing new ways to give administrators more flexibility, this strict, multi-tiered protection scenario is intentionally designed this way to keep websites bulletproof.

However, your suggestion is absolutely spot on: we need to document this better. Adding a visual “Application Scheme / Rules Priority Flowchart” to our documentation would be incredibly helpful for advanced users like you to understand exactly which layer triggers first.

I’ve added a task for our documentation team to create this flowchart. Thank you so much for bringing it up, it helps us improve the plugin for everyone!

Hi @bear2000,

Thank you so much for your exceptional 5-star review! We are incredibly honored by your words and thrilled to hear that our AS-level blocking and user interface are delivering the robust, real-world protection you need. It is incredibly rewarding for our team to see the engineering and design discipline recognized by advanced users like you.

Regarding your feature request: automatically blocking completely anonymous, unclassified IPs (no ASN, no hostname, no rDNS) is an absolutely brilliant idea. In fact, we are currently developing version 8.11.6, and we are going to prioritize adding this capability. We agree that intercepting these “ghost” IPs will significantly strengthen real-world protection.

Thank you again for your support and for helping us make Advanced IP Blocker even better! Stay tuned for the next update.

Best regards, The Advanced IP Blocker Team

Hi @cousineddie,

Thanks for the update and for keeping an eye on the logs!

What you are experiencing is a very common scenario. It’s important to differentiate between malicious traffic (which Advanced IP Blocker excels at stopping, such as brute-force attacks, vulnerability scanners, and malicious bots) and form spam.

Form spam is often submitted by human “click-farms” or sophisticated bots using clean, residential IPs that are not on any global blacklists. Because these IPs are technically “clean” and they mimic normal browsing behavior, a firewall or GeoIP blocker will naturally let them through (unless you block their specific country, as you just did with the Netherlands, which is a great move!).

To effectively stop webmail spam, you need a defense-in-depth approach. Advanced IP Blocker protects your server infrastructure, but for forms, we highly recommend adding a dedicated Anti-Spam or CAPTCHA layer directly to your contact form (like Contact Form 7, WPForms, etc.).

Here are a few quick recommendations to stop those 14 spam emails:

1. Add a CAPTCHA to your form: Integrating Cloudflare Turnstile (which is free and invisible) or Google reCAPTCHA v3 into your forms will immediately drop bot submissions without blocking legitimate users.
2. Use Akismet: If you use a compatible form plugin, Akismet is incredibly good at analyzing the content of the message and flagging it as spam before it reaches your inbox.
3. Manual Blacklisting: Since you noticed they come from the same 3-4 IPs, you can add those specific IPs directly to the Local Blacklist (ALLOW/BLOCK rules) in Advanced IP Blocker to ban them permanently.
4. Email Scraping: Please ensure your actual email address is not exposed in plain text on your website’s HTML. Sometimes bots just scrape your email and send spam directly from their own mail servers, bypassing your website’s contact form entirely!

Advanced IP Blocker is doing its job keeping your site secure from hackers, but combining it with a good CAPTCHA on your contact page will give you the ultimate peace of mind against spammers.

Let us know if you need help configuring any specific IP blocking rules!

Best regards,

AIB Team

If you have a spare moment, leaving a 5-star review would be amazing. It helps us grow and reach more people who need simple, powerful security.

👉 Rate Advanced IP Blocker here

Hi @cousineddie,

Thank you so much for providing the exact IP addresses and your configuration details. This helped us pinpoint the exact issue immediately!

We tested the IPs (195.2.84.198, 178.20.47.39, 84.54.44.19) and they are indeed correctly mapped to Russia (Moscow). The reason they bypassed the block on your site is due to API Rate Limiting.

Because you are using the Real-time API method with IP-API.com, you are subject to their free-tier limit of 45 requests per minute. When your site experiences a burst of traffic or a wave of spam bots, the API limit is quickly exhausted. Once that limit is reached, the API returns an HTTP 429 (Too Many Requests) error. When AIB cannot fetch the country data due to this error, it defaults to letting the connection through to prevent locking out legitimate visitors.

The Solution for High-Traffic / Spam Waves: We highly recommend switching your Geolocation Method from “Real-time API” to “Local Database”. This processes all IPs locally on your server—meaning zero rate limits, zero API latency, and 100% block accuracy during high-traffic spikes.

How to set it up:

1. Go to AIB Settings -> IP Detection & Geolocation.
2. Change the method to Local Database.
3. Create a free account at MaxMind to get a MaxMind License Key and paste it into the settings.
4. Wait a few minutes for the databases to download (you should see GeoLite2-City, GeoLite2-Country, and GeoLite2-ASN show as “Installed”).
5. Finally, click the “Clear Location Cache” button.

Regarding your request to only allow Australia and the US: While it is technically possible to select every other country in the blocklist to create an “Allowlist”, we strongly advise against this approach for a few critical reasons:

1. Broken Third-Party Services: Many essential services (Payment Gateways like Stripe/PayPal, Uptime Monitors, SEO crawlers, and API webhooks) route their traffic through data centers in Europe or other unexpected regions. Blocking the rest of the world will likely break these integrations.
2. Database Bloat: Blocking 200+ countries will generate an enormous amount of blocked IP records in your database, which can become resource-intensive and bloat your server over time.

The Recommended Best Practice: Instead of blocking the entire world, use Hard Blocks strictly for known high-risk countries (like Russia) where you never expect legitimate traffic. For other broadly suspicious regions, use the AIB “Geo-Challenge” feature instead. The JavaScript challenge will instantly stop automated spam bots from those countries without bloating your database with block logs, while still allowing legitimate human visitors or advanced verified services to pass through harmlessly.

Let us know how the Local Database works out for you!