Main Content

The reason Nginx can support hundreds of thousands of concurrent connections on the same server is not “high magic” configuration, but the combined design of Master-Worker multi-process + event-driven. Master process is for management and control. Worker processes are for real network I/O.

Master Process

  • Mainly manages Worker processes, accepts external information and sends signals to each Worker process
  • Monitors Worker process running status, automatically restarts new Worker process when Worker process exits abnormally
  • Reads and parses nginx.conf, establishes shared memory area
  • Derives Workers based on worker_processes directive (default auto)
  • Receives external signals (-s reload|quit|stop|reopen) and broadcasts to Workers

Worker Process

  • Worker processes specifically handle network requests. Multiple Worker processes are equal to each other
  • A request can only be processed in one Worker
  • Number of Worker processes is usually set to match number of CPU cores
  • Each Worker runs single-threaded, listening to all connection events with epoll (Linux) or kqueue (FreeBSD/macOS)

Connection Acceptance Mechanism

  • By default all Workers listen on the same set of ports together
  • Uses accept_mutex lock to avoid thundering herd
  • worker_connections × worker_processes is the theoretical concurrent connection upper limit

nginx -s reload Flow

  1. Master process performs syntax check on configuration file
  2. Try configuration
  3. If try succeeds, use new configuration, create new worker process
  4. If new creation succeeds, send closing message to old worker process
  5. Old worker process continues to serve after receiving signal until current process’s received requests are processed and then exits

Benefits of Nginx Multi-Process

  • Each Worker process is independent, no locking needed, saving overhead
  • Each Worker process is independent, one abnormal end does not affect others, they can still provide services
  • Multi-process model provides support for reload hot deployment

Common Commands

  • nginx -s reload — Smooth configuration reload (SIGHUP), zero-downtime configuration change
  • nginx -s quit — Graceful shutdown (SIGQUIT), exits after processing existing connections
  • nginx -s stop — Force terminate (SIGTERM), exits immediately
  • nginx -s reopen — Reopen logs (SIGUSR1), log rotation without restart

New Features (Nginx 1.28)

  • Native QUIC/HTTP/3 support
  • Introduces CUBIC congestion control, 24%-73% faster file transfer in high-traffic high-latency scenarios
  • Can combine with reuseport on to give each Worker independent listening FD, reducing lock contention