Nginx: limit_conn vs upstream max_conns (in location context) - nginx

Question

Environment: Nginx 1.14.0 (see dockerfile for more details).
To limit the number of concurrent connections for a specific location
in a server, one can use two methods - limit_conn (third example for all ips)
and upstream max_conns.
Is there a difference in the way the two methods works?
Can someone explain or refer to explanation?
example of limiting using upstream max_conns:
http {
upstream foo{
zone upstream_foo 32m;
server some-ip:8080 max_conns=100;
}
server {
listen 80;
server_name localhost;
location /some_path {
proxy_pass http://foo/some_path;
return 429;
}
}
}
limiting using limit_conn:
http {
limit_conn_zone $server_name zone=perserver:32m;
server {
listen 80;
server_name localhost;
location /some_path {
proxy_pass http://some-ip:8080/some_path;
limit_conn perserver 100;
limit_conn_status 429;
}
}
}

Answer 1

upstream max_conns is the number of connections from the nginx server to an upstream proxy server. max_conns is more to make sure backend servers do not get overloaded. Say you have an upstream of 5 servers that nginx can send to. Maybe one is underpowered so you limit the total number of connections to it to keep from overloading it.
limit_conn is the number of connections to the nginx server from a client and is to limit abuse from requests to the nginx server. For example you can say for a location that an IP can only have 10 open connections before maxing out.

Answer 2

Also note that, if the max_conns limit has been reached, the request can be placed in a queue for further processing, provided that the queue (NGINX Plus) directive is also included to set the maximum number of requests that can be simultaneously in the queue:
upstream backend {
server backend1.example.com max_conns=3;
server backend2.example.com;
queue 100 timeout=70;
}
If the queue is filled up with requests or the upstream server cannot be selected during the timeout specified by the optional timeout parameter, or the queue parameter is omitted, the client receives an error (502).