【轉】Nginx配置location總結及rewrite規則寫法

 轉載：https://segmentfault.com/a/1190000002797606

 http://www.cnblogs.com/lidabo/p/4169396.html

nginx 配置文件，自下到上分爲三種井井有條的結構：
 |    http block        the protocol level
 |   　　 server block        the server level
 V    　　　　location block        the requested URI

Nginx 容許用戶定義 Location block ，並指定一個匹配模式（pattern）匹配特定的 URI。除了簡單的字符串（好比文件系統路徑），還容許使用更爲複雜的匹配模式（pattern）。
Location block 的基本語法形式是：

location [=|~|~*|^~|@] pattern { ... }

[=|~|~*|^~|@] 被稱做 location modifier ，這會定義 Nginx 如何去匹配其後的 pattern ，以及該 pattern 的最基本的屬性（簡單字符串或正則表達式）。

location正則寫法

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 ] } location ~* /js/.*/\.js

• 已=開頭表示精確匹配
• 如 A 中只匹配根目錄結尾的請求，後面不能帶任何字符串。
• ^~ 開頭表示uri以某個常規字符串開頭，不是正則匹配
• ~ 開頭表示區分大小寫的正則匹配;
• ~* 開頭表示不區分大小寫的正則匹配
• / 通用匹配, 若是沒有其它匹配,任何請求都會匹配到

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

上面的匹配結果 按照上面的location寫法，如下的匹配示例成立：

• / -> configuration A
  精確徹底匹配，即便/index.html也匹配不了
• /downloads/download.html -> configuration B
  匹配B之後，往下沒有任何匹配，採用B
• /images/1.gif -> configuration D
  匹配到F，往下匹配到D，中止往下
• /images/abc/def -> configuration D
  最長匹配到G，往下匹配D，中止往下
  你能夠看到 任何以/images/開頭的都會匹配到D並中止，FG寫在這裏是沒有任何意義的，H是永遠輪不到的，這裏只是爲了說明匹配順序
• /documents/document.html -> configuration  C
  匹配到C，往下沒有任何匹配，採用C
• /documents/1.jpg -> configuration E
  匹配到C，往下正則匹配到E
• /documents/Abc.jpg -> configuration CC
  最長匹配到C，往下正則順序匹配到CC，不會往下到E

[ configuration A ] 精準匹配

這會徹底匹配指定的 pattern ，且這裏的 pattern 被限制成簡單的字符串，也就是說這裏不能使用正則表達式。

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

匹配狀況：

1. http://website.com/abcd        # 正好徹底匹配
2. http://website.com/ABCD        # 若是運行 Nginx server 的系統自己對大小寫不敏感，好比 Windows ，那麼也匹配
3. http://website.com/abcd?param1&param2    # 忽略查詢串參數（query string arguments），這裏就是 /abcd 後面的 ?param1&param2
4. http://website.com/abcd/    # 不匹配，由於末尾存在反斜槓（trailing slash），Nginx 不認爲這種狀況是徹底匹配
5. http://website.com/abcde    # 不匹配，由於不是徹底匹配

[ configuration B ] 精準匹配

能夠不寫 location modifier ，Nginx 仍然能去匹配 pattern 。這種狀況下，匹配那些以指定的 patern 開頭的 URI，注意這裏的 URI 只能是普通字符串，不能使用正則表達式。

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

匹配狀況：

1. http://website.com/abcd        # 正好徹底匹配
2. http://website.com/ABCD        # 若是運行 Nginx server 的系統自己對大小寫不敏感，好比 Windows ，那麼也匹配
3. http://website.com/abcd?param1&param2    # 忽略查詢串參數（query string arguments），這裏就是 /abcd 後面的 ?param1&param2
4. http://website.com/abcd/    # 末尾存在反斜槓（trailing slash）也屬於匹配範圍內
5. http://website.com/abcde    # 仍然匹配，由於 URI 是以 pattern 開頭的

[ configuration CC ] 正則匹配（區分大小寫）

這個 location modifier 對大小寫敏感，且 pattern 須是正則表達式

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

匹配狀況：

