location匹配的是nginx的哪個變數？

$request_uri

location的匹配種類有哪些?

格式  location [ 空格 | = | ~ | ~* |^~|!~ | !~* ] /uri/ {}

• =開頭表示精確匹配
• ^~ 開頭,注意這不是一個正則表示式--它的目的是優於正則表示式的匹配。如果該location是最佳匹配，則不再進行正則表示式檢測。
• ~ 開頭表示區分大小寫的正則匹配;
• ~* 開頭表示不區分大小寫的正則匹配
• / 通用匹配, 如果沒有其它匹配,任何請求都會匹配到
• !~ && !~*：表示區分大小寫不匹配的正則和不區分大小寫的不匹配的正則

location搜尋順序

順序 no優先順序：(location =) > (location 完整路徑) > (location ^~ 路徑) > (location ~,~* 正則順序) > (location 部分起始路徑) > (/)

1.首先匹配=
2.其次匹配^~
3.再其次按照配置檔案的順序進行正則匹配、
4.最後是交給/進行通用匹配
注意：
當有匹配成功時，立刻停止匹配，按照當前匹配規則處理請求

特別注意： 字串匹配優先搜尋，但是隻是記錄下最長的匹配 ( 如果 ^~ 是最長的匹配，則會直接命中，停止搜尋正則 )，然後繼續搜尋正則匹配，如果有正則匹配，則命中正則匹配，如果沒有正則匹配，則命中最長的字串匹配.

舉例說明

精確匹配

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 為最長的字串匹配且為^~匹配方式，所以停止搜尋正則，直接命中！)

# 所以這裡的 ^~ 符號比較特殊，就是為了提高字串匹配的優先順序，優先於正則匹配.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

location  = / {
  # 精確匹配 / ，主機名後面不能帶任何字串
  [ configuration A ] 
}

location  / {
  # 因為所有的地址都以 / 開頭，所以這條規則將匹配到所有請求
  # 但是正則和最長字串會優先匹配
  [ configuration B ] 
}

location /documents/ {
  # 匹配任何以 /documents/ 開頭的地址，匹配符合以後，還要繼續往下搜尋
  # 只有後面的正則表示式沒有匹配到時，這一條才會採用這一條
  [ configuration C ] 
}

location ~ /documents/Abc {
  # 匹配任何以 /documents/ 開頭的地址，匹配符合以後，還要繼續往下搜尋
  # 只有後面的正則表示式沒有匹配到時，這一條才會採用這一條
  [ 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 ] 
}

• / -> 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/
}