RAMNIC

Nginx References (location block)

Note that most these references are Ubuntu/Debian based but should also be useful with any Nginx install.

Nginx

Location Block

• (none) If no modifiers are present, the location is interpreted as a prefix match. This means that the location given will be matched against the beginning of the request URI to determine a match.

  location /example {
       ...
    }

 

• = If an equal sign is used, this block will be considered a match if the request URI exactly matches the location given.

  location = /example {
       ...
    }

 

• ~ If a tilde modifier is present, this location will be interpreted as a case-sensitive regex match.

  location ~ \.(gif|jpg|png|PNG|JPG|GIF)$ {
       ...
    }

 

• ~* If a tilde and asterisk modifier is used, the location block will be interpreted as a case-insensitive regex match.

  location ~* \.(gif|jpg|png)$ {
      ...
    }

 

• ^~ If a carat and tilde modifier is present, and if this block is selected as the best non-regex match, regex matching will not take place.

  location ^~ /example {
       ...
    }

How Nginx picks which location block will be used

• The first block checked is the exact match = . If this block matches, it is used immediately.
• Next will be the other 2 prefix (non-regex) type blocks. This would include ^~ and none. Starting with the longest match. ie; /example and /example/images. The longer is /example/images. Now here is where it gets a little misunderstood by many. If the match was a ^~, it is used immediately, but if it was other (none) then that is stored by Nginx to be used later in the final decision.
• After the longest matching prefix location is determined and stored, Nginx moves on to evaluating the regex locations. Nginx tries the regex locations sequentially. The first regex location that matches the request URI is immediately selected to serve the request.
• If no regex locations are found that match, the previously stored prefix location is selected to serve the request.

 
Other things to note:

• Order of the regex matches do matter. This is because the first regex match gets used immediately.
• Internal redirect that get triggered inside location blocks. Some directives that might influence internal redirect.
• index
• error_page
• rewrite
• try_files
• A example of a index directive. With this example you can also see how the other above directives could be internally redirected and fall into another location block.

  index index.html;
  
  location = /matchme {
      ...
    }
  
  location / {
      ...
    }

   
  If you follow this you will see if the request is /matchme it would then need to do a internal redirect to
  /matchme/index.html. This match would then be handled by the second location block because it is no longer that exact match. So the index directive get inherited by the location block but if you needed to stay inside the first location block, you could do something like this.

  location = /matchme {
        index you_will_never_match_me;
        autoindex on;
    }

   
  You can see that the index file will not be found and autoindex of the directory would happen. Not the best way probably to do this, but explains how to bypass the inherited index and preventing it jumping to another location block.