Common configuration errors – Nginx

The next step in troubleshooting a problem is to take a look at the configuration to see whether it actually achieves the goal you are trying to accomplish. NGINX configurations have been floating around the Internet for a number of years. Often, they were designed for an older version of NGINX, and to solve a specific problem. Unfortunately, these configurations are copied without really understanding the problem they were designed to solve. There is sometimes a better way to solve the same problem, using a newer configuration.

Using if instead of try_files

One such case is a situation in which a user wants to deliver a static file if it is found on the filesystem, and if not, to pass the request on to a FastCGI server:

server {

  root /var/www/html;

  location / {

    if (!-f $request_filename) {

      include fastcgi_params;

      fastcgi_pass 127.0.0.1:9000;

      break;

    }

  }

}

This was the way this problem was commonly solved before NGINX had the try_files directive, which appeared in version 0.7.27. The reason why this is considered a configuration error is that it involves using if within a location directive. As detailed in the Converting an if-fy configuration to a more modern interpretation section in Chapter 4, NGINX as a Reverse Proxy, this can lead to unexpected results or possibly even a crash. The way to correctly solve this problem is as follows:

server {

  root /var/www/html;

  location / {

    try_files $uri $uri/ @fastcgi;

  }

  location @fastcgi {
    include fastcgi_params;

    fastcgi_pass 127.0.0.1:9000;

  }

}

The try_files directive is used to determine whether the file exists on the filesystem, and if not, passes the request on to the FastCGI server without using if.

Using if as a hostname switch

There are countless examples of configurations where if is used to redirect requests based on the HTTP Host header. These types of configuration work as selectors and are evaluated for each request:

server {

  server_name .example.com;

  root /var/www/html;

  if ($host ~* ^example\.com) {

    rewrite ^/(.*)$ http://www.example.com/$1 redirect;

  }

}

Instead of incurring the processing costs associated with evaluating if for each request, NGINX’s normal request-matching routine can route the request to the correct virtual server. The redirect can then be placed where it belongs, and even without a rewrite:

server {

  server_name example.com;

  return 301 $scheme://www.example.com;

}
server {

  server_name www.example.com;

  root /var/www/html;

  location / {

    …

  }

}

Not using the server context to best effect

Another place where copied configuration snippets often lead to incorrect configurations is the area of the server context. The server context describes the whole virtual server (everything that should be addressed under a particular server_name instance). It is underutilized in these copied configuration snippets.

Often, we will see root and index specified per location:

server {

  server_name www.example.com;

  location / {

    root /var/www/html;

    index index.php index.html index.htm;

  }

  location /ftp{

    root /var/www/html;

    index index.php index.html index.htm;

  }

}

This can lead to configuration errors when new locations are added, and the directives are not copied to those new locations or are copied incorrectly. The point of using the root and index directives is to indicate the document root for the virtual server and the files that should be tried when a directory is given in the URI, respectively. These values are then inherited for any location directive within that server context:

server {

  server_name www.example.com;

  root /var/www/html;

  index index.php index.html index.htm;

  location / {

    ...

  }

  location /ftp{

    ...

  }

}

Here, we specified that all files will be found under /var/www/html and that index.php, index.html, and index.htm are to be tried, in order, as index files for any location.

Related Articles

How to add swap space on Ubuntu 21.04 Operating System

How to add swap space on Ubuntu 21.04 Operating System

The swap space is a unique space on the disk that is used by the system when Physical RAM is full. When a Linux machine runout the RAM it use swap space to move inactive pages from RAM. Swap space can be created into Linux system in two ways, one we can create a...

read more

Lorem ipsum dolor sit amet consectetur

0 Comments

Submit a Comment

Your email address will not be published. Required fields are marked *

one × five =