Clear explanation of master vs workers and why worker_connections is not just "max RPS." In reverse-proxy edge roles I size workers to CPU cores (auto is fine) and set worker_connections for concurrent client sockets plus upstream sockets, because each proxied request can hold both sides open under keepalive. Underestimating that number shows up as accept queue growth and intermittent 502s long before CPU saturates.

Ops check after a tune: watch active and waiting connections under load, confirm worker_connections * worker_processes leaves headroom above peak, and keep multi_accept on only when the accept queue actually builds. If waiting climbs while CPU is idle, raise connections or shorten idle keepalive timeouts before adding hardware. Log worker exits and reopen cycles after reload — a sudden drop in worker count after config change usually means a limit was hit, not a traffic cliff.