What is Nginx and what is it used for?

• Servers and Infrastructure
• Updated: 4 October 2026
• About 10 min read

Getting to know Nginx

1. 1

   The four roles of Nginx

   The same software takes on different jobs depending on how it is configured. In most installations several of these roles are used together.

   • Web server: It reads static files such as HTML, CSS, JavaScript and images straight from disk and sends them to the visitor.
   • Reverse proxy: Instead of answering the request itself, it passes the request to an application behind it (the upstream or backend server) and carries the response back to the visitor. PHP, Node.js, Python and Java applications are mostly published this way. Details: what a reverse proxy is.
   • Load balancer: If several servers run the same application, it shares the requests out between them. Details: load balancing.
   • Cache: It keeps a copy of the responses coming from the backend for a set time; when the same request arrives again it answers without running the application. Details: caching and compression.

   In addition, it is common to accept the HTTPS connection at Nginx and pass the request to the application behind it unencrypted (SSL/TLS termination).

   : Enlarge

2. 2

   Event-driven architecture: few processes, many connections

   When Nginx is running you will see two kinds of process. The master process reads the configuration, starts the worker processes and manages reloads. The worker processes handle visitor connections.

   The important point is this: no separate process or thread is opened for each connection. Each worker process watches a large number of connections at once and only deals with the connection that has something to do at that moment (data has arrived, or it is ready to send data). This is called event-driven operation. A visitor's slow connection does not keep the worker idle while it waits; in the meantime the worker serves other connections.

   The number of worker processes is set with the worker_processes directive; the value auto sets it according to the number of processor cores. This architecture aims to keep memory use predictable, particularly when a large number of simultaneous connections stay open. Actual performance, however, depends on your site, your application and the configuration; it would be wrong to generalise without measuring.

   : Enlarge

3. 3

   How it differs from Apache

   Apache is also a long-established and widely used web server. The two do the same job, but their approach to configuration is different.

   • There is no .htaccess. When permitted, Apache reads the .htaccess file in each folder at request time; when you change the file the setting takes effect immediately and you do not need to restart the server. Nginx does not recognise such a file; an .htaccess you place in a folder does nothing.
   • Configuration is central. In Nginx all settings live in the configuration files on the server, and changing them usually requires administrator rights.
   • A change needs a test and a reload. Saving the file is not enough; first the syntax is checked, then Nginx is told to read the configuration again.
   • It does not run PHP itself. Apache can run PHP inside itself as a module. Nginx passes the request to PHP-FPM, which runs separately. Details: Nginx and PHP-FPM.

   Apache also has an event-based mode of operation and can be used with PHP-FPM, so the difference is not black and white. The real distinction is where the settings live and who can change them. To move existing .htaccess rules, see the guide on migrating from Apache to Nginx.

   : Enlarge

4. 4

   The two together: Nginx in front, Apache behind

   You do not have to choose between Nginx and Apache. A common arrangement is this: Nginx receives the visitor, serves static files itself and manages the HTTPS connection; it passes the remaining requests, as a reverse proxy, to Apache behind it. Apache continues to run the application and the .htaccess rules.

   The benefit of this arrangement is that you add a layer in front without changing the existing application that relies on .htaccess. The cost is that there are two programs to manage: two configurations, two sets of logs, and an extra setting so that Apache can see the visitor's real IP address. Setting up this arrangement is covered in the reverse proxy setup guide.

   : Enlarge

