Using 444

[Paul]

On 9/27/25 03:08, Maxim Dounin wrote:
> Hello!

Maxim, many thanks.  Currently battling a DDoS including out of control 
"AI". Front end nginx/1.18.0 (Ubuntu) easily handles volume (CPU usage 
rarely above 1%) but proxied apache2 often runs up to 98% across 12 
cores (complex cgi needs 20-40 ms per response.)

I'm attempting to mitigate.  Your advice appreciated. I've "snipped" 
below for readability:

[snip]
>> I am currently (a bit "hit and miss") using :
>>
>> proxy_buffering on;     # maybe helps proxied apache2 ?
> 
> Proxy buffering is on by default (see
> http://freenginx.org/r/proxy_buffering), so there is no need to
> switch it on unless you've switched it off at previous
> configuration levels.

Understood, thanks -- I had two lines (rem'd in or out for testing 
purposes) trying to respect genuine requests from regular users.  Given 
that nginx has a lot of spare capacity, could this be better tuned to 
alleviate the load on the back end?  I've read your doc, but in a 
production environment, I'm unsure of the implications of "proxy_buffers 
number size;" and "proxy_busy_buffers_size size;"
> 
>> connection_pool_size 512;
>> client_header_buffer_size 512;
>> large_client_header_buffers 4 512;
> 
> Similarly, I would rather use the default values unless you
> understand why you want to change these.

Maybe mistakenly, I was trying to eliminate stupidly artificial cgi 
requests -- "GET /cgi-bin/....." that ran several kilobytes long.  The 
backend apache could "swallow" them (normally a 404) but I was trying to 
eliminate the overhead.

> 
>> location ~ \.php$ {  return 444; }

You did not mention this, but it does not appear to work well. 
access.log today gives hundreds of:

104.46.211.169 - - [27/Sep/2025:12:32:12 +0000] "GET /zhidagen.php 
HTTP/1.1" 404 5013 "-" "-"

and the 5013 bytes is our "404-solr-try-again" page, not the 444 expected.

>> if ($http_user_agent = "") {  return 444; }
/.../
>> Note the "-" which doesn't get a 444,
/.../
> But if you really want to, there two basic options:/.../

Thanks. This was a previous suggestion on this list -- many/most 
malicious actors don't give a $http_user_agent -- I'll play with it....
> 
> Also, depending on the traffic pattern you are seeing, it might be
> a good idea to configure limit_req / limit_conn with appropriate
> limits.

Again thanks, I had tried various 'location' lines such as
	limit_req_zone $binary_remote_addr zone=mylimit:5m rate=1r/s;
	limit_req zone=mylimit burst=5 nodelay;

without success... obviously haven't fully understood

Truly appreciate your assistance,
tnx and br
Paul


> 


   \\\||//
    (@ @)
ooO_(_)_Ooo__________________________________
|______|_____|_____|_____|_____|_____|_____|_____|
|___|____|_____|_____|_____|_____|_____|_____|____|
|_____|_____| mailto:paul at stormy.ca _|____|____|