IniLerm

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.

Hello @secretuser777,

Thank you very much for providing the server IP and the extra context! That actually clears up the mystery entirely. 🕵️‍♂️

Since you’ve successfully registered 24 other websites hosted on the exact same server IP (62.109.31.252), you hit our Central Network’s anti-spam Rate Limiting firewall.

To protect our API against mass bots and DoS attacks, our firewall temporarily blocks any IP address that makes more than 20 connection requests (such as API key generations, telemetry, or network syncs) within a few seconds. Since all 25 of your WordPress sites share the exact same outbound server IP, registering them back-to-back quickly triggered this temporary security block exactly on your last domains.

The good news is that this is incredibly easy to fix. The block is purely temporary and clears itself automatically.

To get the key for yandex-blog.ru: 1. Please wait for about 5 minutes without pressing the button to let the rate limit counters reset on our firewall. 2. Click “Free API Key” again, and it will generate instantly.

Let me know if you can successfully get it now! Thanks for using Advanced IP Blocker to protect your network of sites.

Best regards,

Advanced IP Blocker Team

Hi @ljfent,

Yes, absolutely!

Since you had to remove the plugin directory manually via FTP/File Manager previously, the standard WordPress uninstallation process (which cleans up the database) didn’t have a chance to run.

You have two safe ways to completely remove all remaining data without affecting the integrity of your WordPress database in any way:

Option 1: The Easy Way (via the Plugin)

1. Reinstall and activate the latest version of Advanced IP Blocker.
2. Go to Security > Settings > Uninstallation.
3. Check the box for “Delete Data on Uninstall” and click Save.
4. Go to your WordPress Plugins page.
5. Deactivate and then Delete the plugin normally.
   This will automatically and safely erase all tables, settings, and cache files.

Option 2: The Advanced Way (via phpMyAdmin)
If you prefer to do it manually, you can safely drop (delete) all tables that start with your database prefix followed by advaipbl_.
These tables are completely isolated and only used by our plugin:

• wp_advaipbl_logs
• wp_advaipbl_notifications_queue
• wp_advaipbl_ip_scores
• wp_advaipbl_request_log
• wp_advaipbl_malicious_signatures
• wp_advaipbl_cache
• wp_advaipbl_blocked_ips
• wp_advaipbl_endpoint_lockdowns
• wp_advaipbl_community_ips (if you used v8.6.3+)
• etc ….

(Note: Replace wp_ with your actual database prefix if it’s different).

You can also safely delete the advaipbl_settings row from your wp_options table.

Either method is perfectly safe for your site. Let me know if you need any further assistance!

Best regards,

Advanced IP Blocker Team

Hi @sabotoro,

That is fantastic news! I am so glad to hear the “ghost logs” are finally gone. 🎉

I want to sincerely thank you for your patience and for sticking with us through the troubleshooting process. Your detailed feedback and testing were absolutely crucial in helping us identify and fix this unique edge-case. Because of your reports, the plugin is now more stable and accurate for everyone.

If you have a moment, and feel that the support you received was helpful, we would be incredibly grateful if you could leave a quick 5-star review for the plugin. It helps our free project grow immensely.

👉 Rate Advanced IP Blocker here

I am marking this topic as Resolved, but please feel free to open a new one if you ever need assistance again.

Best regards,

The Advanced IP Blocker Team

Hello again @sabotoro,

Thank you so much for your extensive testing and for providing all these details. The fact that the errors continue exactly every 15 minutes—even with cron-job.org paused and /wp-cron.php fully excluded—is an incredibly valuable clue.

We have been analyzing this behavior deeply with our development team, and we have a strong working hypothesis about what might be happening on your server.

Our Hypothesis: The Server-Level CLI Cron We strongly suspect that there is a scheduled task (a cron job) running directly on your server’s operating system (via CLI / Command Line Interface) exactly every 15 minutes.

Because this task executes directly on the server and not through a standard web browser:

