nginx主要是公司運維同窗必須掌握的知識,涉及到反向代理、負載均衡等服務器配置。前端開發尤爲是純前端開發來講對nginx接觸的並很少,可是在一些狀況下,nginx仍是須要前端本身來搞;例如咱們公司的開發環境和測試環境,雖然qa能夠幫助搞定配置,可是每新增一個前端模塊或者模塊nginx配置常常變動都求着qa搞,麻煩別人還不如本身來搞,這樣更能理解本身的需求。這些都須要前端開發對nginx有所理解,下面咱們來講說nginx最基礎的server和location匹配規則。php
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的匹配順序以下:前端
以上若都沒有匹配,那麼其會走默認的server,即:nginx
一種特殊狀況,若是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
第二點須要補充一下,看請求的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塊。
一個示例:
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寫法,如下的匹配示例成立:
config A
config B
configuration D
config D
config C
configuration E
config CC
因此實際使用中,我的以爲至少有三個匹配規則定義,以下: #直接匹配網站根,經過域名訪問網站首頁比較頻繁,使用這個會加速處理,官網如是說。 #這裏是直接轉發給後端應用服務器了,也能夠是一個靜態首頁 # 第一個必選規則 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/ }