语法

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. 再执行前缀匹配规则 ^~ uri 或 uri，不会立即返回，会先记下，看下面有没有优先级更高的
   • 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