Table of Contents
Introduction to Nginx
Nginx is a high‑performance web server and reverse proxy that is widely used on Linux servers. It is known for handling large numbers of concurrent connections efficiently while using relatively low memory. In this chapter you will see how Nginx is typically installed, how its configuration is structured, and how to perform the most common basic tasks such as serving simple sites, defining server blocks, and reloading configuration safely. More advanced concepts like SSL and reverse proxying belong in other chapters and will only be touched on briefly here.
Installing Nginx and Managing the Service
On most Linux distributions Nginx is available directly from the default package repositories. The exact package manager command depends on the distribution, but the package name is usually nginx. Once installed, Nginx runs as a system service that you can control with systemctl.
On a typical system you will start the service with a command like:
sudo systemctl start nginxTo enable Nginx to start automatically at boot you use:
sudo systemctl enable nginxTo stop or restart the service you can run:
sudo systemctl stop nginx
sudo systemctl restart nginxFor configuration changes, restarting is not always necessary. Nginx supports a reload operation that applies configuration changes without dropping existing connections. This is usually preferred in production environments:
sudo systemctl reload nginxYou can always check if Nginx is running by inspecting its status:
sudo systemctl status nginxThis shows whether the service is active, and any recent error messages if it failed to start.
Nginx Master and Worker Processes
Nginx uses a master and worker process model. The master process reads the configuration, opens listening sockets, and manages worker processes. Worker processes handle actual requests from clients.
You can see the running Nginx processes with a command like:
ps aux | grep nginx
The master process typically runs as root so it can bind to low numbered ports such as 80, while workers usually run as a less privileged user defined in the configuration. The number of worker processes and certain performance settings are defined in the main configuration file and can be tuned for your hardware and workload.
Nginx Configuration Structure
Nginx reads its configuration from a main file, commonly /etc/nginx/nginx.conf. This file can include additional configuration files. Most distributions use the same general structure, even if exact paths differ slightly.
The configuration is made of nested blocks. Each block is enclosed in curly braces and can contain directives and other blocks. A typical high level layout looks like this:
user www-data;
worker_processes auto;
events {
worker_connections 1024;
}
http {
include mime.types;
default_type application/octet-stream;
sendfile on;
include /etc/nginx/conf.d/*.conf;
include /etc/nginx/sites-enabled/*;
}Directives are simple statements that end with a semicolon, for example:
worker_processes auto;
Blocks, such as events { ... } or http { ... }, group directives that apply within a certain context. Many configuration issues come from placing directives in the wrong context, so it is important to understand the scope of each block.
The most important blocks for basic web serving are the http block and server blocks inside it. The http block defines HTTP related settings shared across sites, while each server block represents a virtual host, which you will see next.
Server Blocks and Virtual Hosts
In Nginx each website or virtual host is defined by a server block. A server block tells Nginx which hostnames and ports it should listen to, and which content to serve for those requests.
Here is a minimal example of a server block:
server {
listen 80;
server_name example.com www.example.com;
root /var/www/example.com/html;
index index.html;
location / {
try_files $uri $uri/ =404;
}
}
The listen directive specifies the port, and optionally the IP address, on which this server block should accept connections. For basic HTTP sites this is usually port 80. The server_name directive lists the hostnames for this site. When a request arrives, Nginx compares the value of the Host header to determine which server block should handle it.
The root directive defines the directory in the filesystem where the site files are stored. The index directive tells Nginx which file names to look for when a client requests a directory, for example /.
The location block determines how requests for particular paths are handled. In the example, the location / block matches all URIs that start with /. The try_files directive instructs Nginx to look for an existing file or directory that matches the URI and, if none is found, return a 404 Not Found status.
A single Nginx instance can host many sites by using multiple server blocks, each with its own server_name, root, and other settings.
Sites Available and Sites Enabled Layout
Several distributions organise Nginx configuration with sites-available and sites-enabled directories. This structure allows you to store configuration for many sites while easily controlling which ones are active.
You typically find:
/etc/nginx/sites-available which holds configuration files for each potential site, for example example.com.
/etc/nginx/sites-enabled which holds symbolic links pointing to the files in sites-available that are currently enabled.
To enable a site you create the configuration file in sites-available then create a symlink in sites-enabled. An example command might look like this:
sudo ln -s /etc/nginx/sites-available/example.com \
/etc/nginx/sites-enabled/example.com
To disable a site you remove the symlink from sites-enabled:
sudo rm /etc/nginx/sites-enabled/example.comAfter enabling or disabling a site you must reload Nginx so it reads the updated configuration.
Not all distributions use this layout. Some use only a conf.d directory that Nginx includes from the main nginx.conf. The core idea is the same: individual site configurations live in separate files that Nginx includes from a single main configuration.
Location Blocks and Basic Request Handling
Within a server block, location directives are used to match specific request URIs and define how Nginx should process them. Only the basics belong here, more advanced patterns and directives will appear in other chapters.
A simple location block can look like this:
location /images/ {
root /var/www/static;
}
When a request comes in for /images/logo.png, Nginx takes the root directory /var/www/static, appends the requested path, and tries to serve /var/www/static/images/logo.png.
The most common match is a prefix match, where the URI must start with the given string. There are also exact and regular expression matches, which let you fine tune routing. When multiple location blocks could match a request, Nginx uses a priority order to decide which one to apply.
Within a location block you can change many behaviors, for example selecting a different root, adding headers, or passing the request to another service. For basic static file serving you mostly adjust root, index, and possibly try_files.
Static File Serving and Index Files
One of the simplest uses of Nginx is to serve static files such as HTML, CSS, JavaScript, and images from a directory tree. A basic configuration for static content might look like: