IniLerm

Hi @uniqf0x,

Thank you for your feedback, and I’m really sorry to hear about the trouble you experienced with your Cloudflare setup.

When a server’s origin IP gets blocked, it usually happens because the firewall is receiving internal server requests (or loopback requests) that trigger a security rule, and the server’s IP hasn’t been explicitly excluded from the blocking engine.

To securely connect Advanced IP Blocker with Cloudflare without locking yourself out, here is the recommended configuration:

1. Whitelist your Origin IP: Go to Advanced IP Blocker > Settings > IP Management and add your server’s Origin IP (both IPv4 and IPv6) to the Whitelist. This guarantees the firewall will never push a block rule against your own server.

2. Trust Cloudflare Networks: Ensure Cloudflare IPs are properly resolved. In the settings, under Trusted Proxies, you can quickly trust all Cloudflare traffic by adding their ASNs: AS13335 AS209242

3. Auto-Whitelist Admins (For Dynamic IPs): If your personal IP changes frequently, navigate to Login & User Protection > Advanced Login Protection and enable Auto-Whitelist Admins. This ensures that as long as you can log into your WordPress dashboard, your current IP will never be blocked by the Cloudflare integration.

The Cloudflare API integration is a very powerful feature, but it does require telling the plugin which IPs are “friendly” to avoid self-blocking loops.

I hope this helps you configure it safely! If this resolves your issue, I would really appreciate it if you could reconsider your rating. If you need any further assistance setting this up, please feel free to open a thread in the support forum and I’ll gladly help you out personally.

Best regards,

Perhaps you might be interested?

https://ww.wp.xz.cn/support/topic/how-to-regain-access-if-you-are-accidentally-locked-out/

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 wweber,

To clarify how the “fragment” functionality works: the Global URL Exclusions engine performs a literal, case-insensitive substring match. It does not support regular expressions (regex) or shell wildcard (*) matching, meaning options B and C will not work as intended.

Technically, your Option A (/favicon) would match all three files because it acts as a substring. However, we strongly advise against using generic substrings like /favicon.

Here is why, along with our recommended best practices:

1. Security Risk of Broad Exclusions: Global URL Exclusions completely bypass the plugin’s firewall and security engine for any incoming request that matches the fragment. If you use a broad substring like /favicon, you might unintentionally expose other URLs or future paths that happen to contain that string, creating a significant security blind spot on your site.
2. Use Exact File Names: If you feel you must use the Global URL Exclusions for these files, we highly recommend adding the exact file names separately, one per line. For example: favicon.ico, favicon.svg, favicon-96×96.svg. This strict approach ensures that only those exact assets bypass the firewall.
3. Address the Root Cause (Highly Recommended): The most secure approach is actually to avoid using Global URL Exclusions for this issue entirely. The plugin is simply doing its job by logging that requests for these specific files are resulting in 404 (Not Found) errors. The best long-term solution is to resolve the underlying 404 errors by ensuring these favicon files actually exist in the appropriate directories on your server. Once the files are present and returning a normal 200 OK status, the 404 errors will stop, and you won’t need to intentionally weaken your firewall protections.

• This reply was modified 3 weeks, 6 days ago by IniLerm.

Hello @wweber,

Don’t worry, what you are seeing is completely normal behavior and not an attack on your site.

Modern browsers (especially Safari on Apple devices like iPhones, iPads, and Macs) are programmed to automatically look for favicon.ico and variations of apple-touch-icon.png in the root directory of any website they visit in the background, regardless of the HTML tags you have inserted.

If you have already uploaded the files but are still seeing 404 errors, it is very likely due to:

1. Server or CDN Caching: Your server, caching plugin, or CDN (like Cloudflare) might still be serving a cached 404 response for those URLs.
2. Filename Variations: Apple devices often request specific sizes or names (e.g., apple-touch-icon-152x152.png or apple-touch-icon-precomposed.png). If you only uploaded the standard one, it will still trigger 404s for the others.

The Solution: Since these are completely harmless requests and pose zero security risk, the best and easiest way to stop them from flooding your security logs (and prevent them from triggering the plugin’s 404 blocking rules) is to exclude them.

Please go to your WordPress dashboard:

1. Navigate to Security > Settings > General.
2. Find the Global URL Exclusions text area.
3. Add the following lines (one per line): favicon.ico apple-touch-icon

