nginx中location的匹配模式有以下幾種：

• 精確匹配：以=開頭，只有完全匹配才能生效，例子location = /uri

• 非正則匹配：以^~開頭，^表示非、~表示正則，例子location ^~ /uri

• 正則匹配：

  • 以~開頭，表示區分大小寫的正則匹配，例子location ~ pattern
  • 以!~開頭，表示區分大小寫不匹配的正則，例子location !~ pattern
  • 以~*開頭，表示不區分大小寫的正則匹配，例子location ~* pattern
  • 以!~*開頭，表示不區分大小寫不匹配的正則，例子location !~* pattern

• 普通匹配：不帶任何修飾符，例子location /uri、location /

我們暫且把非正則匹配和普通匹配稱為前綴匹配

1 匹配模式優先級

location = /uri 　　　=開頭表示精確匹配，只有完全匹配上才能生效。
location ^~ /uri 　　^~ 開頭對URL路徑進行前綴匹配，并且在正則之前。無正則普通匹配（^ 表示“非”，~ 表示“正則”，字符意思是：不要繼續匹配正則）
location ~ pattern 　~開頭表示區分大小寫的正則匹配。!~為區分大小寫不匹配的正則
location ~* pattern 　~*開頭表示不區分大小寫的正則匹配。!~*為不區分大小寫不匹配的正則
location /uri 　　　　不帶任何修飾符，也表示前綴匹配，但是在正則匹配之后。
location / 　　　　　通用匹配，任何未匹配到其它location的請求都會匹配到，相當于switch中的default。

注意： 前綴匹配，如果有包含關系時，按最大匹配原則進行匹配。比如在前綴匹配：location /dir1與location /dir1/dir2，如有請求http://localhost/dir1/dir2/file將最終匹配到location /dir1/dir2

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

上述的優先級不完全正確

具體規則：

等號類型（=）的優先級最高。一旦匹配成功，則不再查找其他location的匹配項

剩下的幾種匹配優先級略復雜，具體可以查看Nginx官方文檔（http://nginx.org/en/docs/http/ngx_http_core_module.html#location）

• ^~和普通匹配。

  使用前綴匹配，不支持正則表達式，如果有多個location匹配成功的話，不會終止匹配過程，會記憶表達式最長的那個。

• 如果上一步得到的最長的location為^~類型，則表示阻斷正則表達式，不再匹配正則表達式

• 如果上一步得到的最長的location不是^~類型，繼續匹配正則表達式，只要有一個正則成功，則使用這個正則的location，立即返回結果，并結束解析過程

“最長”命中

^~和普通命中，都是優先使用匹配最長的結果，示例如下：

例子1

location /test_1 {
    return 400;
}
location ^~ /test {
    return 401;
}

如上如果path為/test_1，返回的是400，說明^~優先級并不比普通匹配高

例子2

location /test_1 {
    return 400;
}
location ^~ /test {
    return 401;
}
location ~ /test {
    return 402;
}

如上如果path為/test_1，返回的是402，此時^~和普通匹配只記住了最長一個location /test_1，不會阻止正則

如果path為/test，返回401，此時^~和普通匹配只記住了最長一個location ^~ /test，會阻止正則

2 路徑替換

規則

配置proxy_pass時，可以實現URL路徑的部分替換。

proxy_pass的目標地址，默認不帶/，表示只代理域名，url和querystring部分不會變（把請求的path拼接到proxy_pass目標域名之后作為代理的URL）。

如果在目標地址后增加/，則表示把path中location匹配成功的部分剪切掉之后再拼接到proxy_pass目標地址。

比如請求 /a/b.html

location /a {
    proxy_pass http://server;
}

location /a/ {
    proxy_pass http://server/;
}

如上兩個匹配成功后，實際代理的目標url分別是

http://server/a/b.html (把/a/b.html拼接到http://server之后)

http://server/b.html (把/a/b.html的/a/去掉之后，拼接到http://server/之后)

通過 Nginx Server 訪問 http://nginx/nginx_location/some/path

proxy_pass直接映射到主機的 /test

建議location和proxy_pass后面都加上/，否則容易引起混亂。

location	proxy_pass	實際訪問目標
/nginx_location/	http://server/test/	http://server/test/some/path

要求

注意的是，對于location為正則表達式的匹配，proxy_pass的目標地址不可以帶/

比如，如下配置會報錯：

location ~ /abc(.*) {
    proxy_pass   http://127.0.0.1/;
}

如果是正則表達式，想要實現proxy_pass的路徑替換，可以使用如下方式：

location ~ /abc(.*) {
    proxy_pass   http://127.0.0.1/$1;
}

3 root和alias的使用

nginx指定文件路徑有兩種方式root和alias，

root與alias主要區別在于nginx如何解釋location后面的uri，

這會使兩者分別以不同的方式將請求映射到服務器文件上。

3.1 最基本的區別

alias 指定的目錄是準確的，給location指定一個目錄。

root 指定目錄的上級目錄，并且該上級目錄要含有locatoin指定名稱的同名目錄。

以root方式設置資源路徑：

語法: root path;
配置塊: http、server、location、if

以alias 方式設置資源路徑

語法: alias path;
配置塊: location

Example:

location /img/ {
	alias /var/www/image/;
}
#若按照上述配置的話，則訪問/img/目錄里面的文件時，ningx會自動去/var/www/image/目錄找文件
location /img/ {
	root /var/www/image;
}
#若按照這種配置的話，則訪問/img/目錄下的文件時，nginx會去/var/www/image/img/目錄下找文件

注意：

1.使用alias時，目錄名后面一定要加”/“。
2.使用alias標簽的目錄塊中不能使用rewrite的break。
3.alias在使用正則匹配時，必須捕捉要匹配的內容并在指定的內容處使用。
4.alias只能位于location塊中

所以使用nginx設置root時要注意一個問題，就是如果該root設置的前端目錄不是根目錄，那么在寫root的絕對地址時，要把前端目錄的部分省略掉。 我們用設置虛擬目錄指向的alias來和root比較一下就非常明顯了

location /abc/ {   alias /home/html/abc/; }  

在這段配置下，http://test/abc/a.html就指定的是 /home/html/abc/a.html。這段配置亦可改成

location /abc/ {   root /home/html/;} 

可以看到，使用root設置目錄的絕對路徑時，少了/abc,也就是說，使用root來設置前端非根目錄時，nginx會組合root和location的路徑,即 /home/html/abc/。

4 try_files指令

Syntax:	try_files file ... uri;
try_files file ... =code;
Default:	—
Context:	server, location

示例

try_files $uri $uri/ /test/;

功能：依次試圖訪問多個url對應的文件（由root或者alias指令指定），當文件存在是直接返回文件內容，如果所有文件都不存在，則按最后一個URL結果或者code返回

5 stub_status

配置示例

location /basic_status {
	stub_status;
}

ngx_http_stub_status_module模塊內建的狀態頁 用于輸出nginx的基本狀態信息；

server{
....
	location /ngxstatus {
		stub_status;
	}
}

信息頁返回數值：

Active connections: 291
server accepts handled requests
16630948 16630948 31070465
Reading: 6 Writing: 179 Waiting: 106

• Active connections: 活動狀態的連接數；
• accepts：已經接受的客戶端請求的總數；
• handled：已經處理完成的客戶端請求的總數；
• requests：客戶端發來的總的請求數；
• Reading：處于讀取客戶端請求報文首部的連接的連接數；
• Writing：處于向客戶端發送響應報文過程中的連接數；
• Waiting：處于等待客戶端發出請求的空閑連接數；