IniLerm

Hi Fredpeng,
Thank you for your feedback!
I want to clarify a technical detail that might help you solve this:

1. Object Cache vs. Page Cache
   The “Redis Object Cache” plugin mainly stores database query results. It usually allows PHP to execute on every visit, so the Geo-Challenge logic (which checks for the cookie) should work fine even with Redis enabled.
   However, if the challenge is looping or failing, it is almost always due to Page Caching (which stores the full HTML and skips PHP execution).
2. Where to look
   Since you cannot find an exclusion option in the Redis plugin (because it handles objects, not pages), please check if you have:
   Another caching plugin installed: (e.g., WP Rocket, WP Fastest Cache, W3 Total Cache, Autoptimize, etc.).
   Server-Level Caching: Some hosting providers enable Nginx FastCGI Cache or Varnish by default.
3. The Solution
   Wherever your Page Cache is managed, you need to add an exclusion rule. You must configure the cache to BYPASS (not cache) the page if the following Cookie is present:
   advaipbl_js_verified
4. One last check
   Sometimes, old configuration data gets stuck in the Object Cache. Please try clicking the “Flush Cache” button in your Redis settings to ensure the plugin is reading the latest settings.
   Let me know if you find another caching layer active!
   Best regards,

Hi Moddo,
First and foremost, thank you for an absolutely outstanding bug report. Your detailed analysis, clear explanation of the execution order, and deep understanding of both our plugin and LiteSpeed’s caching mechanism were incredibly insightful. This is one of the most helpful and well-researched community contributions we have ever received.
You were 100% correct.
Your diagnosis of the premature DONOTCACHEPAGE constant definition was spot-on. We were so focused on preventing the challenge page itself from being cached that we inadvertently created a situation where any page could become uncacheable for unverified visitors, severely impacting performance for a large portion of traffic, especially legitimate crawlers.
What We Have Done:
Based directly on your feedback, we have completely refactored our caching compatibility logic in the upcoming version 8.5.12.
Removed Cache Logic from the Loader: We have removed all DONOTCACHEPAGE logic from the early loader (advaipbl-loader.php). You were right; this was the wrong place for that decision.
Conditional Definition at the Point of Action: The DONOTCACHEPAGE constant is now defined only within the serve_js_challenge() function. This means the constant is only set at the precise moment we are about to serve a dynamic challenge page, and only on that specific request.
Cacheability for All Other Pages: As a result, all other pages on the site remain fully cacheable by LiteSpeed and other page caching systems, regardless of whether the visitor has been verified by a challenge. Verified users who have the cookie will bypass the challenge and can be served cached pages, and unverified users visiting non-challenge pages can also be served cached pages.
This change not only resolves the incompatibility with LSCWP but also significantly improves the plugin’s performance footprint for all users who employ page caching.
Your contribution has been invaluable in helping us identify and fix this fundamental issue. It’s dedicated users like you that help make open-source software better for everyone. We have already integrated this fix into our development branch, and it will be a key part of our next release.
Also, thank you for your kind words about the plugin’s concept and for your work on the Czech translation. We truly appreciate your support.
Thank you again for your time, effort, and excellent work!
Best regards,
IniLerm
Developer of Advanced IP Blocker

• This reply was modified 10 months, 4 weeks ago by IniLerm.

Hi,

I’m marking this thread as resolved. Feel free to open a new topic if you have further questions.

Thanks.

Hi Jaro,

Thank you again for this follow-up. You’ve hit the nail on the head, and your points are exceptionally well-made. You’re absolutely right; a strategy that works for a small blog must be able to scale, and security plugins, in particular, must be built to withstand edge cases like DDoS attacks.

Your analysis of high-traffic scenarios is 100% correct.

• DDoS Scenario & Transients: The scenario you described (100k unique IPs generating 100k transients) is a perfect stress test, and you are right that it would put significant strain on the wp_options table. Our current Rate Limiting module is the first line of defense against this, as it’s designed to block IPs that make rapid requests before they trigger more resource-intensive operations like geolocation lookups. However, your point stands that a sufficiently distributed attack could still create this exact problem.
• Local Database vs. Real-time API: This is a classic trade-off. We initially opted for the real-time API with caching for two reasons: 1) to keep the plugin’s initial footprint extremely light (no large database download required on install), and 2) to ensure the data is always up-to-date, especially for rapidly changing ASN information. However, you are correct that for instant, high-volume decisions, a local database (like the one Wordfence uses with MaxMind GeoIP2) is the superior, enterprise-grade solution.

You’ve given us a lot to think about, and frankly, you’ve helped shape our roadmap.

Based on your feedback, we are now planning the following architectural improvements for a future major release:

1. Hybrid Geolocation Model: We will introduce an option for users to switch between the current real-time API (for ease of use and low footprint) and a local, downloadable MaxMind GeoIP2 database for high-performance sites. This will give administrators the power to choose the best strategy for their specific needs, effectively eliminating the API call bottleneck during traffic spikes.
2. Dedicated Custom Tables for Volatile Data: Your point about transients is well taken. We will migrate our geolocation cache from the wp_options table to a dedicated custom table. This will completely isolate this high-volume data from the critical options table, preventing the kind of database bloat you described. Your suggestion of using SQLite is still on our radar as a potential enhancement for this.

You’ve provided the kind of expert feedback that is rare and incredibly valuable. It’s clear you have extensive experience with high-performance environments. Thank you for pushing us to think bigger and build better.

All the best,
IniLerm

With this new version 8.5.3.1, you can remove the Trusted Signatures list (whitelist) that we proposed in the previous post. It is now included in the plugin’s native code to avoid false positives.
In future versions, this list will be updated with the fingerprints provided by providers (Google, Meta, Amazon, legitimate crawlers, etc.).
This is the method of teaching this intelligent function to detect distributed bots attacks.
Additionally, you can add any signature you think is legitimate to the whitelist.

