Nginx 的 location 實現了對請求的細分處理，有些 URI 返回靜態內容，有些分發到後端服務器等，今天來徹底弄懂它的匹配規則
一個最簡單的 location 的例子如下
server {
server_name website.com;
location /admin/ {
# The configuration you place here only applies to
# http://website.com/admin/
}
}
複製代碼location 支持的語法 location [=|~|~*|^~|@] pattern { ... }，乍一看還挺複雜的，來逐個看一下。
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 prefix_match[uri] is '^~':
return prefix_match[uri]
else:
rv = prefix_match[uri] // 注意這裏沒有 return，且這裏是最長匹配
if uri in regex_match:
return regex_match[uri] // 按文件中順序，找到即返回
return rv
複製代碼一個簡化過的Node.js寫的代碼如下
function ngx_http_core_find_location(uri, static_locations, regex_locations, named_locations, track) {
let rc = null;
let l = ngx_http_find_static_location(uri, static_locations, track);
if (l) {
if (l.exact_match) {
return l;
}
if (l.noregex) {
return l;
}
rc = l;
}
if (regex_locations) {
for (let i = 0 ; i < regex_locations.length; i ++) {
if (track) track(regex_locations[i].id);
let n = null;
if (regex_locations[i].rcaseless) {
n = uri.match(new RegExp(regex_locations[i].name));
} else {
n = uri.match(new RegExp(regex_locations[i].name), "i");
}
if (n) {
return regex_locations[i];
}
}
}
return rc;
}
複製代碼案例分析
案例 1
server {
server_name website.com;
location /doc {
return 701; # 用這樣的方式，可以方便的知道請求到了哪裏
}
location ~* ^/document$ {
return 702; # 用這樣的方式，可以方便的知道請求到了哪裏
}
}
curl -I website.com:8080/document
HTTP/1.1 702
複製代碼按照上述的規則，第二個會有更高的優先級
案例2
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
正則匹配是使用文件中的順序，找到返回
本系列往期文章參考
Nginx系列教程（4）nginx處理web應用負載均衡問題以保證高併發
Nginx系列教程（5）如何保障nginx的高可用性(keepalived)