语法
Syntax : location [ = | ~ | ~* | ^~ ] uri { ... }
location @name { ... }
Default: —
Context: server, location
测试环境
server {
listen 8888;
# location ~ /foo/bar { return 501; }
# location ~* /foo/bar { return 502; }
# location = /foo/bar { return 503; }
# location ^~ /foo/bar { return 504; }
# location /foo/bar { return 505; }
}
各种排列组合,重启服务,然后分别:
curl http://localhost:8888/foo/bar/a
curl http://localhost:8888/foo/bar
结论
官方文档,配合实际验证:
简单总结:
- 执行顺序是:完整匹配(
= uri
) > 前缀匹配(^~ uri
/uri
) > 正则匹配(~
/~*
)。 - 优先级是:完整匹配 > 正则匹配 > 前缀匹配(越长优先级越高)。
- 完整匹配、正则匹配成功后直接返回,前缀匹配则不是。
详细说明:
- 先执行完整匹配规则
= uri
,如果匹配成功(一字不差)就直接返回,不再继续匹配 - 再执行前缀匹配规则
^~ uri
或uri
,不会立即返回,会先记下,看下面有没有优先级更高的uri
和^~ uri
同时出现会报 duplicate location,让人怀疑它俩是不是本来就相等。- 注意:按照规则长度,长的会覆盖短的(最大前缀规则)。
不知道实际实现如何,总之,从结论上来看,可以理解成和配置文件书写顺序无关。
- 再正则匹配(
~
大小写敏感,~*
大小写不敏感)- 遇到一个匹配成功的就直接返回,与配置文件书写顺序有关
- 如果正则匹配全部失败,就采纳普通匹配结果,如果普通匹配也全部失败,就 404
关于 @name
命名规则
location / {
error_page 404 = @fallback;
}
location @fallback {
proxy_pass http://backend;
}
location / {
try_files /system/maintenance.html
$uri $uri/index.html $uri.html
@mongrel;
}
location @mongrel {
proxy_pass http://mongrel;
}
- 不用于请求路径的解析,而是用于请求重定向
- 不能被嵌套,也不能嵌套别的 location