Nginx location 指令

语法

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

结论

官方文档,配合实际验证:

简单总结:

  1. 执行顺序是:完整匹配(= uri) > 前缀匹配(^~ uri/uri) > 正则匹配(~/~*)。
  2. 优先级是:完整匹配 > 正则匹配 > 前缀匹配(越长优先级越高)。
  3. 完整匹配、正则匹配成功后直接返回,前缀匹配则不是。

详细说明:

  1. 先执行完整匹配规则 = uri,如果匹配成功(一字不差)就直接返回,不再继续匹配
  2. 再执行前缀匹配规则 ^~ uriuri,不会立即返回,会先记下,看下面有没有优先级更高的
    • uri^~ uri 同时出现会报 duplicate location,让人怀疑它俩是不是本来就相等。
    • 注意:按照规则长度,长的会覆盖短的(最大前缀规则)。
      不知道实际实现如何,总之,从结论上来看,可以理解成和配置文件书写顺序无关。
  3. 再正则匹配(~ 大小写敏感,~* 大小写不敏感)
    • 遇到一个匹配成功的就直接返回,与配置文件书写顺序有关
  4. 如果正则匹配全部失败,就采纳普通匹配结果,如果普通匹配也全部失败,就 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;
}
  1. 不用于请求路径的解析,而是用于请求重定向
  2. 不能被嵌套,也不能嵌套别的 location