Save the settings. From now on, Advanced IP Blocker will simply ignore these benign background requests and they will no longer clutter your logs or trigger any 404 blocks.

Let me know if this helps!

Hello,

First and critically important: Please edit your comment and remove the .htaccess content. It is highly unsafe to share your .htaccess on a public forum because it exposes your server’s internal absolute paths (like {edited}.../private_html/), which can be exploited by attackers.

Regarding Global URL Exclusions: We strongly advise against excluding your homepage. The homepage is the primary target for 95% of automated attacks and DDoS bots. Excluding it means turning off the firewall at your front door, making your site totally vulnerable.

Looking closely at your .htaccess, we’ve solved the mystery: Our Advanced IP Blocker rules are nowhere to be found in your file (there is no # BEGIN Advanced IP Blocker). You currently only have rules from All In One WP Security (AIOS). It seems you may have confused our plugin’s settings with AIOS, or our setting was never successfully activated on your end.

If you wish to properly enable our Server-Level Firewall and bypass this Edge CDN caching issue: 1. Go to Advanced IP Blocker Settings and enable the .htaccess feature. 2. Crucial Step: Because your ‘FASTCACHE’ uses aggressive [L] (Last) flags that intercept requests, you MUST copy our # BEGIN Advanced IP Blocker ... # END block and paste it at the VERY TOP of your .htaccess file, directly above the # BEGIN HTACCESS PAGE CACHING line. This guarantees our firewall evaluates the malicious bots before the cache steps in.

Tip: Before making any changes to the .htaccess file, make a backup copy of the file.

Thank you!

• This reply was modified 1 month ago by IniLerm.
• This reply was modified 1 month ago by Yui. Reason: homepath removed

Hi again,

Thank you for providing the specific URL (eugenioruberto.it) where the issue uniquely occurs. After analyzing the console behavior and the homepage architecture, we’ve pinpointed the exact chain of events.

Your homepage is executing multiple async requests (Pop-ups, Webpushr, Complianz) combined with an underlying Cloudflare/Turnstile verification platform (the console is flooded with challenges.cloudflare.com 401 Unauthorized HTTP errors).

Here is the exact issue: When a malicious bot attacks your homepage and our firewall properly intercepts it (serving a 403 HTTP status and our Block Screen HTML), your Edge CDN/Fastcache platform acts aggressively to shield your server. It intercepts that 403 response intended only for the bot and locally caches the HTML block screen across its CDN layer to absorb the attack. Consequently, when you try to access the homepage 1 minute later, the Edge CDN incorrectly broadcasts that cached block screen fragment back to you, totally bypassing WordPress (which is why our plugin never logs your IP—we didn’t block you; the CDN served you a cached photograph of a previous block).

Since your Edge caching configuration acts strictly on the frontend structure of this specific site, we highly recommend you use our Server-Level .htaccess Firewall Engine feature.

How to solve it: Go to Advanced IP Blocker > Settings > Server-Level Firewall (.htaccess) and enable it. By pushing the blocks directly to your server’s .htaccess layer, malicious IPs are severed purely at the Apache network level before WordPress loads. This completely prevents your Edge CDN from ever receiving the visual PHP-rendered block screen to mistakenly cache it, silently neutralizing the bots without poisoning your Fastcache.

Important: This answer is an assumption based on the data we have so far to try to solve this problem that only affects one site with a complex configuration.

• This reply was modified 1 month, 1 week ago by IniLerm.

I’m sincerely sorry you decided to disable the plugin.
The problem is most likely an incompatibility with the caching plugin you’re using on this site (Fastcache by Host.it), which probably has an advanced configuration for this unusual situation.

Carefully read the documentation for that caching plugin; they specifically mention incompatibility with other caching plugins if they run simultaneously (e.g., Cloudflare, wpfastestcache, wpRocket …. etc) and the specific TTL that applies to multiple pages (homepage). https://it.ww.wp.xz.cn/plugins/fastcache-by-host-it/

A CDN typically doesn’t use just one IP address.

A CDN (Content Delivery Network) is a group of geographically distributed servers that work together to deliver web content quickly.

Since you’re using the HOST.it CDN, and if you want to run one last test, you can add the ASN of the host.it CDN, which covers all its IP addresses, to IP Detection -> Trusted Proxies.

Host SPA ASN:

AS47242

With a bit of luck, maybe this will solve the problem, although I still think it’s a problem with the cache plugin.

• This reply was modified 1 month, 1 week ago by IniLerm.