IniLerm

Hi @mayecreate,

I just checked IP address 198.153.xx.x. (Last malicious connection: 2026-04-17 00:10:49), we have manually removed it from our global database again.

Please note that it may take a few hours for the updated list to automatically sync across all external websites using the plugin. The global database is automatically updated every six hours since the last update at each site.

Best Regrads,

Advanced IP Blocker Team

After reviewing your security via Tawk, we’ve confirmed you have multiple layers of security. This is good, but it’s important to understand the differences between them.

1- Host.it: First-level CDN and Cache. We recommend configuring it correctly to avoid interfering with the rules at the next levels.

2- Htaccess: Excellent server-level protection.

3- Advanced IP Blocker: Application-level protection against malicious attacks.

This is a correct and robust configuration.

ej. host.it blocked home for ip:

HOST.IT

HTTP 403Access Blocked

Your request has been blocked by the security system protecting this website. This can happen if your request appeared suspicious, originated from a network flagged as risky, or triggered a protection rule.

Client IP 77.111.246.44

Timestamp2026-04-17 10:48:09

Think this is a mistake? Take a screenshot of this page — including IP and timestamp — and send it to the website owner or technical support for troubleshooting.

This request will never reach the security logs because it is blocked by your hosting/CDN before it reaches the application (WordPress).

Fantastic news! I’m glad clearing the cache sorted it out. Aggressive page caching can sometimes ‘freeze’ a legitimate firewall block screen and accidentally show it to everyone.

Regarding your question about the CDN IP (81.31.157.10): Yes, you are 100% correct! Adding that IP to the ‘Trusted Proxies’ list is exactly what you should do.

Because your host routes traffic through their CDN, all visitors technically arrive at your WordPress server originating from that specific IP (81.31.157.10). By adding it to the Trusted Proxies list, you are telling our firewall: ‘I trust this specific CDN IP. When you see it, please look at the HTTP headers to find the REAL visitor’s IP address beneath it.’

Doing this prevents the firewall from accidentally blocking your entire host’s CDN if it gets attacked, and ensures that the logging and blocking features target the actual attackers accurately instead of mixing real visitors up with the CDN server.

Excellent intuition! You have configured it perfectly. If everything looks good and you are happy with the plugin, a quick 5-star review would mean the world to us. Don’t hesitate to reach out if you need any more help

Hi there, and thanks for reaching out!

That is indeed a curious behavior. Advanced IP Blocker is designed to protect your site globally. When a block happens exclusively on the homepage (/) while letting traffic pass through deeper directory links, it almost always points to a caching interference or a very specific custom rule.

Let’s solve this. Please follow these steps in order:

1. Whitelist your IP: Go to Security -> Dashboard -> System Status and click ‘Add to Whitelist’ next to your IP. This ensures the firewall doesn’t accidentally pick you up as a false positive while testing.

2. Clear All Caches (Crucial): If one of our security pages was accidentally cached by a caching plugin (like Fastcache by Host.it, LiteSpeed, WP Rocket, or your server’s Varnish cache) while stopping a bot, that cached blocked page will be served to everyone. Please purge all your website caches entirely.

3. Check Advanced Rules: Did you recently create any custom rules under the Advanced Rules tab? If a rule uses a URI modifier pointing exclusively to /, it might be isolating your homepage. Try disabling your custom rules temporarily.

4. Check the Security Logs: This will give us the definitive answer. Go to Security -> Security Logs and filter by “Blocked” or this IP address 77.111.246.56 that we have just used for testing. Look for the entry specifically targeting your homepage. The log will exactly state the “Reason” (e.g., WAF, GeoBlock, Threat Score, Admin Rule).

Could you clear your cache first, and if it still fails, tell me what “Reason” appears in your Security Logs for those homepage blocks?

I’ll be happy to guide you further!

• This reply was modified 5 months ago by IniLerm.
• This reply was modified 5 months ago by IniLerm.

Hello @mayecreate,

I have just reviewed the IP 198.153.xx.x. Since it only had a total of 10 (login_lockdown, aib_network – Last Seen 2026-04-13 16:35:13) threat points on record, we have already manually removed it from our Global Database for you.

Please note that it may take a few hours for the updated list to automatically sync across all external websites using the plugin. If you manage the website where you were originally blocked, you can force an immediate sync from your WordPress admin panel by temporarily disabling and re-enabling the Community Network feature.

