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


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

1. server匹配規則

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

先看一個例子:

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,即:

  • 優先選擇listen配置項后有default或default_server的server,若沒有則:
  • 找到匹配listen端口的第一個server塊

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

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;
    ...
}

這種情況下,其匹配順序是:

  • 首先,看請求的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/
}

參考


免責聲明!

本站轉載的文章為個人學習借鑒使用,本站對版權不負任何法律責任。如果侵犯了您的隱私權益,請聯系本站郵箱yoyou2525@163.com刪除。



 
粵ICP備18138465號   © 2018-2025 CODEPRJ.COM