rewrite reg replacementlocation ~ /zlocation ~ /zzcom改為了xcom，並且沒有location匹配上xcom，此時會直接去/html目錄下找/xcom/index.html。
訪問日誌如下：
瀏覽器位址改變，傳送了兩次請求。debuger發現瀏覽器傳送了兩次請求：
從日誌分析，首先匹配location ~ /a，結果被rewrite到了/b，此時會使用/b重新匹配所有location（注意是所有，包括剛匹配過的/a，有的文章說是匹配其他的，後續會說明）。接著匹配到了/b，rewrite到了/c，所以繼續重新匹配所有location，這一次匹配到了/c，/c中沒有繼續rewrite，此時nginx通知瀏覽器rewrite的最終位址是/c，於是瀏覽器重定向傳送請求：訪問到最終資源。
上面說的每次rewrite會重新匹配所有location，說法是否正確，這裡給出證明，我們把上面配置的location /a和location /b改為如下：
location ~ /a
location ~ /ab
/a會報錯無限迴圈：
假如每次rewrite是繼續匹配後續的location，根據上面的配置，會繼續匹配到/ab，然後uri被重寫到、為/c，肯定不會出現死迴圈。
訪問日誌如下：
我們發現location /a中rewrite語句後的語句沒有執行，因為 ** 沒有輸出。所以last的指令的用途就是停止執行rewrite的後續語句。其他跟預設情況沒什麼區別。
訪問日誌如下：
我們可以看到瀏覽器傳送了三次請求，前兩個都是301重定向：
結合日誌，我們來分析下這種情況，首先在location /a中，執行rewrite時，因為有break指令，本次請求結束，訪問日誌可以看出。所以nginx立即返回當前rewrite的資源，即/b，，瀏覽器就會訪問此時匹配到了location /b在location /b中，rewrite到了/c，所以第二次訪問執行了location /b和location /c，location /c中沒有rewrite了，所以nginx把rewrite的最終結果/c返回給瀏覽器，瀏覽器於是重定向到，此時匹配location /c，得到最終結果。
location ~ /a所以當乙個location中有多個rewrite時，在預設情況下，會先依次執行完。
Nginx中的rewrite指令
rewite 在server塊下，會優先執行rewrite部分，然後才會去匹配location塊 server中的rewrite break和last沒什麼區別，都會去匹配location，所以沒必要用last再發起新的請求，可以留空.location中的rewirte 不寫last和break 那...
Nginx中的rewrite指令
rewite 在server塊下，會優先執行rewrite部分，然後才會去匹配location塊 server中的rewrite break和last沒什麼區別，都會去匹配location，所以沒必要用last再發起新的請求，可以留空.location中的rewirte 不寫last和break 那...
Nginx中的rewrite指令
rewite 在server塊下，會優先執行rewrite部分，然後才會去匹配location塊 server中的rewrite break和last沒什麼區別，都會去匹配location，所以沒必要用last再發起新的請求，可以留空.location中的rewirte 不寫last和break 那...