A handful of clients are exhausting an nginx server by holding many simultaneous slow downloads open. Why does `limit_conn` help here where `limit_req` does not?

## Two modules, two resources nginx ships two distinct limiting modules and candidates routinely conflate them. - `ngx_http_limit_req_module` — `limit_req_zone` / `limit_req`. Limits the **rate of request arrivals** per key. - `ngx_http_limit_conn_module` — `limit_conn_zone` / `limit_conn`. Limits the **number of concurrent connections** per key. Both use a shared memory zone keyed by an nginx variable, both are configurable in `http`, `server` and `location` contexts, and both reject with 503 by default (`limit_req_status`, `limit_conn_status`). That surface similarity is why they get muddled. ```nginx http { limit_conn_zone $binary_remote_addr zone=perip:10m; limit_conn_zone $server_name zone=persrv:10m; server { location /downloads/ { limit_conn perip 5; limit_conn persrv 200; limit_rate 512k; } } } ``` ## Why a rate limit misses this attack Rate limiting assumes the harmful thing is *how often* a client asks. Whole classes of resource exhaustion do not look like that: - **Slow reads.** A client requests a large file and then reads a few bytes per second. One request, one arrival, indefinite occupancy. - **Slow request bodies (slowloris-shaped).** The client sends headers or a body one byte at a time so the request is never complete. - **Concurrent bulk downloads.** Perfectly legitimate-looking requests, just fifty of them at once from one source. In every case the arrival rate is trivially low. `limit_req` sees nothing to reject. What is consumed is connection slots — and, behind nginx, upstream connections and backend worker threads. `limit_conn` measures exactly that. `limit_conn perip 5;` means the sixth concurrent connection from that address being processed is rejected immediately, while the first five continue. ## The counting rule that catches people out nginx counts only connections **where a request is being processed and the whole request header has already been read**. Two consequences: 1. An idle keep-alive connection does not consume a `limit_conn` slot. A browser holding six persistent connections to your host is not sitting at your limit while the user reads the page. 2. A connection that has sent partial headers is *also* not counted yet — which is precisely the slowloris shape. `limit_conn` therefore does not by itself solve the incomplete-header attack; `client_header_timeout` does, by closing connections that dawdle over their headers. So the honest answer in an interview is that `limit_conn` is one of three controls, not a complete defence: ```nginx client_header_timeout 10s; # kill slow header senders client_body_timeout 10s; # kill slow body senders send_timeout 10s; # kill clients that stop reading the response limit_conn perip 5; # cap concurrency once a request is in flight ``` ## Choosing the key The key is any variable, and the choice defines the fairness unit: - `$binary_remote_addr` — per client address. Compact, and the usual default. Punishes shared NATs and corporate egress, which is the trade you accept. - `$server_name` — a ceiling for one virtual host so a single site cannot starve its neighbours on a shared instance. - A variable you build with `map` — for example a tenant identifier extracted from a header — when the address is not the meaningful unit. One caution: the zone is shared memory inside *this* nginx instance. Behind a load balancer with several nginx nodes, each keeps its own counters, so the effective concurrency ceiling is the per-node limit multiplied by the node count. ## Pairing with bandwidth control `limit_conn` caps how many streams a client gets; `limit_rate` (and `limit_rate_after`) caps how fast each one flows. Together they bound the bandwidth one key can take: five connections at 512k each is a hard 2.5 MB/s ceiling. Setting only `limit_rate` invites the client to compensate by opening more connections; setting only `limit_conn` lets each connection run at line speed. Interviewers like this pairing because it shows you reasoned about what the client will do next. ## When to reach for which Ask what the scarce resource is. If it is *work performed per unit time* — database queries behind an API, login attempts, expensive search — use `limit_req`. If it is *simultaneous occupancy* — connections, sockets, large transfers, long-lived streams — use `limit_conn`. Real edge configs usually carry both, in separate zones, because the two abuse shapes are independent.