Best regards,

AIB Support 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

• This reply was modified 5 months ago by IniLerm.

Hi @wweber,

Thank you for reaching out and for participating in the AIB Community Defense network!

What you are describing is actually the expected and correct behavior of the system. Let me explain how it works under the hood so you can understand what those logs mean:

1. Regarding the missing “Trigger details” for AIB Community Blocks: When you enable Community Blocking, your site downloads a constantly updated list of over 110,000 strictly verified malicious IPs. When one of those IPs tries to visit your site, the plugin pre-emptively blocks it at the gateway. Because the IP is blocked instantly—before it can interact with your WordPress installation, drop a payload, or scan for vulnerabilities—there are no local trigger details to show.

The “trigger” in this case is simply: The IP is globally recognized as dangerous because of attacks it performed on other sites across our network. Your site benefits from that shared intelligence, so it drops the connection without needing to gather new evidence.

2. Regarding the preceding 403 Error on /: Malicious scripts rarely send just one request at a time; they usually perform concurrent, multi-threaded burst attacks. If a bot blasts your site with multiple requests in the exact same millisecond, the system processes them simultaneously. One thread might log as a standard 403 Forbidden (meaning the request to the root / was rejected globally by WordPress or your server configuration), while the parallel threads are immediately caught by the downloaded Threat List and logged as an AIB Community Block.

In short: seeing an AIB Community Block with no local payload details means the firewall is doing exactly what it was designed to do—stopping known attackers dead in their tracks before they can even try anything on your specific site.

I hope this clarifies how the Community Defense network operates! Let us know if you have any other questions.

Hello @theboina,

Thank you for reaching out!

To give you some context on how the AIB Community Defense Network works: the system is designed to be self-healing. Any IP address added to the global blocklist is automatically removed after 5 consecutive days of zero malicious activity reported across our network.

If you ever need an IP removed immediately, the correct procedure is exactly what you just did: opening a support ticket so we can review it. When we receive a removal request, our team manually analyzes the IP’s threat score and its recent reported activity. If the total threat score is below 100 points, we consider it a low risk or a potential false positive and proceed to delete it from our Global Database.

I have just reviewed the IP 5.159.138.232. Since it only had a total of 5 threat points on record, we have already manually removed it from our Global Database for you.

Please note that it may take a few hours for the updated list to automatically sync across all external websites using the plugin. If you manage the website where you were originally blocked, you can force an immediate sync from your WordPress admin panel by temporarily disabling and re-enabling the Community Network feature.

Let us know if you have any other questions.

Best regards,

AIB Support Team

Hello @secretuser777,

Thank you for your patience and for confirming the 403 HTTP error from your logs.

We have conducted a deep investigation and traced your request through our infrastructure. Here is what is happening:

1. Your Web Server’s IP (62.109.31.252) is 100% clean and explicitly allowed on our firewalls. This is why 24 of your websites successfully registered without any issues. 2. When yandex-blog.ru attempts to register, it passes cleanly through our Cloudflare edge network. However, our internal Data Center (Origin Server) firewall is immediately rejecting the connection with a 403 Forbidden error before our WordPress API can even process it.

Since the IP is definitely allowed, the server-level firewall is almost certainly reacting to the specific payload sent (the domain string yandex-blog.ru). Strict datacenter firewalls (like ModSecurity) sometimes have globally enforced rules that drop POST requests containing certain keywords (like “yandex”) to block spoofed bot traffic.

But do not worry, I have some excellent news for you: Even without the V3 API Key, your website is STILL receiving the AIB Community Defense list! The plugin is designed with a smart fallback mechanism: if it fails to connect to the secure V3 API, it automatically downgrades and downloads the public V2 Community List feed. Therefore, your yandex-blog.ru website is fully protected right now, despite the registration 403 error.

There is no need to reinstall or change your server configurations. You can safely leave it as it is while we investigate checking our origin server’s ModSecurity logs to see if we can manually whitelist that keyword bypass for your specific domain in the future.

Please let me know if you have any other questions. We are glad to hear all your other 24 sites are perfectly synced!

Best regards, AIB Support Team

• This reply was modified 5 months, 3 weeks ago by IniLerm.