Nginx - minimal configuration

A secure server is one that allows only the required number of servers. Ideally, we would build a server based on a minimal system by enabling other features individually. Doing minimal configuration also helps with debugging. If the bug is not available in the minimal system, add the function separately and continue searching for the bug.

This is the minimum configuration required to run nginx:

# /etc/nginx/nginx.confevents {}         # event context have to be defined to consider config validhttp {
server {
  listen 80;
  server_name  javatpoint.co  www.javatpoint.co  *.javatpoint.co;

  return 200 "Hello";
}

Root, Location and try_files directives

root directive

The root directive is used to set the root directory for requests, allowing nginx to map incoming requests onto the filesystem.

server {
  listen 80;
  server_name javatpoint.co;
  root /var/www/javatpoint.co;
}

It allows nginx to return server content upon request:

javatpoint.co:80/index.html     # returns /var/www/learnfk.com/index.html
javatpoint.co:80/foo/index.html # returns /var/www/learnfk.com/foo/index.html

Location directive

The location directive is used to set the configuration based on the URI (Uniform Resource Identifier) of the request.

The syntax is:

location [modifier] path

Example:

location /foo {
  # ...
}

If no modifier is specified, the path is treated as a prefix, after which anything can follow. The above example will match:

/foo
/fooo
/foo123
/foo/bar/index.html
...

We can also use multiple location directives in a given context:

server {
  listen 80;
  server_name javatpoint.co;
  root /var/www/javatpoint.co;

  location/{
    return 200 "root";
  }

  location /foo {
    return 200 "foo";
  }
}
javatpoint.co:80  /      # => "root"
javatpoint.co:80   /foo    # => "foo"
javatpoint.co:80   /foo123 # => "foo"
javatpoint.co:80   /bar    # => "root"

Nginx also provides some modifiers that can be used in conjunction with the location directive.

Modifiers have assigned priorities:

=           - Exact match
^~          - Preferential match
~ && ~*     - Regex match
no modifier - Prefix match

First, nginx will check all exact matches. If it doesn't exist, it will look for the preferred option. If this match also fails, the regular expression matches will be tested in the order in which they appear. If all else fails, the last prefix match will be used.

location /match {
  return 200 'Prefix match: will match everything that starting with /match';
}

location ~* /match[0-9] {
  return 200 'Case insensitive regex match';
}

location ~ /MATCH[0-9] {
  return 200 'Case sensitive regex match';
}

location ^~ /match0 {
  return 200 'Preferential match';
}

location = /match {
  return 200 'Exact match';
}
/match     # => 'Exact match'
/match0    # => 'Preferential match'
/match1    # => 'Case insensitive regex match'
/MATCH1    # => 'Case sensitive regex match'
/match-abc # => 'Prefix match: matches everything that starting with /match'

try_files directive
The directive tries different paths and returns any found.

try_files $uri index.html =404;

So /foo.html will try to return the files in the following order:

$uri(/foo.html);

index.html

If not found: 404

If we define try_files in the server context and then define where to look for all requests, try_files will not be executed. This happens because try_files in the server context defines its pseudo location, which is the lowest specific location possible. Therefore, defining location/ would be more specific than our pseudo-location.

server {
  try_files $uri /index.html =404;

  location/{
  }
}

Therefore, we should avoid using try_files in the server context:

server {
  location/{
    try_files $uri /index.html =404;
  }
}

Source: https://www.imooc.com/article/319107