Nginx location matching example sharing

This article mainly shares with you Nginx location matching examples. Since the team is separating the front-end and back-end, the front-end takes over the Nginx and node layers. In daily work, there is a lot of dealing with Nginx. I didn't know much about location matching rules before. In order to understand how location is matched, I hope it can help you.

Grammar rules

location [ = | ~ | ~* | ^~ ] uri { ... }
location @name { ... }

The grammar rules are very simple, a location keyword, followed by optional modifiers, followed by the characters to be matched, in curly brackets are The action to perform.

Modifier

• = indicates an exact match. A hit will only occur if the requested url path is exactly equal to the following string.

• #~ indicates that the rule is defined using regular expressions and is case-sensitive.

• ~* means that the rule is defined using regular expressions and is not case-sensitive.

• ^~ means that if the character after the symbol is the best match, this rule will be used and no subsequent search will be performed.

Matching process

Serializes the requested url. For example, decode characters such as %xx, remove multiple connected / in the URL, and parse ., ..## in the URL. #wait. This step is the preliminary work for matching.

location has two representation forms, one is to use prefix characters, and the other is to use regular expressions. If it is regular, there is

~ or ~* modifier in front.

The specific matching process is as follows:

First check the location defined using prefix characters, select the longest matching item and record it.

If an exact matching location is found, that is, a location that uses the

= modifier, end the search and use its configuration.

Then search locations defined using regular expressions in order. If they match, stop searching and use the configuration defined by it.

If there is no matching regular location, the longest matching prefix character location recorded previously is used.

Based on the above matching process, we can get the following two insights:

1. The order in which locations defined using regular expressions appear in the configuration file is very important. Because after the first matching regular pattern is found, the search stops, and subsequent regular patterns defined have no chance of matching again.

2. Using exact matching can improve the search speed. For example, if you frequently request /, you can use = to define location.

Example

Next we will use an example to explain the matching process in detail.

Suppose we have the following configuration file:

location = / {
    [ configuration A ]
}

location / {
    [ configuration B ]
}

location /user/ {
    [ configuration C ]
}

location ^~ /images/ {
    [ configuration D ]
}

location ~* \.(gif|jpg|jpeg)$ {
    [ configuration E ]
}

Request

/Exactly match A, no more searching.

Request

/index.htmlMatch B. First, search for matching prefix characters, find the longest matching configuration B, and then search for matching regular rules in order. The result is not found, so the longest match from the previous tag is used, which is configuration B.

Request

/user/index.htmlMatch C. First find the longest match C. Since there is no matching regular pattern later, the longest match C is used. Request
/user/1.jpgMatch E. First, search for the prefix characters to find the longest matching item C, then continue the regular search and find the matching item E. So use E.

Request

/images/1.jpgMatch D. First, search for prefix characters and find the longest match D. However, what is special is that it uses the ^~ modifier and no longer performs the subsequent regular matching search, so D is used. Here, if there are no previous modifiers, the final match is actually E. You can think about why.

Request

/documents/about.htmlMatch B. Because B means that any URL starting with / will match. In the above configuration, only B can satisfy it, so B is matched.

Usage of location @name

@ is used to define a named location. Mainly used for internal redirection and cannot be used to handle normal requests. Its usage is as follows:

location / {
    try_files $uri $uri/ @custom
}
location @custom {
    # ...do something
}

In the above example, when trying to access the url and unable to find the corresponding file, it will be redirected to our custom named location (custom here).

It is worth noting that the named location cannot nest other named locations.

Is the

/ at the end of the URL necessary?

There are three points about the

/ at the end of the URL that need to be explained. The first point is related to location configuration, and the other two points have nothing to do with it. It does not matter whether the characters in

1. include

   /. In other words, /user/ and /user are the same.

2. If the URL structure is in the form of

   https://domain.com/, no redirection will occur regardless of whether there is / at the end. Because the browser adds / by default when making a request. Although many browsers will not display / in the address bar. You can verify this by visiting Baidu.

3. If the structure of the URL is https://domain.com/some-dir/. Missing / at the end will result in redirection. Because according to the convention, the / at the end of the URL represents the directory, and the absence of / represents the file. Therefore, when accessing /some-dir/, the server will automatically go to this directory to find the corresponding default file. If you access /some-dir, the server will first look for the some-dir file. If it cannot find it, it will treat some-dir as a directory and redirect. Go to /some-dir/ and find the default file in that directory. You can test your website to see if it is like this.

Summary

There are two forms of location configuration, prefix characters and regular expressions. When searching for a match, first search for the prefix character, select the longest match, and then search for the regular pattern. Regular characters have higher priority than prefix characters.

Regular searches are performed in the order in the configuration file. Therefore, the order of regular expressions is very important. It is recommended that the more detailed ones be placed first.

Using =exact matching can speed up the search sequence. If the root domain name is frequently accessed, it is recommended to use =.

Related recommendations:

Javascript refresh page method and location.reload() usage introduction

Completely master $location## in AngularJS

#php program header location jump notes

The above is the detailed content of Nginx location matching example sharing. For more information, please follow other related articles on the PHP Chinese website!