摘要：概述有定位的意思根據來進行不同的定位在虛擬主機的配置中是必不可少的可以把網站的不同部分定位到不同的處理方式上偽靜態反向代理負載均衡等等都離不開語法中括號可以不寫任何參數此時稱為一般匹配也可以寫參數因此大類型可以分為種精準匹配一般匹配正則匹配

location 有"定位"的意思, 根據Uri來進行不同的定位.
在虛擬主機的配置中,是必不可少的,location可以把網站的不同部分,定位到不同的處理方式上.偽靜態,反向代理,負載均衡等等都離不開location.

location [=|~|~*|^~] patt {}

中括號可以不寫任何參數,此時稱為一般匹配,也可以寫參數.因此,大類型可以分為3種：

location = patt {} [精準匹配]
location patt{}  [一般匹配]
location ~ patt{} [正則匹配]

完全匹配指定的 pattern ，且這里的 pattern 被限制成簡單的字符串，也就是說這里不能使用正則表達式.

server {
    server_name website.com;
    location = /abcd {
    […]
    }
}

http://website.com/abcd        # 正好完全匹配
http://website.com/ABCD        # 如果運行 Nginx server 的系統本身對大小寫不敏感，比如 Windows ，那么也匹配
http://website.com/abcd?param1    # 忽略查詢串參數（query string arguments）,也同樣匹配
http://website.com/abcd/    # 不匹配，因為末尾存在反斜杠（trailing slash），Nginx 不認為這種情況是完全匹配
http://website.com/abcde    # 不匹配，因為不是完全匹配

可以理解為左前綴匹配(like pattern%),這種情況下，匹配那些以指定的 patern 開頭的 URI，注意這里的 URI 只能是普通字符串，不能使用正則表達式.

server {
    server_name website.com;
    location /abcd {
    […]
    }
}

http://website.com/abcd        # 正好完全匹配
http://website.com/ABCD        # 如果運行 Nginx server 的系統本身對大小寫不敏感，比如 Windows ，那么也匹配
http://website.com/abcd?param1     # 忽略查詢串參數（query string arguments），這里就是 /abcd 后面的 ?param1
http://website.com/abcd/    # 末尾存在反斜杠（trailing slash）也屬于匹配范圍內
http://website.com/abcde    # 仍然匹配，因為 URI 是以 pattern 開頭的

對大小寫敏感(在window上無效)，且 pattern 須是正則表達式

server {
    server_name website.com;
    location ~ ^/abcd$ {
    […]
    }
}


http://website.com/abcd        # 完全匹配

http://website.com/ABCD        # 不匹配，~ 對大小寫是敏感的

http://website.com/abcd?param1     # 忽略查詢串參數（query string arguments），這里就是 /abcd 后面的 ?param1 

http://website.com/abcd/    # 不匹配，因為末尾存在反斜杠（trailing slash），并不匹配正則表達式 ^/abcd$

http://website.com/abcde    # 不匹配正則表達式 ^/abcd$

不區分大小寫，pattern 須是正則表達式

server {
    server_name website.com;
    location ~* ^/abcd$ {
    […]
    }
}

http://website.com/abcd        # 完全匹配

http://website.com/ABCD        # 匹配，這就是它不區分大小寫的特性

http://website.com/abcd?param1     # 忽略查詢串參數（query string arguments），這里就是 /abcd 后面的 ?param1 

http://website.com/abcd/    # 不匹配，因為末尾存在反斜杠（trailing slash），并不匹配正則表達式 ^/abcd$

http://website.com/abcde    # 不匹配正則表達式 ^/abcd$

匹配情況類似一般匹配，以指定匹配模式開頭的 URI 被匹配

分別為區分大小寫不匹配及不區分大小寫不匹配的正則

任何請求都會匹配到.

用于定義一個 Location 塊，且該塊不能被外部 Client 所訪問，只能被 Nginx 內部配置指令所訪問，比如 try_files or error_page

http://www.test.com/ 從域名后面(uri:http請求行的第二列)開始匹配,也就是/,匹配原則一般都是左前綴匹配,location / {} 能夠匹配所有HTTP 請求，因為任何HTTP 請求都必然是以"/"開始的,但是，正則location 和其他任何比"/"更長的普通location (location / {} 是普通location 里面最短的，因此其他任何普通location 都會比它更長，當然location = / {} 和 location ^~ / {} 是一樣長的）會優先匹,由此可見匹配的優先級可以總結為:

越詳細就越優先

是不是有點像css的選擇器?

Example1

# 首先看有沒有精準匹配,如果有,則停止匹配過程.
location = patt {
  config A
}
location / {
  root   /usr/local/nginx/html;
  index  index.html index.htm;
}

