前端開發掌握nginx常用功能之server&location匹配規則

Nginx 前端開發 · 發表 2019-02-08 19:19:00

摘要： nginx主要是公司運維同學必須掌握的知識，涉及到反向代理、負載均衡等伺服器配置。前端開發尤其是純前端開發來說對nginx接觸的並不多，但是在一些情況下，nginx還是需要前端自己來搞；例如我們公司的開發環境和測試環境，雖然qa可以幫助搞定配置，但是每新增一個前端模組或者模組nginx配置經常...

nginx主要是公司運維同學必須掌握的知識，涉及到反向代理、負載均衡等伺服器配置。前端開發尤其是純前端開發來說對nginx接觸的並不多，但是在一些情況下，nginx還是需要前端自己來搞；例如我們公司的開發環境和測試環境，雖然qa可以幫助搞定配置，但是每新增一個前端模組或者模組nginx配置經常變更都求著qa搞，麻煩別人還不如自己來搞，這樣更能理解自己的需求。這些都需要前端開發對nginx有所理解，下面我們來說說nginx最基礎的server和location匹配規則。

1. server匹配規則

nginx的server 塊可以配置多個，那麼一個請求該匹配那個server塊呢，這主要是根據server塊的server_name 和listen 來決定的。其中server_name 僅僅檢查請求的“Host”頭以決定該請求應由哪個虛擬主機來處理。

先看一個例子：

server {
listen8001;
server_name *.net;
}

server {
listen8001;
server_name baidu.net;
}

server {
listen8001;
server_name baidu.*;
}

通過測試，發現相同listen埠 的情況下，多個server的匹配順序如下：

完全匹配優先順序最高，匹配則終止
萬用字元在前的優先順序其次 ，如*.com
萬用字元在後的優先順序次之 ，如baidu.*
正則匹配優先順序最低 ，如~^.www.test.com$

以上若都沒有匹配，那麼其會走預設的server，即：

優先選擇listen配置項後有default或default_server的server ，若沒有則：
找到匹配listen埠的第一個server塊

一種特殊情況，如果nginx中只為某個listen埠配置一個server塊的話，那麼nginx是不會根據該埠的server_name進行匹配的。因為只有一個server域，那麼根據上面沒有匹配的規則的情況下會走第一個匹配listen埠的server塊。

server {
listen8001;
server_name baidu.net;
}
server { # server沒有配置listen的話，root使用者預設是80埠，非root使用者預設8080
server_name server.com; 
}

如上面8001埠只有一個server的情況下，任何server_name訪問server_name:8001 都會匹配上面server塊（前提是server_name對應域名能請求到該機器上）。

另一種特殊情況，server塊配置的虛擬主機是基於域名和IP混合 的。如下所示：

server {
listen192.168.1.1:8001;
server_name example.org www.example.org;
...
}
server {
listen192.168.1.1:8002;
server_name example.com www.example.com;
...
}

這種情況下，其匹配順序是：

首先，看請求的IP地址和埠是否匹配某個server配置塊中的listen指令配置，匹配則命中該server塊，否則執行以下
其次，看請求的Host頭是否匹配這個server塊中的某個server_name的值，匹配這命中，否則走預設server。

第二點需要補充一下，看請求的Host頭是否匹配server_name，要滿足一個條件，即通過server_name指定的域名可以訪問到當前nginx配置所在的機器，因為通過域名訪問nginx所在的機器最終還是通過ip的形式來訪問的。

比如，訪問www.example.org，最終通過dns解析出nginx所在的ip地址來進行訪問的，又因為該server監聽8001埠，所以通過www.example.org:8001也可以命中192.168.1.1:8001所在的server塊。

2. location匹配規則

一個示例：

location= / {
# 精確匹配 / ，主機名後面不能帶任何字串
[ configuration A ]
}

location/ {
# 因為所有的地址都以 / 開頭，所以這條規則將匹配到所有請求
# 但是正則和最長字串會優先匹配
[ configuration B ]
}

location /documents/ {
# 匹配任何以 /documents/ 開頭的地址，匹配符合以後，還要繼續往下搜尋
# 只有後面的正則表示式沒有匹配到時，這一條才會採用這一條
[ configuration C ]
}

