今天深刻研究了下nginx的location的用法,已經一些須要注意的細節,如今作一個概括總結,以備後面查詢。html
$request_uri
格式 location [ 空格 | = | ~ | ~* | !~ | !~* ] /uri/ {} # 精確匹配: 相等(=) # 字符串匹配: 字符串匹配(空格) 匹配開頭(^~) # 正則匹配: 區分大小寫匹配(~) 不區分大小寫匹配(~*) 區分大小寫不匹配(!~) 不區分大小寫不匹配(!~*)
精確匹配 > 字符串匹配( 長 > 短 [ 注: ^~ 匹配則中止匹配 ]) > 正則匹配( 上 > 下 ) # 精確匹配只能命中一個 # 字符串匹配使用匹配最長的最爲匹配結果 # 正則匹配按照location定義的順序進行匹配,先定義具備高優先級
特別注意: 字符串匹配優先搜索,可是隻是記錄下最長的匹配 ( 若是 ^~ 是最長的匹配,則會直接命中,中止搜索正則 ),而後繼續搜索正則匹配,若是有正則匹配,則命中正則匹配,若是沒有正則匹配,則命中最長的字符串匹配.nginx
( 這裏使用了 echo-nginx-module 模塊,方便作輸出測試 )git
精確匹配 location = /images/test.png { echo 'config1'; } location /images/test.png { echo 'config2'; } location \/images\/test\.png$ { echo 'config3'; } 若是此時請求 http://127.0.0.1/images/test.png 會輸出什麼呢? 輸出 config1, 毋容置疑,精確匹配優先級最高!
精確匹配的特殊狀況 location = / { index index.html; } location / { echo 'config2'; } 此時是輸入http://127.0.0.1 會輸出什麼呢? 是輸出 config2, 怎麼精確匹配的優先級不靈了呢? 是這樣的,精確匹配仍是起做用了,請求目錄(非具體文件),nginx會將請求內部定向到index文件, 既此時真正的請求是http://127.0.0.1/index.html, 這是 config2則被命中! 因此精確匹配不要用來匹配 /
字符串搜索與正則搜索 location /images/test.png { echo 'config1'; } location ^~ /images/ { echo 'config2'; } location ~ \/images\/test\.png$ { echo 'config3'; } location ~ \/images\/ { echo 'config4'; } 若是此時請求 http://127.0.0.1/images/test.png 會輸出什麼呢? 固然是 config3,正則命中 (雖然 config1 爲最長匹配的字符串,此時只作記錄,後面還要搜索正則匹配,則config3正則匹配命中), 仔細觀察能夠發現config4也被匹配成功了,可是正則的匹配順序是按照location的定義順序匹配的,因此config3命中.
字符串匹配優先級的提高( ^~ ) location /images/ { echo 'config1'; } location ^~ /images/test.png { echo 'config2'; } location ~ /images/test\.png$ { echo 'config3'; } location ~ \/images\/ { echo 'config4'; } 若是此時請求 http://127.0.0.1/images/test.png 會輸出什麼呢? 固然是config2, 首部匹配命中 (由於字符串匹配是優先搜索的,此時發現config2 爲最長的字符串匹配且爲^~匹配方式,因此中止搜索正則,直接命中!)
# 因此這裏的 ^~ 符號比較特殊,就是爲了提升字符串匹配的優先級,優先於正則匹配.