Nginx configuration location matching rules example explanation

The scope of nginx configuration instructions can be divided into three types: main, server, and location. In fact, these three are not included in sequence, but independent of each other. For example, a directive with only main-level scope cannot be written in a server or location. A certain instruction of a module can have main, server, and location scopes at the same time. In addition, each module has three levels of configuration: main, srv, and loc. The main-level configuration of a module is shared by all servers and locations, and the srv-level configuration is shared by all locations. Location has only its own independent loc-level configuration. This is why the srv and loc-level configurations of a module need to be merged, while the main-level configuration does not need to be merged. This may seem a bit confusing, but it is not difficult to understand the configuration relationship of nginx by distinguishing main, server, and location as a scope level and a subject, which is similar to the difference between an adjective and a name.

Generally speaking, when a request URL comes, nginx will parse it to a certain location for processing. This parsing process can actually be divided into two types: string matching and regular expression matching according to the location configuration. The simplest way to organize locations is to save them directly as a linked list. When parsing the URL, you can find the corresponding location by traversing them one by one. However, this is too inefficient and is completely undesirable for high-performance servers like nginx. nginx organizes the string-matching locations into a three-pronged string sorting tree, and the balance of the tree is also considered when it is established. I will introduce the implementation of the source code in detail later in the article.

First, let me briefly introduce the types and matching rules of location, using the example of nginx wiki (http://wiki.nginx.org/HttpCoreModule#location) as an example:

Location priority official documentation

• Directives with the = prefix that match the query exactly. If found, searching stops.
• All remaining directives with conventional strings, longest match first. If this match used the ^~ prefix, searching stops.
• Regular expressions, in order of definition in the configuration file.
• If #3 yielded a match, that result is used. Else the match from #2 is used.

= prefix matches this query exactly. If found, stop searching.

Of all the remaining regular strings, the longest match. If this match is prefixed with ^~, the search stops.

Regular expressions, in the order defined in the configuration file.

If rule 3 produces a match, the result is used. Otherwise, the same rules as from rule 2 are used.

For example

location = / { 
 # Only matches "/". 
 [ configuration A ]  
} 
location / { 
 # Matches any request, because all requests start with "/" # But longer character matches or regular expression matches will take precedence [ configuration B ]  
} 
location ^~ /images/ { 
 # Match any request starting with /images/ and stop matching other locations 
 [ configuration C ]  
} 
location ~* \.(gif|jpg|jpeg)$ { 
 # Matches requests ending with gif, jpg, or jpeg.  
 # But all requests to the /images/ directory will be handled by [Configuration C].   
 [ configuration D ]  
}

You can see that there are 5 different types of locations in the above example. The 4th location with a "~" prefix is ​​the location that needs regular matching. Nginx has different priority rules for these 5 different types of locations when parsing URLs. The general rules are as follows:

1. If the string exactly matches a location prefixed with "=", stop and use the configuration of this location;

2. The string matches the remaining non-regular and non-special locations. If a location with a "^~" prefix is ​​matched, stop;

3. Regular matching, the matching order is the order in which the locations appear in the configuration file. If a regular location is matched, stop and use the configuration of this location; otherwise, use the location configuration with the maximum string match obtained in step 2.

For example, for the following request:

1, / -> Exactly match the first location, match stops, use configuration A

2. /some/other/url -> First, the prefix part of the string is matched to the second location, and then a regular expression match is performed. Obviously, there is no match, so the configuration B of the second location is used.

3. /images/1.jpg -> First, the prefix part of the string matches the second location, but then the third location also matches the prefix. At this time, it is the maximum string match for this URL in the configuration file, and the location has a "^~" prefix, so no regular expression matching is performed, and configuration C is finally used.

4. /some/other/path/to/1.jpg -> First, the prefix part of the same string matches the second location, and then a regular expression is matched. If the regular expression matches successfully, congifuration D is used.

Request URI example:

/ -> Complies with configuration A
/documents/document.html -> matches configuration B
/images/1.gif -> matches configuration C
/documents/1.jpg -> matches configuration D
@location example error_page 404 = @fetch;

location @fetch(
proxy_pass http://fetch;
)

location matching command

• ~ #The wavy line indicates a regular match, case-sensitive
• ~* # indicates to perform a regular match, not case sensitive
• ^~ #^~ indicates ordinary character matching. If this option matches, only this option will be matched, and no other options will be matched. It is generally used to match directories.
• = # Perform an exact match of common characters
• @ #"@" defines a named location, used for internal targeting, such as error_page, try_files

The priority of location matching (regardless of the order of locations in the configuration file)

= Exact matches are processed first. If an exact match is found, nginx stops searching for further matches.

Ordinary character matching, regular expression rules and long block rules will be given priority over query matching, which means that if the item matches, it is necessary to see if there is a regular expression match and a longer match.

^~ only matches this rule and nginx stops searching for other matches. Otherwise, nginx continues to process other location instructions.

Finally, the instructions with "~" and "~*" are matched. If a corresponding match is found, nginx stops searching for other matches. When there is no regular expression or no regular expression is matched, the verbatim match instruction with the highest degree of match will be used.

This is the end of this article about the example of nginx configuration location matching rules. For more relevant content about nginx configuration location matching rules, please search for previous articles on 123WORDPRESS.COM or continue to browse the following related articles. I hope everyone will support 123WORDPRESS.COM in the future!