limit-req and greedy UAs

Richard Stanway r1ch+nginx at teamliquid.net
Mon Sep 12 21:39:38 UTC 2016


limit_req works with multiple connections, it is usually configured per IP
using $binary_remote_addr. See
http://nginx.org/en/docs/http/ngx_http_limit_req_module.html#limit_req_zone
- you can use variables to set the key to whatever you like.

limit_req generally helps protect eg your backend against request floods
from a single IP and any amount of connections. limit_conn protects against
excessive connections tying up resources on the webserver itself.

On Mon, Sep 12, 2016 at 10:23 PM, Grant <emailgrant at gmail.com> wrote:

> > ‎https://www.nginx.com/blog/tuning-nginx/
> >
> > ‎I have far more faith in this write up regarding tuning than the
> anti-ddos, though both have similarities.
> >
> > My interpretation is the user bandwidth is connections times rate. But
> you can't limit the connection to one because (again my interpretation)
> there can be multiple users behind one IP. Think of a university reading
> your website. Thus I am more comfortable limiting bandwidth than I am
> limiting the number of connections. ‎The 512k rate limit is fine. I
> wouldn't go any higher.
>
>
> If I understand correctly, limit_req only works if the same connection
> is used for each request.  My goal with limit_conn and limit_conn_zone
> would be to prevent someone from circumventing limit_req by opening a
> new connection for each request.  Given that, why would my
> limit_conn/limit_conn_zone config be any different from my
> limit_req/limit_req_zone config?
>
> - Grant
>
>
> > Should I basically duplicate my limit_req and limit_req_zone
> > directives into limit_conn and limit_conn_zone? In what sort of
> > situation would someone not do that?
> >
> > - Grant
>
> _______________________________________________
> nginx mailing list
> nginx at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx/attachments/20160912/16af3727/attachment.html>


More information about the nginx mailing list