https://www.cnblogs.com/linjiqin/p/5532119.html
Location文法文法:location [=|~|~*|^~] /uri/ { … }
= --> 開頭表示精確匹配
^~ --> 開頭表示uri以某個常規字串開頭,理解為匹配url路徑即可。
nginx不對url做編碼,因此請求為/static/20%/aa,可以被規則^~ /static/ /aa匹配到(注意是空格)。
~ --> 開頭表示區分大小寫正則匹配
~* --> 開頭表示不區分大小寫正則匹配
!~和!~* --> 分別為區分大小寫不匹配及不區分大小寫不匹配的正則
/ --> 通用匹配,任何請求都會匹配到。
多個location配置的情況下匹配順序為:
首先匹配=,其次匹配^~, 其次是按檔案中順序的正則匹配,最後是交給 / 通用匹配。當有匹配成功時候,停止匹配,按當前匹配規則處理請求。
例子,有如下匹配規則:
location = / { #http://localhost/ 訪問根目錄/ #規則A}location = /login { #http://localhost/login #規則B}location ^~ /static/ { #http://localhost/static/a.html #http://localhost/static/c.png 則優先匹配到 規則C #規則C}#http://localhost/a.gif, http://localhost/b.jpg 將匹配規則D和規則E,但是規則D順序優先,規則E不起作用,location ~ \.(gif|jpg|png|js|css)$ { #規則D}location ~* \.png$ { #http://localhost/a.PNG 則匹配規則E,而不會匹配規則D,因為規則E不區分大小寫。 #規則E}http://localhost/a.xhtml 不會匹配規則F和規則G,http://localhost/a.XHTML 不會匹配規則G,因為不區分大小寫。規則F,規則G屬於排除法,符合匹配規則但是不會匹配到,所以想想看實際應用中哪裡會用到。location !~ \.xhtml$ { #規則F}location !~* \.xhtml$ { #規則G}訪問http://localhost/category/id/1111 最終匹配到規則H,因為以上規則都不匹配,這個時候應該是nginx轉寄請求給後端應用伺服器,比如FastCGI(php),tomcat(jsp),nginx作為方向Proxy 伺服器存在。location / { #http://localhost/register #規則H}
所以實際使用中,個人覺得至少有三個匹配規則定義,如下:
#直接匹配網站根,通過網域名稱訪問網站首頁比較頻繁,使用這個會加速處理,官網如是說。#這裡是直接轉寄給後端應用伺服器了,也可以是一個靜態首頁# 第一個必選規則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/}
對於以上基礎推薦配置,有一個補充,就是關於轉寄有一點需要注意。例如下面配置,對一個目錄轉寄:
location ^~ /outer/ { #case A: url最後以/結尾 proxy_pass http://tomcat:8080/ #case B: url最後沒有/ #proxy_pass http://tomcat:8080 }
關鍵在於最後的/,訪問localhost/outer/in.html,其中case A會轉寄到tomcat:8080/in.html, 而case B會轉寄到tomcat:8080/outer/in.html,所以務必注意了。