1. It has no IP address.
2. It has no User-Agent.
3. It has no Request URL (URI).

During the execution of this background task, something in your WordPress environment (perhaps another security plugin, a theme function, or a core restriction) is failing and returning an internal 403 Forbidden status.

Why is Advanced IP Blocker logging it? Our plugin actively monitors WordPress for any outgoing 403 HTTP status headers to catch attackers. Because this CLI request has a completely empty URL, it bypasses the /wp-cron.php exclusion rule you set up. Advanced IP Blocker is simply observing the 403 error generated by your system and dutifully logging it: “A 403 error occurred”, resulting in those confusing, completely blank log entries.

What we are doing for v8.9.6: While our plugin isn’t the one blocking the request, it shouldn’t be logging internal server CLI errors as external attacks. We are preparing a patch for our upcoming version 8.9.6 that will explicitly instruct the plugin’s error listener to completely ignore any processes running via CLI or lacking a valid Request URL.

If our hypothesis is correct, installing v8.9.6 will instantly silence these “ghost” logs from your security dashboard.

What you can do in the meantime: Since something is still throwing a 403 error every 15 minutes, we highly encourage you to investigate your server’s scheduled tasks. Check your cPanel/Plesk “Cron Jobs” section, or ask your hosting provider if there is a server-level script running every 15 minutes that might be failing or lacking permissions. Identifying that script will solve the root cause of the 403 error itself.

Thank you again for your patience and for helping us uncover such a unique edge-case. We will let you know as soon as v8.9.6 is officially released!

Best regards, The Advanced IP Blocker Team

Hi @sabotoro,

This is turning into quite the mystery! The fact that the User-Agent fix didn’t work and the IP is still showing up empty tells us something very important: The problem is happening before our plugin’s logic can even read the request properly.

If an IP is in our Whitelist, it gets a 100% free pass. If it’s still being blocked, and the Security Log shows an empty IP/User-Agent, it means the request is likely being mangled or blocked by a layer above our plugin.

Let’s do a definitive test to isolate the issue.

Step 1: The Global Exclusion Test
We need to tell the plugin to completely ignore wp-cron.php.

1. Go to Security > Settings > General Settings.
2. Find the “Global URL Exclusions” text box.
3. Ensure that /wp-cron.php is on its own line in that box.
4. Click Save.

What this does: This completely turns off Advanced IP Blocker for the cron file. If cron-job.org is still getting a 403 error after this, we know with 100% certainty that our plugin is not doing the blocking.

Step 2: Check Server-Level Firewalls
If Step 1 doesn’t fix it, the block is happening at the server level.

1. Do you use Cloudflare? Check your Cloudflare WAF events. A “Bot Fight Mode” rule might be blocking cron-job.org.
2. Hosting ModSecurity: Many hosts (like Hostinger, SiteGround, cPanel) have a built-in firewall called ModSecurity. It often blocks external cron services because they look like automated bots. You may need to ask your hosting provider to whitelist the IP 128.140.8.200 in their server firewall.

Please apply the Global URL Exclusion for /wp-cron.php and let me know if the 403 errors stop in your cron-job.org dashboard!

Best regards,

Advanced IP Blocker Team

Hello again @sabotoro,

One quick follow-up tip that might save you some time digging through server logs!

Before you reach out to your hosting support, you can actually use our plugin’s built-in Cron Diagnostics to confirm if this 15-minute ping is indeed a scheduled task:

Simply go to Security > Logs > Cron Logs (or navigate to wp-admin/admin.php?page=advaipbl_settings_page&tab=logs&sub-tab=cron_logs).

Check if there are any Cron Events executing at the exact same time as your 403 errors (e.g., 10:45:02, 10:30:02). If the timestamps match perfectly, you have 100% confirmation that these are automated maintenance tasks. Sometimes, these logs can also help you identify the specific hook or external IP triggering the cron, making it much easier to whitelist!

Let us know what you find.

Best regards!

Geolocation .> Geo-Security -> Maxmind Local Database