ngnix的簡單轉發請求之server和location配置

巨大的建築，總是由一木一石疊起來的，我們何妨做做這一木一石呢？我時常做些零碎事，就是爲此。
這是對的，但是我沒有說過這句話！ —— 魯迅

簡單梳理一下nginx中關於server 和location的配置.
比如URL：www.mask_dev2.com:9999/login/
server管的前半部分，即：www.mask_dev2.com:9999
location管的是後半部分，即：/login/

一個nginx可以配置多個server。
每個server可以配置多個location。

URL的前半部分控制選擇哪一個server，後半部分控制選擇哪一個location，最終決定往哪裏去請求.

server的配置

server {
  listen 9999;
  server_name www.mask_dev2.cn;
  location / {
    default_type text/html;
    content_by_lua '
      ngx.say("<p>first</p>")
    ';
  }
}

server {
  listen  9999;
  server_name www.mask_dev2.*;
  location / {
    default_type text/html;
    content_by_lua '
      ngx.say("<p>second</p>")
    ';        
  }
}

server {
  listen 9998;
  server_name _;
  location / {
    default_type text/html;
    content_by_lua '
      ngx.say("<p>third</p>")
    ';

  }
}

首先，請求nginx的地址，肯定是請求的nginx所在的服務器，也就是說ip是固定的。
也就是說，無所謂server_name是什麼，都是指的當前服務器.
那麼當前服務器是怎樣對應多個域名呢，這個只需要在相應的dns服務器中進行添加，就行了，比如暫時把本機當成dns服務器，修改hosts

127.0.0.1 localhost
127.0.0.1 www.mask_dev2.cn
127.0.0.1 www.mask_dev2.com

server匹配順序

server_name與host匹配優先級如下：

1、完全匹配
2、通配符在前的，如*.test.com
3、在後的，如www.test.*
4、正則匹配，如~^\.www\.test\.com$

如果都不匹配

1、優先選擇listen配置項後有default或default_server的
2、找到匹配listen端口的第一個server塊

location配置

找到server之後，再去找具體的location

server {
  listen 9998;
  server_name _;
  location = / {  
    #規則A  
  }  
  location = /login {  
    #規則B  
  }  
  location ^~ /static/ {  
    #規則C  
  }  
  location ~ \.(gif|jpg|png|js|css)$ {  
    #規則D  
  }  
  location ~* \.png$ {  
    #規則E  
  }  
  location !~ \.xhtml$ {  
    #規則F  
  }  
  location !~* \.xhtml$ {  
    #規則G  
  }  
  location / {  
    #規則H  
  }  

語法規則：

location [=|_|*|^~] uri { … }

1. = 開頭表示精確匹配
2. ^~ 開頭表示uri以某個常規字符串開頭，理解爲匹配 url路徑即可。nginx不對url做編碼，因此請求爲/static/20%/aa，可以被規則^~ static /aa匹配到（注意是空格）。
3. ~ 開頭表示區分大小寫的正則匹配
4. ~* 開頭表示不區分大小寫的正則匹配
5. !_和!*分別爲區分大小寫不匹配及不區分大小寫不匹配 的正則
6. / 通用匹配，任何請求都會匹配到。
7. 多個location配置的情況下匹配順序爲（參考資料而來，還未實際驗證，試試就知道了，不必拘泥，僅供參考）：

首先匹配 =，其次匹配^~, 其次是按文件中順序的正則匹配，最後是交給 / 通用匹配。當有匹配成功時候，停止匹配，按當前匹配規則處理請求。

但是一般沒有這麼複雜，有3點。

1. 默認請求。
2. 頁面請求.
3. 後臺邏輯請求.

#直接匹配網站根，通過域名訪問網站首頁比較頻繁，使用這個會加速處理，官網如是說。  
#這裏是直接轉發給後端應用服務器了，也可以是一個靜態首頁  
# 第一個必選規則  
location = / {  
    proxy_pass http://tomcat:8080/index  
}  

# 第二個必選規則是處理靜態文件請求，這是nginx作爲http服務器的強項  
# 有兩種配置模式，目錄匹配或後綴匹配,任選其一或搭配使用  
location ~* \.(gif|jpg|jpeg|png|css|js|ico)$ {  
    root /webroot/res/;  
}  

#第三個規則就是通用規則，用來轉發動態請求到後端應用服務器  
#非靜態文件請求就默認是動態請求，自己根據實際把握  
#畢竟目前的一些框架的流行，帶.php,.jsp後綴的情況很少了  
location / {  
    proxy_pass http://127.0.0.1:8080/  
}  

總結

比如，現在同時啓動 前臺系統，和後臺系統，就可以用兩個server(可以配置host爲api,admin,或者直接修改端口也可以)，每個server中3個location來確定具體頁面的請求.