How to Configure NGINX
Traducciones al EspañolEstamos traduciendo nuestros guías y tutoriales al Español. Es posible que usted esté viendo una traducción generada automáticamente. Estamos trabajando con traductores profesionales para verificar las traducciones de nuestro sitio web. Este proyecto es un trabajo en curso.
NGINX is a lightweight, high-performance web server designed for high-traffic use cases. The most common use cases are HTTP cache at scale, load balancing, and reverse proxy.
What makes NGINX stand apart is its capability to serve static content such as HTML and Media files effectively. It uses an event-driven model to provide predictable performance even when the load is high.
This guide shows you several different NGINX server configurations.
NGINX Config: Directives, Blocks, and Contexts
All NGINX configuration files are located in the /etc/nginx/
directory. The primary configuration file is /etc/nginx/nginx.conf
.
The way NGINX configurations are setup is by:
- directives - they are NGINX configuration options
- Blocks (also known as contexts) - Groups in which Directives are organized
Note that any character after #
in a line becomes a comment. And NGINX does not interpret it.
To better understand directives and blocks, take a look at the condensed copy of /etc/nginx/nginx
conf below:
- File: /etc/nginx/nginx.conf
1 2 3 4 5 6 7 8 9 10 11 12 13
user nginx; worker_processes 1; error_log /var/log/nginx/error.log warn; pid /var/run/nginx.pid; events { . . . } http { . . . }
There are 4 directives in this snippet in the main context :
- user
- worker_processes
- error_log
- pid
Additional directives can be placed inside of events{…}, http{…} and so on. To read more about directives, visit the official NGINX documentation.
Let’s take a look at these blocks and their NGINX configurations.
NGINX Configuration - http Block
http blocks contain directives for handling web traffic. These directives are often universal as they are passed on to all website configurations NGINX serves. A list of available directives for http blocks are available on official NGINX http block documentation.
- File: /etc/nginx/nginx.conf
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19
http { include /etc/nginx/mime.types; default_type application/octet-stream; log_format main '$remote_addr - $remote_user [$time_local] "$request" ' '$status $body_bytes_sent "$http_referer" ' '"$http_user_agent" "$http_x_forwarded_for"'; access_log /var/log/nginx/access.log main; sendfile on; #tcp_nopush on; keepalive_timeout 65; #gzip on; include /etc/nginx/conf.d/*.conf; }
In the http block there’s an include directive that tells NGINX where website configuration files are located. It changes depending upon your source of NGINX installation:
- Installation from official NGINX repository: include directive is
include /etc/nginx/conf.d/*.conf;
. Every website you host with NGINX gets it’s own configuration file in/etc/nginx/conf.d/
, with names formatted asexample.com.conf
. - Installation from Debian or Ubuntu repositories: the include directive here would now be
include /etc/nginx/sites-enabled/*;
With site configuration file stored in/etc/nginx/sites-available/
NGINX Configuration - Server Blocks
Regardless of the installation source, server configuration files contain a server block for a website. Here’s an example server block:
- File: /etc/nginx/conf.d/example.com.conf
1 2 3 4 5 6 7 8
server { listen 80 default_server; listen [::]:80 default_server; server_name example.com www.example.com; root /var/www/example.com; index index.html; try_files $uri /index.html; }
There are several directives in this block that are worth taking a look at:
- listen - tells NGINX the hostname/IP and the TCP port where it should listen for HTTP connections
- server_name: allows multiple domains to be served from a single IP address. Ideally, it should be created per domain or site. Based on the request header it receives, the server decides which domain to serve.
NGINX Server Blocks Configuration Example - server_name
Here are some examples for server_name NGINX configuration based on sites you want to host on the server.
Configuration for processing requests for both example.com
and www.example.com
:
- File: /etc/nginx/conf.d/example.com.conf
1
server_name example.com www.example.com;
Configuration for processing requests for all subdomains for example.com
:
- File: /etc/nginx/conf.d/example.com.conf
1 2
server_name *.example.com; server_name .example.com;
Configuration for processing requests of all domains that start with example.
:
- File: /etc/nginx/conf.d/example.com.conf
1
server_name example.*;
NGINX Configuration of Location Blocks
Location
directives cover requests for specific files and folders. It also allows NGINX to respond to requests for resources within the server. Here’s an NGINX location blocks configuration:
- File: /etc/nginx/sites-available/example.com
1 2 3 4 5
location / { } location /images/ { } location /blog/ { } location /planet/ { } location /planet/blog/ { }
The locations are literal string matches, which means that a request to http://example.com/planet/blog/
or http://example.com/planet/blog/about/
is fulfilled by location /planet/blog/
, even though location /planet/
also matches this request.
Configuring NGINX location directive using regex match
When a location
directive is followed by a tilde (~), NGINX server performs a regular expression (regex) match. NGINX uses
Perl Compatible Regular Expression (PCRE) for regex. Here’s an example:
- File: /etc/nginx/sites-available/example.com
1 2
location ~ IndexPage\.php$ { } location ~ ^/BlogPlanet(/|/index\.php)$ { }
If you want this match to be case-insensitive, configure your location directive by adding an asterisk to tilde(~*).
- File: /etc/nginx/sites-available/example.com
1 2
location ~* \.(pl|cgi|perl|prl)$ { } location ~* \.(md|mdwn|txt|mkdn)$ { }
Adding a caret and tilde(^!) to location directives tells NGINX if it matches a particular string stop searching for more specific matches. And to use the directives here instead.
- File: /etc/nginx/sites-available/example.com
1 2
location ^~ /images/IndexPage/ { } location ^~ /blog/BlogPlanet/ { }
Finally, if you add an equals sign (=), this forces an exact match with the path requested and stops searching for more specific matches.
- File: /etc/nginx/sites-available/example.com
1
location = / { }
Location Root and Index Configuration
root
and index
determine the content of the associated location
directive block. Here’s an example:
- File: /etc/nginx/sites-available/example.com
1 2 3 4
location / { root html; index index.html index.htm; }
In this example, the document root is located in the html/
directory. Under the default installation prefix for the NGINX, the full path to this location is /etc/nginx/html/
.
Here’s a complex example that shows a set of location
directives for a server responding to the domain example.com
:
- File: /etc/nginx/sites-available/example.com location directive
1 2 3 4 5 6 7 8 9 10 11 12
location / { root /srv/www/example.com/public_html; index index.html index.htm; } location ~ \.pl$ { gzip off; include /etc/nginx/fastcgi_params; fastcgi_pass unix:/var/run/fcgiwrap.socket; fastcgi_index index.pl; fastcgi_param SCRIPT_FILENAME /srv/www/example.com/public_html$fastcgi_script_name; }
In this NGINX configuration, all requests that end in a .pl
extension are handled by the second location block, which specifies a fastcgi
handler for these requests. Otherwise, NGINX configuration uses the first location directive.
Let’s analyze how NGINX handles some requests based on this configuration:
http://example.com/
is requested - if it exists NGINX returns/srv/www/example.com/public_html/index.html
. If the file doesn’t exist, it serves/srv/www/example.com/public_html/index.htm
. A 404 is returned if neither exist.http://example.com/blog/
is requested - if the file exists,/srv/www/example.com/public_html/blog/index.html
is returned. If not,/srv/www/example.com/public_html/blog/index.htm
is served instead. If neither exist, a 404 error is returned.http://example.com/tasks.pl
is requested - NGINX uses FastCGI handler to execute the file at/srv/www/example.com/public_html/tasks.pl
and return the result.http://example.com/username/roster.pl
is requested - NGINX uses FastCGI handler to execute the file at/srv/www/example.com/public_html/username/roster.pl
and return the result.
NGINX Configuration of Reverse Proxy
NGINX reverse proxy acts as an intermediate proxy that takes a client request and passes it to the servers. From load balancing, increased security to higher performance - it is used for a range of use cases.
To get started with configuring a reverse proxy, follow these steps.
If not already installed, install NGINX by
apt update apt install nginx
This installs NGINX web server.
Deactivate your virtual host. To deactivate your virtual host run
unlink /etc/nginx/sites-enabled/default
Change your directory to /sites-available and create a reverse proxy there:
cd /etc/nginx/sites-available` nano reverse-proxy.conf`
Configure proxy server to redirect all requests on port 80 to a lightweight http server that listens to port 8000. To do that, write the following Nginx configuration:
1 2 3 4 5 6 7 8 9 10
server { listen 80; listen [::]:80; access_log /var/log/nginx/reverse-access.log; error_log /var/log/nginx/reverse-error.log; location / { proxy_pass http://127.0.0.1:8000; } }
Use the symbolic link and copy configuration from
/etc/nginx/sites-available
to/etc/nginx/sites-enabled
:ln -s /etc/nginx/sites-available/reverse-proxy.conf /etc/nginx/sites-enabled/reverse-proxy.conf
Verify if NGINX is working:
nginx -t
If you see a successful test message, NGINX reverse proxy is properly configured on your system.
Configuring Load Balance with NGINX
We assume that you already have NGINX installed. If not, follow the steps from the previous section. To configure your NGINX and use it as a load balancer, add your backend servers to your configuration file first. Collect your server IPs that acts as load balancers:
- File: load_balancer.conf
1 2 3 4 5 6 7 8
upstream backend { server 72.229.28.185; server 72.229.28.186; server 72.229.28.187; server 72.229.28.188; server 72.229.28.189; server 72.229.28.190; }
After upstream servers are defined, go to the location /etc/nginx/sites-available/
and edit load_balancer.conf
.
- File: /etc/nginx/sites-available/load_balancer.conf
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18
upstream backend { server 72.229.28.185; server 72.229.28.186; server 72.229.28.187; server 72.229.28.188; server 72.229.28.189; server 72.229.28.190; } server { listen 80; server_name SUBDOMAIN.DOMAIN.TLD; location / { proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_pass https://backend; } }
Every time a request is made to port 80 to SUBDOMAIN.DOMAIN.LTD, request is routed to upstream servers.
After done, execute this new configuration by reloading NGINX using
nginx -t
cd /etc/nginx/site-enabled/
ln -s ../sites-available/load_balancer.conf
systemctl reload nginx
You can further configure and optimize your load balancer by load balancing methods like Round Robin, Least connected, IP hash, and Weighted.
This page was originally published on