Explain the internal working of NGINX worker processes and the event loop?

Each NGINX worker process is single-threaded by default but handles many connections concurrently through an event loop rather than through parallel threads.

On startup, a worker registers all the listening sockets it inherited from the master with the operating system's event notification interface - epoll on Linux. It then enters a loop: block on a call that returns as soon as one or more registered sockets have activity, process each ready event (accepting a new connection, reading available data, writing buffered output), and loop back to wait again.

Because this loop never blocks waiting on a single slow connection, the worker's attention effectively multiplexes across every connection it holds, spending CPU only on sockets that actually have work ready. Any operation that could block for a meaningful amount of time - certain filesystem operations, DNS resolution - is either handled asynchronously or, in some builds, delegated to a small thread pool so it doesn't stall the entire event loop for every other connection that worker is serving.

With worker_processes auto;, NGINX typically runs one worker per CPU core, letting the OS schedule each worker on its own core while every worker independently runs its own event loop over a subset of the total connections.