1. http://website.com/abcd        # 徹底匹配
2. http://website.com/ABCD        # 不匹配，~ 對大小寫是敏感的
3. http://website.com/abcd?param1&param2    # 忽略查詢串參數（query string arguments），這裏就是 /abcd 後面的 ?param1&param2
4. http://website.com/abcd/    # 不匹配，由於末尾存在反斜槓（trailing slash），並不匹配正則表達式 ^/abcd$
5. http://website.com/abcde    # 不匹配正則表達式 ^/abcd$

注意：對於一些對大小寫不敏感的系統，好比 Windows ，~ 和 ~* 都是不起做用的，這主要是操做系統的緣由。

[ configuration CD ] 正則匹配（不區分大小寫）

與 ~ 相似，但這個 location modifier 不區分大小寫，pattern 須是正則表達式

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

匹配狀況：

1. http://website.com/abcd        # 徹底匹配
2. http://website.com/ABCD        # 匹配，這就是它不區分大小寫的特性
3. http://website.com/abcd?param1&param2    # 忽略查詢串參數（query string arguments），這裏就是 /abcd 後面的 ?param1&param2
4. http://website.com/abcd/    # 不匹配，由於末尾存在反斜槓（trailing slash），並不匹配正則表達式 ^/abcd$
5. http://website.com/abcde    # 不匹配正則表達式 ^/abcd$

 

 

 

 

實際使用建議

因此實際使用中，我的以爲至少有三個匹配規則定義，以下： #直接匹配網站根，經過域名訪問網站首頁比較頻繁，使用這個會加速處理，官網如是說。 #這裏是直接轉發給後端應用服務器了，也能夠是一個靜態首頁 # 第一個必選規則
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/
}

 

普通匹配和正則匹配優先級：

若是咱們訪問：http://127.0.0.1:8080/image/aiai.png

此時, 「/」 與」/image/aiai.png」 匹配，同時,」image」正則 與」image/logo.png」也能匹配,誰發揮做用?

答案：正則表達式的成果將會使用！

　　　　location / { root D:\wnmp\www\html; index index.html index.htm index.php; } location ~ image { root D:\wnmp\www; //在這裏要注意了，若是location 正則寫image了則的 root 路徑中不能夠在次寫image index index.html; }

圖片真正會訪問:D:\wnmp\www\image\aiai.png (而不是：D:\wnmp\www\html\image\aiai.png)

 

普通長短優先級

咱們訪問 http://127.0.0.1:8080/foo

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

 對於uri 「/foo」,   兩個location的patt,都能匹配他們，即 ‘/’能從左前綴匹配 ‘/foo’, ‘/foo’也能左前綴匹配’/foo’，此時, 真正訪問 /var/www/html/index.html 緣由:’/foo’匹配的更長,所以使用之：

 

 

---

 

---

 

location ~ /hls123/(\d+).m3u8$ {
                #設置nginx變量
                set $a $1;
                echo $a "::a = : ${a}";
}

curl "http://localhost/hls123/4001489370813.m3u8"
4001489370813 ::a = : 4001489370813

以上的這種是能夠是接受參數的 $1 就是這參數

　　　　location ~ \/.+\/.+\.(m3u8|ts) {
                #設置nginx變量
                if ($uri ~ \/([a-zA-Z0-9]+)\/([a-zA-Z0-9]+)(|-).*\.(m3u8|ts)) {
                        set $app_name $1;
                        set $a $2;
                }
                echo "::document = : ${document_uri}";
                echo "::uri = : ${uri}";
                echo "::app_name = : ${app_name}";
                echo "::stream_name = : ${a}";
                #set $stream_id "";
                #default_type 'text/html';
                #lua_code_cache off;
                #rewrite_by_lua_file  /home/www/lua-tinywan/set_by_file.lua;
                #echo "stream_id :" $stream_id;
                #proxy_pass $stream_id;
        }

curl "http://localhost/hls123/4001489370813.m3u8"
::document = : /hls123/4001489370813.m3u8
::uri = : /hls123/4001489370813.m3u8
::app_name = : hls123
::stream_name = : 4001489370813

可使用上面的這個方法獲取須要的參數（不會）