avoid limit_req / limit_conn limits for proxy_cache cached content

[Constantine A. Murenin]

Hello,

My optimised and heavily-cached OpenGrok-based dev web site has finally
succumbed to the DDoS from the supposed AI abuse, so, I'm, reevaluating
resource usage and the applicable limits.

My objective is to serve everyone as long as there is available capacity.
Instead of doing a cat and mouse game on blocking any specific identifier,
like User-Agent or IP or netblock or region, I want to block excessive
usage IFF the content isn't already cached.

For example, the search results page on my OpenGrok may take 10ms to 50ms
to generate when the Lucene index is stored on an mfs, but once generated,
the page is basically "free" to serve, and I want keep serving the cached
entry even during what may look like a DDoS attack on my instance.
Otherwise, a Slashdot-like event could result in the most popular
combination of identifiers being promptly blocked, and legitimate users
being denied access, even when the content was actually "free" and wouldn't
have required any excessive resources to generate and serve.

I've re-looked at http://freenginx.org/r/limit_req and
http://freenginx.org/r/limit_conn, but I don't see any way to exclude
cached content from still getting subjected to the limits.

I think the standard route here may be to use an
http://freenginx.org/r/error_page exception handler, to automatically
handle the 503 errors thrown by limit_req and limit_conn, and continue
serving the content if cached, but I'm not quite certain how to integrate
it with http://freenginx.org/r/proxy_cache.  Any suggestions?

One option may be to use http://freenginx.org/r/proxy_store instead of
proxy_cache, but I'm not sure that'll work properly when I'm also caching
the search result pages, too, to account for the Slashdot-like events
(they're currently referred to as "When many people access the same link
simultaneously -- such as when a GitLab link is shared in a chat room"),
without creating new restrictions on the input for the search query string,
for example, not to mention having to do manual purges of the cached data
and missing all the other nice features of the standard proxy_cache.

Best regards,
Constantine.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://freenginx.org/pipermail/nginx/attachments/20260517/baccae0f/attachment.htm>