@spectraemail

Recommended configuration:
Step 1: Settings –> Attack Signature Engine

• Signature IP Threshold: The minimum number of different IPs that must use the same attack signature to be flagged as malicious.
  Value: 10
• Analysis Window (Hours): How far back (in hours) the analysis process should look for patterns.
  Value: 1
• Signature Rule Lifetime (Hours): How long a malicious signature will remain active before it expires.
  Value: 12

Step 2: Settings –> Trusted Signatures (Whitelist)

• Manage specific request signatures that should always be allowed by the Attack Signature Engine, even if they appear malicious (e.g., legitimate crawlers, monitoring services).
  Add known legitimate signature hashes here (one per line). Requests matching these exact fingerprints will always be allowed and never logged by the Signature Engine. Use this for services like Googlebot, Facebook Crawler, etc., to prevent false positives.
• ** We are building a list of trusted signatures, you can add to the whitelist

Step 3: IP Management –> Blocked Signatures

• This table lists all attack “fingerprints” that are currently being challenged by the JavaScript verifier. These rules are generated automatically by the Signature Analysis engine and expire on their own.
• Find hashes in the “Blocked Signatures” page by clicking “View Details”. Manually signature add whitelist button

** Trusted Signatures list (google, meta, facebook, amazon, yandex, Known crawlers)

9706d557e15672071207bb8a9281929cf8ebae2effc969efaa4c02b6ecd25827
4357e810006cbcca85538dcbf2dfbedbb402d81783942c19ef2fd2bcf36cac30
831c290f9b8e5047055e08320c196a9e70555f6555a7f382b1befaae68b13059
022d8938605fb7ace7bf0b8065024ac4b7c1a1cd0a30b102b52e1294b7d72add
11e72d8146bdcbf3a53517d240284f9a1d1293573f2445f01bbbf334a211fa11
4f8ca18d80d3d9011bd62d4e3ecd2525d2df4ac020b02c2dc9f830b138b0446d
7a292aeecb714d9b6b488308dbe4e7045b4648dfee6d8d8fdbd0035ee40a9f58
96cf4186d7adc3da7338031aad4265e9c4fe60d83c02d4d0dcbfa570ad557ecf
9ce22068e218c8bee0c7c91dbd4827682f60c53dc8d20a85e2f60a2b307ad239
a02e355c79010c8c3ac7a05a209f39b68216112b729774cfe8e7f929232832a5
c08feb2c6c0d36215e6e9c30fa1e6b4705473631f6549dbec3677040606f28aa
c5364e70a5108b71ef91dbdc2914864534116b92cf368c41cd86ebead67d0af1
d05bf96e94cac639887a3492b728a953da8c26d06ab980bb0ab4194d2d945ff7
df88e81ab810ad131aeb9a2217dab49328ce84ab3fcf410118dea55058552571
eb596d705f64c69d53d48abebd43bac8d9fdf5d0d2baa5ba6fbf75b87510c8be
15c81a56f544780993d34ffd7c615640ff27e0f5bf0011675c838f7e9a18a075
58bc871b23551ec8e03c5cfd743accb5add82d0d414960e67f12a38fe73c4c32
5fa6ae3a3cc89216d8731c9be1009b6cdb08923098e0a9632d6d004e5dd90afd
c81b74779fe9a063ad540c69ba17f62208bd7f030f1bce0ac6d8037f51888420
c2d7bb6e8ffaa95be56128bbb44628bd870fb64a86259225b0ec9548b4a95e43
0af2ea30ffd71fe4ad6cb65a27dc2785efbbcedbbf5695749868920b416508b2
322e854629560b8cde97321f0ebf36a743e191343de0bc3452da60782d198ea7
c9f80e720084bba5a49d312a3575363d270fa3cd5a236bf97b23d85459c34478
f28c08c87db78fc72feed997490034a94adfa7048062213013c0f9504fc4f23a
1d3a3b731b9c7607c0d6eb0e3cd9798ee8dc42682530062ae981f795170bfcaf
06305ec342fcb037a73ca0745e33542547384618f128e3cfb1cb760a76ee4325

Hi Vineeth, @vineethmp

That’s an excellent question and a very valid feature request. Thank you for asking!

You are absolutely right that managing large IP lists like Cloudflare’s is a common need. The good news is that the plugin fully supports IP ranges in CIDR format (like 103.21.244.0/22), which makes managing services like Cloudflare much easier. Instead of adding thousands of individual IPs, you can add their official ranges directly to the Whitelist or Manual Blocklist tabs.

However, for importing a list in bulk, the most efficient method currently is via WP-CLI, which is perfect for these kinds of operations.

Here’s how you can do it:

1. Create a text file (e.g., cloudflare_ips.txt) containing the list of IP ranges, one per line. You can get the official list from Cloudflare’s website. For example:codeCode103.21.244.0/22 103.22.200.0/22 103.31.4.0/22 ...
2. Use a command to add them to the whitelist:
   From your server’s command line, in your WordPress root directory, you can run this command to add all ranges from the file to the whitelist:codeBashcat cloudflare_ips.txt | xargs -n 1 wp advaipbl whitelist add
3. To add them to the manual blocklist instead:
   You would use the block command:codeBashcat your_blocklist_file.txt | xargs -n 1 wp advaipbl block --reason="Custom Blocklist Import"

That being said, we absolutely agree that having a simple “Import from file” button directly in the IP Management > Whitelist and Blocked IPs tabs would be a fantastic usability improvement. We’ve added this to our feature roadmap for a future release, as it would make managing large lists much more accessible for everyone.

Thank you again for the great suggestion! Let us know if you have any other questions.

Best regards.