Nginx location matching rules Detailed (3)

Nginx.conf lower segment file server, location uri hit rules for configuring and mapping result.

Syntax Rules

Grammar rule: location [= | ~ | ~ * | ^ ~ | @] / uri / {...}

  • =: Routine Exact Match
  • ^ ~: Regular characters match, the longest match principle, generally used for matching directory
  • ~: Case-sensitive matching canonical
  • ~ *: Regular case-insensitive match
  • ! ~ And ~ *:! Were no match is case-sensitive and case-insensitive regular mismatch
  • /: Tsuhaifu

Match Priority

location matching rules a bit complicated, first posted some official convention of priority:

To summarize, the order in which directives are checked is as follows:

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

Poor translation:

  1. Exact matches "=" prefix mode, if a hit is returned as the final result;
  2. All that remains to conventional string pattern matches, the longest match principle. If the hit, and the use of matching "^ ~" prefix, the result will be returned as the final result of the matching, otherwise continue with step 3 of the regular matching;
  3. For n in the order defined in the profile is matched, it is noted regular order in the physical location stressed configuration file;
  4. Rule 3 If a match, the result is used. Otherwise, the result of Rule 2.

This official explanation is not good for digestion, the need for further explanation, we must first avoid two errors:

1, the location of the matching sequence "first matches the regular, then matches the normal."
Correction: The reason for this misconception is: In some configurations, the regular match overrides ordinary match. The actual location of the matching sequence is actually "ordinary first match, and then matches the regular, ordinary hit may be covered by a regular hit."

2, location of order execution logic has nothing to do with the location of editing.
Correction: This sentence is not all right, "general location" matching rule is "maximum prefix" and therefore "normal location" really has nothing to do with the location to edit the order; but "regular location" matching rules "Sequential match, and as long as the match to matching the first stop behind a ";" normal location "and" regular location "sequence of matching is to match the normal location, and then" consider "matches the regular location. Note that the "consideration" is "possible" means, that is to say after the match finished "normal location", sometimes need to continue to match the "regular location", sometimes you do not need to continue to match the "regular location". In both cases, no need to continue to match the regular location: 1) When a specified location in front of the ordinary "^ ~" or "=", in particular section tells Nginx Once the general location match, there is no need to continue the regular matching; 2) when the normal location exactly match the strict, not the biggest prefix match, then no further matching regular.

To sum it up: "Regular concession strictly accurate location match the results of the general location of the match; but the greatest common prefix match results covering the location"
"The location Nginx matching rules explain", this blog made a very detailed analysis shows matching rules

Easy to remember the location of the matching simplified three categories: common internal location match, matching inside the regular location, the ordinary location matches the regular location. After splitting rules continue to receive the following individual:

  1. Priority match the general location, and then will match the regular location
  2. Normal location using "=" or "^ ~" syntax and the match is successful, stops subsequent matched, the current return hits as a final result
  3. And if not in Article 1, following the general location longest prefix match principle, if an exact match, then the current hits as the final result is returned, otherwise continue regular match; if not hit a regular match, taking ordinary matches, otherwise regular matches covering ordinary match result
  4. Internal general location match does not care about location in order to edit the configuration file, choose the optimal solution
  5. Regular care about location location inside the matching sequence in the configuration file editing, as long as a match to the regular location, location no longer consider editing later in the order
  6. Regular location closely matched exactly match the results of the general location of the concession; but cover the maximum prefix matches the general location of

Example understood in conjunction with the memory (Transfer Example: https://www.cnblogs.com/sign-ptk/p/6723048.html
):

location = / {  
   #规则A  
}  
location = /login {  
   #规则B  
}  
location ^~ /static/ {  
   #规则C  
}  
location ~ \.(gif|jpg|png|js|css)$ {  
   #规则D  
}  
location ~* \.png$ {  
   #规则E  
}  
location !~ \.xhtml$ {  
   #规则F  
}  
location !~* \.xhtml$ {  
   #规则G  
}  
location / {  
   #规则H  
}  

So the effect is as follows:

So the actual use, usually at least three matching rule is defined as follows:

#直接匹配网站根,通过域名访问网站首页比较频繁,使用这个会加速处理,官网如是说。  
#这里是直接转发给后端应用服务器了,也可以是一个静态首页  
# 第一个必选规则  
location = / {  
    proxy_pass http://tomcat:8080/index  
}  
   
# 第二个必选规则是处理静态文件请求,这是nginx作为http服务器的强项  
# 有两种配置模式,目录匹配或后缀匹配,任选其一或搭配使用  
location ^~ /static/ {  
    root /webroot/static/;  
}  
location ~* \.(gif|jpg|jpeg|png|css|js|ico)$ {  
    root /webroot/res/;  
}  
   
#第三个规则就是通用规则,用来转发动态请求到后端应用服务器  
#非静态文件请求就默认是动态请求,自己根据实际把握  
#毕竟目前的一些框架的流行,带.php,.jsp后缀的情况很少了  
location / {  
    proxy_pass http://tomcat:8080/  
}  

Guess you like

Origin blog.csdn.net/weixin_33720956/article/details/90827118