博学笃行·盛德日新

【永福】nginx_conf中location的语法


nginx

location

Syntax:	location [ = | ~ | ~* | ^~ ] uri { ... }
location @name { ... }
Default:	—
Context:	server, location

Sets configuration depending on a request URI.
根据请求的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.
这个匹配是作用于一个正常的URI: 如解码后的%XX形式的请求, 是对...解析后的相对路径形式, 将2个或多个连续的/转换成单个/.

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匹配可以是定义为一个前缀字符串,也可以是一个正则表达式. 正则表达式使用»~
«表示忽略大小写匹配, 使用»~«表示大小写敏感匹配. 针对给定的请求, nginx首先检查使用前缀字符串形式的location配置, 在这些配置中, 最长匹配的location配置段将被选择或记忆. 正则表达式的location配置以其在配置文件中出现的顺序进行检查. 第一段匹配的到的正则表达式对应的location配置段将生效. 如果没有匹配到正则表达式, 那么之前记忆到的location段将被使用.

location blocks can be nested, with some exceptions mentioned below.
location 段可以被嵌套, 但下面会提到的几个例外.

For case-insensitive operating systems such as macOS and Cygwin, matching with prefix strings ignores a case (0.7.7). However, comparison is limited to one-byte locales.
对于一些大小写不敏感的操作系统(macOS和Cygwin), 匹配前缀字符串的时候会忽略大小写(0.7.7). 但是URI对比仅仅针对单字节字符环境.

Regular expressions can contain captures (0.7.40) that can later be used in other directives.
正则表达式可以包含捕获(0.7.40), 用于后面的其他指令.

If the longest matching prefix location has the “^~” modifier then regular expressions are not checked.
如果最长前缀匹配的location有»^~«修饰符, 则正则表达式将不会被检查.

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.
同理, 如果使用=修饰符表示精确匹配URI的location. 如果精确匹配, 则查询结束. 例: 如果/请求频繁, 定义一个 location = / 将会加速整个处理过程, 因为当第一次匹配的时候, 就结束了搜索对应的location. 这样的location显然不能进行嵌套.

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.
在版本0.7.1至0.8.41, 如果一个请求匹配了字符前缀location, 而又没有=^~修饰符, 正则表达式也不会被检查. (译注:这是0.7.1至0.8.41版本的bug)

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 ]
}

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.
请求/将会匹配配置A, 请求/index.html将会匹配配置B, 请求/documents/document.html将会匹配配置C, 请求/images/1.gif将会匹配配置D, 请求/documents/1.jpg将会匹配配置E.

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.
前缀@定义一个命名的location. 这个location不会被用于通常的请求处理, 只用于请求的重定向. 这个情况下不能进行嵌套, 也不能包含嵌套的location段.

If a location is defined by a prefix string that ends with the slash character, and requests are processed by one of proxy_pass, fastcgi_pass, uwsgi_pass, scgi_pass, memcached_pass, or grpc_pass, then the special processing is performed. 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是前缀字符串并以/结尾时, 这个请求是被proxy_pass, fastcgi_pass, uwsgi_pass, scgi_pass, memcached_pass, 或 grpc_pass, 进行处理时, 将有一个特殊的处理过程. 当一个请求的URI等于这串字符串(没有尾部的/), 将会产生一个永久重定向301到带有结尾的/的请求URI上. 如果这不是你想要的情况, 需要定义精确的URI和location配置:

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

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

原文地址

http://nginx.org/en/docs/http/ngx_http_core_module.html#location

评论