nginx configuration location match rule example

nginx configuration can be divided into the scope of the directive main, server, location these 3 kinds, this 3 person actually not in turn contain relationship, but the independent relationship, such as one only have main level scope of instructions, is unable to write in a server or location, some instruction module can have main, at the same time server, location three scopes, each module has main additionally, srv, loc the three levels of the configuration, main level configuration of 1 module is Shared for all server and location, srv level configuration is Shared for all location, location only has its own loc level configuration, which is why srv and loc level configuration of 1 module requires merge, while main level configuration does not require merge. It seems a little confusing here, but it is not difficult to distinguish main, server and location as a scope level and a principal, similar to the difference between an adjective and a name. The configuration relationship of nginx is understandable.

The & # 8203; 1 normally a request from url will be parsed by nginx to an location for processing. This parsing process can actually be divided into string matching and regular expression matching based on the configuration of location. For location way of organization, the simplest is directly will save them for a linked list, 1 1 when parsing url traversal can find location accordingly, but the efficiency is too low, so it is for a high performance server like nginx completely not desirable, nginx string matching location organization became a 3 x string sorting tree, and set up also takes into account the balance of the tree. Later in the article I'll cover the implementation of the source code in detail.

The & # 8203; First of all, I to the introduction of about 1 location types and matching rules, to nginx wiki (http: / / wiki. nginx. org/HttpCoreModule # location) example to do:

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.

The directive with the = prefix matches the query exactly. If found, stop searching.

All the remaining normal strings, the longest match. If this match USES ^〜 Prefix, search stops.

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

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

For example,

location = / { 
 #  Matches only "/". 
 [ configuration A ]  
} 
location / { 
 #  Matches any request, because all requests are "/" start  
 #  But longer character matching or regular expression matching will take precedence  
 [ configuration B ]  
} 
location ^~ /images/ { 
 #  Match any with  /images/  Start the request and stop the match   other location 
 [ configuration C ]  
} 
location ~* \.(gif|jpg|jpeg)$ { 
 #  Match with  gif, jpg, or jpeg Closing request .  
 #  But all  /images/  Directory requests will be made by  [Configuration C] To deal with .   
 [ configuration D ]  
} 

It can be seen that in the above example, there are 5 different types of location, among which the fourth one with the prefix "~" is location requiring regular matching, and nginx has different priority rules for these 5 different types of location when parsing url. The general rules are as follows:

1, the string matches exactly to an location with the "=" prefix, then stops, and this location configuration is used;

2, string match the remaining non-regular and non-special location, if match to some location with "^~" prefix, stop;

3. Regular matching. The matching order is the order that location appears in the configuration file. If it matches to a regular location, it stops and USES the location configuration. Otherwise, use the location configuration with the maximum string match obtained in step 2.

The & # 8203; For example, for the following request:

1, / - > Match exactly to the first location, stop the match, and use configuration A

2 / some other/url - > First, the prefix part of the string is matched to the second location, and then the regular match is performed. Obviously, the second location is not matched, then the configuration configurationB 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 is also matched with the prefix location, which is the largest string match for this url in the configuration file, and location is prefixed with "^~", so the regular match is no longer performed, and configuration C is finally used

4, / some/other/path to / 1. jpg - > First, the prefix part of the same string is matched to the second location, and then the regular match is performed. When the regular match is successful, congifuration D is used

Request URI example:

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

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

location matches the command

~ # squiggly line means perform a regular match, case - sensitive ~* # means perform a regular match, case insensitive ^~ #^~ means normal character matching, if this option matches, only this option matches, do not match other options, 1 is used to match the directory = # for exact matching of normal characters Define a named location for internal orientation, such as error_page, try_files

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

= the exact match will be processed in the first. If an exact match is found, nginx stops searching for other matches.

Normal character matching, regular expression rules and long block rules will be matched prior to the query, which means that if the item is matched, it needs to see if there is a regular expression match and a longer match.

^~ only matches this rule, nginx stops searching for other matches, otherwise nginx continues processing other location instructions.

Finally, match the instruction with "~" and "~*". If the corresponding match is found, nginx will stop searching for other matches. The verbatim matching instruction with the highest degree of matching is used when no regular expression is present or no regular expression is matched.