nginx官网所解释的location配置规则

网上很多关于nginx中location配置规则的解释，但有一些不是很清楚，且容易造成混淆。今天看了下nginx官网上的解释，还是很清楚的，下面简单描述一下。

syntax:	location [ = | ~ | ~* | ^~ ] uri { ... } location @name { ... }
default:	—
context:	server, location

Sets configuration depending on a request URI.

The matching is performed against a normalized URI, after decoding the text encoded in the “%XX” form, resolving references to relative path components “.” and “..”, and possible compression of two or more adjacent slashes into a single slash.

A location can either be defined by a prefix string, or by a regular expression. Regular expressions are specified with the preceding “~*” modifier (for case-insensitive matching), or the “~” modifier (for case-sensitive matching). To find location matching a given request, nginx first checks locations defined using the prefix strings (prefix locations). Among them, the location with the longest matching prefix is selected and remembered. Then regular expressions are checked, in the order of their appearance in the configuration file. The search of regular expressions terminates on the first match, and the corresponding configuration is used. If no match with a regular expression is found then the configuration of the prefix location remembered earlier is used.

location blocks can be nested, with some exceptions mentioned below.

For case-insensitive operating systems such as Mac OS X and Cygwin, matching with prefix strings ignores a case (0.7.7). However, comparison is limited to one-byte locales.

Regular expressions can contain captures (0.7.40) that can later be used in other directives.

这段文字表明nginx中location配置只有两种情况，一种是字符串前缀匹配，另一种是正则匹配。正则匹配又分两种，“~”为区分大小写的，“~*”为不区分大小写的。

查找location的过程中，首先利用字符串前缀匹配，并且最长的匹配会被暂时记住。然后正则表达式会按照在nginx.conf文件中出现的顺序逐个匹配，当有一个匹配到时，就立即采用。若所有的都没匹配上，则采用之前记住的那个前缀匹配。

所以，一般字符串匹配式里都会有一个 location / {...}，来作为最最默认的一个。

If the longest matching prefix location has the “^~” modifier then regular expressions are not checked.

Also, using the “=” modifier it is possible to define an exact match of URI and location. If an exact match is found, the search terminates. For example, if a “/” request happens frequently, defining “location = /” will speed up the processing of these requests, as search terminates right after the first comparison. Such a location cannot obviously contain nested locations.

In versions from 0.7.1 to 0.8.41, if a request matched the prefix location without the “ =” and “ ^~” modifiers, the search also terminated and regular expressions were not checked.

这段文字表明，在字符串前缀匹配的过程中，还有两种特殊情况。

一个是有“~^”标示的，若最长前缀匹配式有“~^”标示，则立即采用，而不再进行正则匹配。但要注意的是，并不是说有“~^”标示的location会被优先匹配，若最长的匹配式不是它，那么它也不会被使用的。

另一个是有“=”标示的，这要求是完全匹配（不光是前缀），不能有嵌套，且一旦匹配上，则立即采用。

Let’s illustrate the above by an example:

location = / {
    [ configuration A ]
}

location / {
    [ configuration B ]
}

location /documents/ {
    [ configuration C ]
}

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

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

location /images/picture.html {   

    [ configuration F ]

}

The “/” request will match configuration A, the “/index.html” request will match configuration B, the “/documents/document.html” request will match configuration C, the “/images/1.gif” request will match configuration D, and the “/documents/1.jpg” request will match configuration E, the "/images/picture.html" will match configuration F.

这里是几个例子，注意其中的D和F。

The “@” prefix defines a named location. Such a location is not used for a regular request processing, but instead used for request redirection. They cannot be nested, and cannot contain nested locations.

If a location is defined by a prefix string that ends with the slash character, and requests are processed by one ofproxy_pass, fastcgi_pass, scgi_pass, uwsgi_pass, or memcached_pass, then in response to a request with URI equal to this string, but without the trailing slash, a permanent redirect with the code 301 will be returned to the requested URI with the slash appended. If this is not desired, an exact match of the URI and location could be defined like this:

location /user/ {
    proxy_pass http://user.example.com;
}

location = /user {
    proxy_pass http://login.example.com;

这里说明了named location规则，以“@”标示，不能有嵌套。不用于正常的请求处理，仅用于请求重定向。

最后所说的那个带“/”结尾的location，不知道用意何在？