Home > Article > Web Front-end > 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.
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.
=
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.
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.
~ or
~* modifier in front.
= modifier, end the search and use its configuration.
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.
Using exact matching can improve the search speed. For example, if you frequently request /, you can use
= to define location.
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.
/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.
/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.
/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.
/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.
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?
/ 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
/. In other words,
/user/ and
/user are the same.
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.
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.
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!