如果訪問http://test.com/
定位流程是　
1: 精準匹配中"/" ,得到index頁為index.htm
2: 再次訪問 /index.htm , 此次內部轉跳uri已經是"/index.htm",根目錄為/usr/local/nginx/html
3: 最終結果,訪問了 /usr/local/nginx/html/index.htm

Example2

location / {
   root   /usr/local/nginx/html;
   index  index.html index.htm;
}

location /foo {
    root /var/www/html;
    index index.html;
}

我們訪問 http://test.com/foo
對于uri "/foo", 兩個location的patt,都能匹配他們
即 "/"能從左前綴匹配 "/foo", "/foo"也能左前綴匹配"/foo",
此時, 真正訪問 /var/www/html/index.html
原因:"/foo"匹配的更長,因此使用之;

Example3

location ~ image {
    root /var/www/image;
    index index.html;
}

如果我們訪問 http://test.com/image/logo.png
此時, "/" 與"/image/logo.png" 匹配
同時,"image"正則 與"image/logo.png"也能匹配,誰發揮作用?
正則表達式的成果將會使用.因為此時的正則表達式更詳細
圖片真正會訪問 /var/www/image/logo.png

再次總結優先級序如下：

1. =
2. (None)    前提是 pattern 完全匹配 URI 的情況（不是只匹配 URI 的頭部,這點很重要）
3. ^~
4. ~ 或 ~*
5. (None) pattern 匹配 URI 的頭部

貌似與location的書寫順序無關? 但實際上還是有關系的

# 配置一
server {

 listen       9090;
 server_name  localhost;

 location ~ .html$ {
     allow all; 
 }  

 location ~ ^/prefix/.*.html$ {
     deny all;  
 }  

}


# 配置二
server {

   listen       9090;
   server_name  localhost;

   location ~ ^/prefix/.*.html$ {
       deny all;  
   }  

  location ~ .html$ {
       allow all; 
   } 
}

Location ~ ^/prefix/.*.html$ {deny all;} 表示正則 location 對于以 /prefix/ 開頭， .html 結尾的所有 URI 請求，都拒絕訪問； location ~.html${allow all;} 表示正則 location 對于以 .html 結尾的 URI 請求，都允許訪問. 實際上，prefix 的是 ~.html$ 的子集.

在"配置一 "下，兩個請求都匹配上 location ~.html$ {allow all;} ，并且停止后面的搜索，于是都允許訪問， 404 Not Found ；在"配置二 "下， /regextest.html 無法匹配 prefix ，于是繼續搜索 ~.html$ ，允許訪問，于是 404 Not Found ；然而 /prefix/regextest.html 匹配到 prefix ，于是 deny all ， 403 Forbidden .

1. =
2. (None)    前提是 pattern 完全匹配 URI 的情況（不是只匹配 URI 的頭部,這點很重要）
3. ^~
4. ~ 或 ~*
5. (None) pattern 匹配 URI 的頭部

越詳細就越優先,但是同優先級的情況下,按書寫順序誰先出現就以誰為準(就近原則)

依然和css選擇器的優先級很像...

http://www.ttlsa.com/nginx/ng...

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

# 第二個必選規則是處理靜態文件請求，這是nginx作為http服務器的強項
# 有兩種配置模式，目錄匹配或后綴匹配,任選其一或搭配使用
location ~ .*.(gif|jpg|jpeg|png|bmp|swf)$
{
    expires      30d;
}

location ~ .*.(js|css)?$
{
    expires      12h;
}

location ~ /.  
{
    deny all; # 其他的任意后綴都不讓其訪問;
}

#第三個規則就是通用規則，用來轉發動態請求到后端應用服務器
location /
{
    try_files $uri @apache; #try_files 將嘗試你列出的文件并設置內部文件指向
}

location @apache
{
    internal; # internal指令指定某個location只能被“內部的”請求調用，外部的調用請求會返回”Not found”
    proxy_pass http://127.0.0.1:88;
    
    proxy_connect_timeout 300s;
    proxy_send_timeout   900;
    proxy_read_timeout   900;
    proxy_buffer_size    32k;
    proxy_buffers     4 32k;
    proxy_busy_buffers_size 64k;
    proxy_redirect     off;
    proxy_hide_header  Vary;
    proxy_set_header   Accept-Encoding "";
    proxy_set_header   Host   $host;
    proxy_set_header   Referer $http_referer;
    proxy_set_header   Cookie $http_cookie;
    proxy_set_header   X-Real-IP  $remote_addr;
    proxy_set_header   X-Forwarded-For $proxy_add_x_forwarded_for;
}