Nginx is a web server, reverse proxy, and load balancer in one program. It was created by Igor Sysoev in 2004 to solve the C10k problem: how to keep ten thousand simultaneous connections on one server without a performance collapse. Today Nginx serves a large share of internet traffic and runs on shared hosting, VDS, and dedicated servers, including the ZevsHost.net infrastructure.
What Nginx is and why it exists
Nginx accepts HTTP requests from browsers and serves them files, pages, or forwards the request further to PHP-FPM, Node.js, or another backend. Besides static and dynamic content, it works as a reverse proxy, caches responses, encrypts traffic over SSL/TLS, and limits load from individual clients.
The main difference from a classic web server is that Nginx does not spawn a separate process or thread for every connection. This solves the core performance problem of older servers under a large number of simultaneous clients.
How the Nginx architecture works: master and worker processes
Inside Nginx there is one master process and several worker processes. The master process starts as root, reads the configuration, opens sockets, and manages worker processes: it restarts them on failure and applies a new configuration without dropping connections.
Worker processes do all the real work: they accept connections, read requests, and send responses. Each worker is a single-threaded process, but thanks to the event-driven model, one worker handles thousands of connections in parallel. The number of worker processes is set by the worker_processes directive and usually equals the number of CPU cores.
nginx -V
nginx -t
systemctl reload nginx
Event-driven model instead of a process per connection
Apache in classic prefork mode spawns a separate process for every connection, and in worker mode a separate thread. As the number of clients grows, so does the number of processes, each consuming memory and requiring CPU context switches.
Nginx uses non-blocking I/O and the epoll system call on Linux (kqueue on BSD). A worker process does not wait for one operation to finish; instead it processes events from hundreds of connections in a loop. This is exactly what lets it hold 10,000 or more simultaneous connections on a modest VPS with 1-2 GB of memory.
How Nginx differs from Apache
Apache is historically stronger at dynamic processing through modules like mod_php, which embed the interpreter directly inside the web server. Nginx fundamentally does not embed interpreters: it hands dynamic content off over FastCGI to PHP-FPM or over HTTP to an upstream server. This pairing is covered in detail in the article on Nginx and PHP-FPM.
Another difference is the configuration file. Apache uses .htaccess in every site folder, which the server rereads on every request. Nginx configuration is static: .htaccess is not supported at all, and rules are described in a server block, covered in detail in the article on Nginx virtual hosts.
Comparison table: Nginx versus Apache
| Parameter | Nginx | Apache |
|---|---|---|
| Processing model | Event-driven, one worker for thousands of connections | Process/thread per connection |
| .htaccess support | No | Yes |
| PHP handling | Via FastCGI and PHP-FPM | Built-in mod_php module |
| Memory use under growing load | Grows slowly | Grows proportionally to connection count |
Where Nginx is used in practice
Typical use cases for Nginx on servers and hosting accounts:
- Web server for static content: HTML, CSS, JS, images without any backend.
- Reverse proxy in front of PHP-FPM, Node.js, or a Java application.
- Load balancer distributing traffic across several backend servers.
- TLS terminator: handling HTTPS in front of internal services over HTTP.
- Caching layer in front of a slow origin server.
Where to start configuring Nginx
Before writing location rules and setting up proxying, you need to install the server itself and understand its configuration file structure. The order is:
- Install the Nginx package from the official repository, as described in the article on installing Nginx on Ubuntu and Debian.
- Study the configuration structure and create the first server block for your domain.
- Set up dynamic content handling through PHP-FPM or a reverse proxy to the required backend.
- If the site is moving from an old server, check the article on migrating from Apache to Nginx so you do not lose rules from .htaccess.
Nginx beats Apache on memory consumption and on the number of simultaneous connections on equal hardware, but it requires a different approach to configuration: no .htaccess and no built-in PHP interpreter. That trade-off pays off on loaded sites and on VPS instances with limited resources.