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

1. server匹配規則

nginx的server塊可以配置多個，那么一個請求該匹配那個server塊呢，這主要是根據server塊的server_name和listen來決定的。其中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用戶默認8080server_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/ }

參考

• https://tengine.taobao.org/nginx_docs/cn/docs/http/request_processing.html
• http://tengine.taobao.org/book/chapter_02.html
• http://nginx.org/en/docs/http/ngx_http_rewrite_module.html
• http://www.nginx.cn/216.html
• http://www.ttlsa.com/nginx/nginx-rewriting-rules-guide/
• http://fantefei.blog.51cto.com/2229719/919431
• http://seanlook.com/2015/05/17/nginx-location-rewrite/

轉載于:https://www.cnblogs.com/wonyun/p/10309491.html

總結

以上是生活随笔為你收集整理的前端开发掌握nginx常用功能之serverlocation匹配规则的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。