5. 5

   Configuration structure: http, server, location

   Nginx configuration consists of nested blocks. Each line is a directive and ends with a semicolon; blocks are opened and closed with curly braces.

   • The http block: General settings for web traffic. They apply to all sites.
   • The server block: Defines a single site (domain name); it is the counterpart of a virtual host in Apache. Which port it listens on (listen) and which domain names it answers for (server_name) are written here.
   • The location block: Determines how a particular address pattern of the site is handled (e.g. /, /img/, addresses ending in .php).

   An inner block inherits the settings of the outer one and, where needed, replaces them with its own value. In its simplest form a complete configuration file looks like this:

   Nginx

   # Main context: the process as a whole
   worker_processes auto;
   
   events {
       worker_connections 1024;
   }
   
   http {
       # Settings shared by all sites
       include mime.types;
       default_type application/octet-stream;
   
       server {
           # A single site
           listen 80;
           server_name example.com;
           root /var/www/example.com/public;
   
           location / {
               # Rules for a particular address pattern
               try_files $uri $uri/ =404;
           }
       }
   }

   In practice each site is kept in a separate file and the main file pulls them in with include. The main file is usually at /etc/nginx/nginx.conf; the location of the site files depends on the distribution (/etc/nginx/conf.d/ is common; /etc/nginx/sites-available/ and sites-enabled/ are the Debian and Ubuntu layout).

   The example below is a small server block that publishes a static site. The folder path is an example; use the path on your own server.

   Nginx

   server {
       listen 80;
       listen [::]:80;
       server_name example.com www.example.com;
   
       # The folder that holds the site's files, and the default document
       root /var/www/example.com/public;
       index index.html;
   
       # Look for the file first, then the folder; otherwise return 404
       location / {
           try_files $uri $uri/ =404;
       }
   
       # Static files may be kept in the browser for 30 days
       location ~* \.(css|js|png|jpg|jpeg|gif|svg|webp|woff2)$ {
           expires 30d;
       }
   
       # Hidden files that start with a dot (.git, .env, .htaccess) are not served,
       # except /.well-known/, which is used for certificate validation
       location ~ /\.(?!well-known) {
           deny all;
       }
   }

   try_files looks for the requested address first as a file, then as a folder; if it finds neither it returns 404. This example only listens on HTTP (80); for HTTPS, move on to the HTTPS and SSL certificate guide.

   : Enlarge

6. 6

   Basic commands: test first, then reload

   After every change to the configuration there are two steps: first a check, then a reload.

   Bash

   # 1. Check the configuration (shows the file and line if there is a syntax error)
   sudo nginx -t
   
   # 2. Reload without downtime (either one is enough)
   sudo systemctl reload nginx
   sudo nginx -s reload
   
   # Helpful commands
   nginx -v                     # shows the installed version
   sudo nginx -T                # prints the whole effective configuration
   sudo systemctl status nginx  # is the service running?

   If nginx -t finds an error it tells you the file name and the line number; do not reload until the error is fixed. A reload does not interrupt the site: the master process starts new worker processes with the new configuration, and the old workers finish the requests they are handling and exit. A restart, on the other hand, drops connections; it is not needed for ordinary configuration changes.

When to use which?

There is no single answer to "which one is better?". The choice should be driven by concrete criteria such as the ones below, not by claims about speed.

When you cannot decide, the question to ask is this: is there a concrete problem that the current setup does not solve? Moving a working site purely in the expectation that "it will be faster" may bring more risk than gain. Measure on your own site before and after the change.

Common mistakes

• Expecting .htaccess to work: When you move to Nginx, redirects, access restrictions and "clean URL" rules silently stop working unless they are moved into the server configuration. Protected folders may become exposed; test them one by one after the move.
• Reloading without testing: Run nginx -t first. A restart with a faulty configuration can take the site down.
• Forgetting a semicolon or a brace: These are the most common syntax errors; the test command shows the line.
• Saving the file and waiting for the change: Until you reload, Nginx keeps running with the old configuration.
• Editing the live file without a backup: Take a copy of the file before the change; if something goes wrong, going back takes a minute.

Roadmap: the next guides

Depending on what you need, you can read the guides in this category in the following order:

• Concepts: what a proxy server is, what a reverse proxy is, what load balancing is, what a CDN is.
• Setup and configuration: setting up a reverse proxy with Nginx, HTTPS and SSL certificates, Nginx and PHP-FPM.
• Performance: caching and compression.
• Security: Nginx security settings; in addition, security headers and HTTPS.
• Troubleshooting: 502, 504 and other Nginx errors.
• Migration: moving from Apache and .htaccess to Nginx.

Frequently asked questions

Related guides

• What is a reverse proxy?What a reverse proxy does, typical architectures, the real visitor IP and headers, how it relates to a CDN, and a short Nginx example.
• Nginx and PHP-FPM: how PHP sites run on Nginxfastcgi_pass, SCRIPT_FILENAME, try_files, the pool concept, socket permissions and the 502 error.
• Migrating from Apache and .htaccess to NginxSide-by-side examples, an equivalents table and a test list for moving .htaccess rules into the Nginx configuration.
• HTTPS in Nginx: setting up an SSL certificateGetting a certificate, redirecting to HTTPS, HSTS, SSL termination and automatic renewal in Nginx.