A secure server is one that allows only the required number of servers. Ideally, we will build the server based on the smallest system by enabling other functions separately. Minimal configuration is also helpful for debugging. If the error is not available in the smallest system, add functions separately, and then continue to search for errors.

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 directive

Root instruction

The root instruction is used to set the root directory of the request, allowing nginx to map the incoming request to the file system.

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 instruction

The identifier used to configure the resource is set according to the URI of the request.

The syntax is:

location [modifier] path

Example:

location /foo {
  # ...
}

If no modifier is specified, the path is treated as a prefix and can be followed by anything. The above example will match:

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

We can also use multiple location instructions 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 instruction.

Modifier assigned priority:

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

We can also use multiple location instructions 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 instruction.

Modifier assigned priority:

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

First, nginx will check all exact matches. If it does not exist, it will look for priority options. If this match also fails, regular expression matches are tested in the order in which they appear. If all other operations fail, the last prefix match is 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 instruction tries a different path and returns any path found.

try_files $uri index.html =404;

Therefore, / foo HTML will attempt to return the files in the following order:

$uri(/foo.html);

index.html

If not found: 404

If we define try in the server context_ Files, and then define the location to find all requests, then try will not be performed_ files. This happens because of the try in the server context_ Files defines its pseudo location, which is the lowest possible specific location. Therefore, defining location / will be more specific than our pseudo location.

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

  location/{
  }
}

Therefore, we should avoid using try in the server context_ files:

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

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