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

時間 2019-12-06

標籤前端開發掌握 nginx 經常使用功能 server&location server location 匹配規則欄目 Nginx 简体版

原文原文鏈接

nginx主要是公司運維同窗必須掌握的知識，涉及到反向代理、負載均衡等服務器配置。前端開發尤爲是純前端開發來講對nginx接觸的並很少，可是在一些狀況下，nginx仍是須要前端本身來搞；例如咱們公司的開發環境和測試環境，雖然qa能夠幫助搞定配置，可是每新增一個前端模塊或者模塊nginx配置常常變動都求着qa搞，麻煩別人還不如本身來搞，這樣更能理解本身的需求。這些都須要前端開發對nginx有所理解，下面咱們來講說nginx最基礎的server和location匹配規則。php

1. server匹配規則

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

先看一個例子：html

server {
    listen      8001;
    server_name *.net;
}

server {
    listen      8001;
    server_name baidu.net;
}

server {
    listen      8001;
    server_name baidu.*;
}

經過測試，發現相同listen端口的狀況下，多個server的匹配順序以下：前端

徹底匹配優先級最高，匹配則終止
通配符在前的優先級其次，如*.com
通配符在後的優先級次之，如baidu.*
正則匹配優先級最低，如~^.www.test.com$

以上若都沒有匹配，那麼其會走默認的server，即：nginx

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

一種特殊狀況，若是nginx中只爲某個listen端口配置一個server塊的話，那麼nginx是不會根據該端口的server_name進行匹配的。由於只有一個server域，那麼根據上面沒有匹配的規則的狀況下會走第一個匹配listen端口的server塊。web

server {
    listen    8001;
    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 {
    listen      192.168.1.1:8001;
    server_name example.org www.example.org;
    ...
}
server {
    listen      192.168.1.1:8002;
    server_name example.com www.example.com;
    ...
}

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

首先，看請求的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 ]
}

以= 開頭表示精確匹配，匹配則終止後續查找；如 A 中只匹配根目錄結尾的請求，後面不能帶任何字符串.
以^~ 開頭表示uri以某個常規字符串開頭，不是正則匹配，匹配則終止後續查找，包括正則匹配，它依然支持最長匹配原則
以~ 開頭表示區分大小寫的正則匹配;
以~* 開頭表示不區分大小寫的正則匹配
以/ 通用匹配, 若是沒有其它匹配,任何請求都會匹配到

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/
}