Location规则介绍

我参与11月更文挑战的第16天，活动详情查看：2021最后一次更文挑战

location修饰符类型

「=」 修饰符：要求路径完全匹配

server { server_name website.com; location = /abcd { […] } } http://website.com/abcd匹配\ http://website.com/ABCD可能会匹配 ，也可以不匹配，取决于操作系统的文件系统是否大小写敏感(case-sensitive)。ps: Mac 默认是大小写不敏感的，git 使用会有大坑。\ http://website.com/abcd?param1¶m2匹配，忽略 querystring\ http://website.com/abcd/不匹配，带有结尾的\ http://website.com/abcde不匹配

「~」修饰符：区分大小写的正则匹配

server { server_name website.com; location ~ ^/abcd$ { […] } } ^/abcd$这个正则表达式表示字符串必须以/开始，以$结束，中间必须是abcd

http://website.com/abcd匹配(完全匹配)\ http://website.com/ABCD不匹配，大小写敏感\ http://website.com/abcd?param1¶m2匹配\ http://website.com/abcd/不匹配，不能匹配正则表达式\ http://website.com/abcde不匹配，不能匹配正则表达式

「~*」不区分大小写的正则匹配

server { server_name website.com; location ~* ^/abcd$ { […] } } http://website.com/abcd匹配 (完全匹配)\ http://website.com/ABCD匹配 (大小写不敏感)\ http://website.com/abcd?param1¶m2匹配\ http://website.com/abcd/ 不匹配，不能匹配正则表达式\ http://website.com/abcde 不匹配，不能匹配正则表达式

修饰符：前缀匹配

如果该 location 是最佳的匹配，那么对于匹配这个 location 的字符串， 该修饰符不再进行正则表达式检测。注意，这不是一个正则表达式匹配，它的目的是优先于正则表达式的匹配\ 查找的顺序及优先级\ 当有多条 location 规则时，nginx 有一套比较复杂的规则，优先级如下：

精确匹配 =\ 前缀匹配 ^~(立刻停止后续的正则搜索)\ 按文件中顺序的正则匹配 ~或~*\ 匹配不带任何修饰的前缀匹配。

这个规则大体的思路是

先精确匹配，没有则查找带有 ^~的前缀匹配，没有则进行正则匹配，最后才返回前缀匹配的结果(如果有的话)

如果上述规则不好理解，可以看下面的伪代码(非常重要) ``` function match(uri): rv = NULL

if uri in exact_match:

return exact_match[uri]

if uri in prefix_match:

if prefixmatch[uri] is '^~': return prefixmatch[uri] else: rv = prefix_match[uri] // 注意这里没有 return，且这里是最长匹配

if uri in regex_match:

return regex_match[uri] // 按文件中顺序，找到即返回

return rv 一个简化过的Node.js写的代码如下 function ngxhttpcorefindlocation(uri, staticlocations, regexlocations, namedlocations, track) { let rc = null; let l = ngxhttpfindstaticlocation(uri, staticlocations, track);\ if (l) { if (l.exactmatch) { return l; } if (l.noregex) { return l; } rc = l; } if (regexlocations) { for (let i = 0 ; i < regexlocations.length; i ++) { if (track) track(regexlocations[i].id); let n = null; if (regexlocations[i].rcaseless) { n = uri.match(new RegExp(regexlocations[i].name)); } else { n = uri.match(new RegExp(regexlocations[i].name), "i"); } if (n) { return regexlocations[i]; } } } return rc; }

server { server_name website.com; location /doc { return 701; # 用这样的方式，可以方便的知道请求到了哪里 } location ~* ^/document$ { return 702; # 用这样的方式，可以方便的知道请求到了哪里

}

}

curl -I website.com:8080/document

```

按照上述的规则，第二个会有更高的优先级 server { server_name website.com; location /document { return 701; } location ~* ^/document$ { return 702; } }

curl -I website.com:8080/document

第二个匹配了正则表达式，优先级高于第一个普通前缀匹配 案例 3

server { server_name website.com; location ^~ /doc { return 701; } location ~* ^/document$ { return 702; } }

curl http://website.com/document HTTP/1.1 701 第一个前缀匹配^~命中以后不会再搜寻正则匹配，所以会第一个命中 案例 4 server { server_name website.com; location /docu { return 701; } location /doc { return 702; } } curl -I website.com:8080/document 返回 HTTP/1.1 701，

server { server_name website.com; location /doc { return 702; } location /docu { return 701; } } curl -I website.com:8080/document 依然返回 HTTP/1.1 701 前缀匹配下，返回最长匹配的 location，与 location 所在位置顺序无关 案例 5 ``` server { listen 8080; server_name website.com;

location ~ ^/doc[a-z]+ {
    return 701;
}

location ~ ^/docu[a-z]+ {
    return 702;
}

} curl -I website.com:8080/document 返回 HTTP/1.1 701\ 把顺序换一下 server { listen 8080; server_name website.com;

location ~ ^/docu[a-z]+ {
    return 702;
}

location ~ ^/doc[a-z]+ {
    return 701;
}

} ``` curl -I website.com:8080/document 返回 HTTP/1.1 702 正则匹配是使用文件中的顺序，找到返回

Linux 监控搭建方案

grafana+prometheus+nodeexporter+mysqlexporter+redis_exporter

具体细节百度

NGINX directory index of "" is forbidden

directory index of "" is forbidden

一直以为是权限问题，排查半天。

location / { index index.php; try_files $uri $uri/ /index.php$uri?$query_string; break; }

最后发现 index index.php 没写

DOCKER 权限不足

docker run -it --privileged -v /Users/liubb/html:/home/wwwroot -p 50007:80 1e1 /usr/sbin/init

关键: privileged /usr/sbin/init