location ~ /documents/Abc {
# 匹配任何以 /documents/Abc 開頭的地址，匹配符合以後，還要繼續往下搜尋
# 只有後面的正則表示式沒有匹配到時，這一條才會採用這一條
[ configuration CC ]
}

location ^~ /images/ {
# 匹配任何以 /images/ 開頭的地址，匹配符合以後，停止往下搜尋正則，採用這一條。
[ configuration D ]
}

location ~* \.(gif|jpg|jpeg)$ {
# 匹配所有以 gif,jpg或jpeg 結尾的請求
# 然而，所有請求 /images/ 下的圖片會被 config D 處理，因為 ^~ 到達不了這一條正則
[ configuration E ]
}

location /images/ {
# 字元匹配到 /images/，繼續往下，會發現 ^~ 存在
[ configuration F ]
}

location /images/abc {
# 最長字元匹配到 /images/abc，繼續往下，會發現 ^~ 存在
# F與G的放置順序是沒有關係的
[ configuration G ]
}

location ~ /images/abc/ {
# 只有去掉 config D 才有效：先最長匹配 config G 開頭的地址，繼續往下搜尋，匹配到這一條正則，採用
[ configuration H ]
}

location ~* /js/.*/\.js {
# 不區分大小寫匹配
[ configuration I ]
}

=
^~
~
~*
/

location 順序 no優先順序：

關於location的優先順序需要認知三點：

先匹配普通location，後匹配正則location ；因為正則會覆蓋普通
普通location匹配與順序無關 ，因為採用最長匹配 原則；正則location匹配與順序有關 ，但是正則location依然採用最長匹配 原則
普通location指定了^~ 則一旦該普通規則匹配上，則不會進行後續匹配了，即使是正則匹配；= 嚴格匹配一旦匹配，也不會後續正則匹配

所以，location的優先順序如下：

(location =) > (location ^~ 路徑) > (location ~,~* 正則順序) > (location 完整路徑)>(location 部分起始路徑) > (/)

按照上面的location寫法，以下的匹配示例成立：

/ ->config A
精確完全匹配，即使/index.html也匹配不了
/downloads/download.html ->config B
匹配B以後，往下沒有任何匹配，採用B
/images/1.gif ->configuration D
匹配到F，往下匹配到D，停止往下
/images/abc/def ->config D
最長匹配到G，往下匹配D，停止往下
你可以看到任何以/images/開頭的都會匹配到D並停止，FG寫在這裡是沒有任何意義的，H是永遠輪不到的，這裡只是為了說明匹配順序
/documents/document.html ->config C
匹配到C，往下沒有任何匹配，採用C
/documents/1.jpg ->configuration E
匹配到C，往下正則匹配到E
/documents/Abc.jpg ->config CC
最長匹配到C，往下正則順序匹配到CC，不會往下到E

實際使用建議

所以實際使用中，個人覺得至少有三個匹配規則定義，如下：
#直接匹配網站根，通過域名訪問網站首頁比較頻繁，使用這個會加速處理，官網如是說。
#這裡是直接轉發給後端應用伺服器了，也可以是一個靜態首頁
# 第一個必選規則
location = / {
proxy_pass http://tomcat:8080/index
}
# 第二個必選規則是處理靜態檔案請求，這是nginx作為http伺服器的強項
# 有兩種配置模式，目錄匹配或字尾匹配,任選其一或搭配使用
location ^~ /static/ {
root /webroot/static/;
}
location ~* \.(gif|jpg|jpeg|png|css|js|ico)$ {
root /webroot/res/;
}
#第三個規則就是通用規則，用來轉發動態請求到後端應用伺服器
#非靜態檔案請求就預設是動態請求，自己根據實際把握
#畢竟目前的一些框架的流行，帶.php,.jsp字尾的情況很少了
location / {
proxy_pass http://tomcat:8080/
}

前端開發掌握nginx常用功能之server&location匹配規則

1. server匹配規則

2. location匹配規則

location 順序 no優先順序：

實際使用建議

參考

您可能也會喜歡…