Nginx

Two rows each contain twelve serial request tokens, grouped by peer: equal weights give six A and six B, while weights 2:1 give eight A and four B in the source fixture.

Choose an nginx balancing method by the decision it actually makes

An upstream group names candidate backend endpoints, and its balancing method chooses among eligible peers. Round robin distributes selections by weight; least connections considers active connections and weights; hash methods use a selected key for affinity. These decisions describe routing policy. They do not automatically measure CPU utilization, guarantee equal response times, or make local session state durable when a peer disappears. ...

Both upload rows pause after 1024 of 65536 bytes. Buffering on stops before backend-handler entry; buffering off forwards early and the handler reads one byte.

Request buffering controls when the backend receives an upload

An upload has two separate connections: client to nginx and nginx to the application. proxy_request_buffering on reads the complete client request body before sending that request upstream. Turning it off lets nginx forward body bytes as they arrive. This changes when the application becomes occupied; it does not create unlimited capacity or make a slow sender disappear. ...

Two aligned columns replace /replace/ with /v1/ while preserving item?x=1. This is literal proxy URI prefix replacement.

proxy_pass maps the URI as well as selecting an upstream

nginx proxy_pass chooses an upstream destination and also affects the request URI sent there. The important distinction is whether the directive includes a URI component, not simply whether its text ends with a slash. In an ordinary prefix location, a literal target URI replaces the matching normalized prefix. An authority-only target can pass the original request URI when the request has not been rewritten. ...

One worker configured with keepalive 2 holds four active upstream connections, then retains two idle connections after release. Idle retention is not an active connection cap.

Upstream keepalive caches idle connections, not active capacity

An nginx upstream keepalive cache preserves eligible idle backend connections for later requests. In the tested configuration, keepalive 2 permits two idle connections in that upstream cache for each worker. It does not restrict the worker to two active backend connections. Reuse reduces repeated connection setup; it does not itself impose an application concurrency budget or guarantee lower latency for every request. ...

Historical nginx 1.28.0 fixture: failed connection recorded as 502, successful backup attempt 200, and one final client response 200.

An access log separates client outcomes from upstream attempts

An nginx access log records request information when logging runs at the end of processing. The selected fields can distinguish what the client requested, which URI ultimately handled it, what response was sent, and what happened during upstream attempts. Keep these observations separate: one status, duration, or path cannot explain the whole request. ...

A counted A-503 attempt leads to B-200 and final success, with a separate exclusion-to-live-traffic path and no periodic-probe implication.

Passive upstream health follows failed traffic, not a probe timer

nginx passive upstream health uses outcomes of real requests to decide whether a peer should temporarily stop receiving traffic. max_fails sets an unsuccessful-attempt threshold, while fail_timeout supplies both the counting interval and the unavailability period. These settings do not schedule periodic application probes. Active checks require a supported checking capability and configuration beyond this passive request-outcome policy. ...