You added `keepalive 32;` to an nginx `upstream` block, but connections to the backend are still opened and closed for every request. What else must the proxying location set, and what does that number actually count?

## Three directives, not one Upstream keepalive is the single most frequently half-configured thing in nginx. The complete form is: ```nginx upstream backend { server 10.0.0.11:8080; server 10.0.0.12:8080; keepalive 32; } server { location / { proxy_pass http://backend; proxy_http_version 1.1; proxy_set_header Connection ""; } } ``` Why each line exists: - **`keepalive 32;`** creates the idle-connection cache for the group. Without it there is nothing to reuse. - **`proxy_http_version 1.1;`** — nginx proxies using HTTP/1.0 by default, and persistent connections are not the default there. Leave this out and every response ends with a close. - **`proxy_set_header Connection "";`** — nginx's default proxied headers include `Connection: close`. Setting the header to the empty string removes it, so the backend is not asked to close. Note also that `Connection` is hop-by-hop: a client-supplied value must not be relayed, which is why nginx handles this header explicitly rather than passing it through. Miss any one and the other two do nothing observable. ## What the number means `keepalive N` is the maximum number of **idle** connections to the upstream group preserved in the cache of **one worker process**. It is not a limit on how many connections that worker may open: under a burst nginx opens as many as it needs, and when more than N of them fall idle, the least recently used are closed. Sizing it as though it were a connection cap is the standard misreading, and it leads people to set it enormous "so we don't run out". Because it is per worker, a host with `worker_processes auto;` on 8 cores and `keepalive 32;` can hold about 256 idle connections to that group. Size it against what the backend can hold open, not against your request rate. ## Two companions - **`keepalive_requests`** — how many requests may be served over one upstream connection before nginx closes it. As of nginx 1.19.10 the default is 1000; it was 100 before. It exists to stop per-connection memory allocations growing without bound and to let long-lived pools rebalance. - **`keepalive_timeout`** in the upstream context — how long an idle upstream connection is kept. One ordering rule catches people: when the group uses a balancing method other than the default round robin, the method directive must appear **before** `keepalive` in the block. ## The race that produces mystery 502s Connection reuse creates a window that does not exist without it. Nginx picks an idle connection and writes a request; at almost the same moment the backend, whose own idle timeout is shorter, closes it. Nginx sees a reset on a connection it believed usable. The symptom is a small, steady trickle of 502s under otherwise normal traffic, often clustered after quiet periods. The fix is ordering the timeouts deliberately: the backend's idle timeout should be **longer** than nginx's `keepalive_timeout` for the group, so nginx is always the side that closes. Nginx's `proxy_next_upstream` behaviour can retry an idempotent request that failed this way, but relying on retries to paper over mismatched timeouts is treating the symptom. ## What you actually gain Every avoided connection is a TCP handshake, and if the hop is encrypted, a TLS handshake too — measurable latency on every request, plus per-connection work on both machines and churn in the local port and socket-state accounting on the proxy host. On a chatty internal path the improvement is usually visible immediately in `$upstream_connect_time`, which drops to near zero for reused connections while `$upstream_response_time` stays where it was. Logging both variables is the cheapest way to prove that keepalive is actually working, and it is a much better answer than "the config looks right". ## Interview framing The question tests whether you have configured this yourself or copied it. The three-directive requirement, the per-worker idle-cache meaning of the number, and the shorter-backend-timeout race are the three things that separate the two.