last 一直會繼續往下匹配,直到 “last”---->最後。。。
break------ 到這裏就中斷了,break出去了。。。
測試目錄:/work/code/src/frontend/nginx2
測試命令: docker run --name nginx2 -v /work/code/src/frontend/nginx2/nginx.conf:/etc/nginx/nginx.conf -v /work/code/src/frontend/nginx2/site1/:/usr/share/www -p 9000:9000 -d nginx
------------------------------------------------------------------------
build.sh
#!/bin/bash if [ -f "./Dockerfile" ]; then rm -f ./Dockerfile fi echo "FROM nginx:latest" >> ./Dockerfile echo "COPY ./dist /cpy/test-micro/base-dist" >> ./Dockerfile echo "COPY ./conf/nginx.conf /etc/nginx/" >> ./Dockerfile
docker build -t mynginx:v1 .
docker run --name ssnginx -p 7007:7007 -v /work/code/src/frontend/nginx/conf/nginx.conf:/etc/nginx/nginx.conf -d mynginx:v1
--------------------------------------------------------------------------
worker_processes auto; events { worker_connections 1024; } http { include /etc/nginx/mime.types; default_type application/octet-stream; log_format main '$remote_addr - $remote_user [$time_local] "$request" ' '$status $body_bytes_sent "$http_referer" ' '"$http_user_agent" "$http_x_forwarded_for"'; access_log /var/log/nginx/access.log main; sendfile on; #tcp_nopush on; keepalive_timeout 65; gzip on; server { listen 9000; server_name localhost; #charset koi8-r; #access_log /var/log/nginx/host.access.log main; root /usr/share/www/site1; location / { index index.html index.htm; } # 請求重定向測試 location /rewrite { add_header Content-Type 'text/html; charset=utf-8'; return 200 'message in rewrite'; } # last location /last { add_header Content-Type 'text/html; charset=utf-8'; rewrite ^/last /rewrite last; } # break location /break { add_header Content-Type 'text/html; charset=utf-8'; rewrite ^/break /rewrite2 last; #這裏如果是break, 就看不到下面的 message in rewrite2了。 而是404------------------------------------++++++++++++++++++++++++++++++++++============================== # rewrite ^/break http://iot.vidagrid.com break; } location /rewrite2 { add_header Content-Type 'text/html; charset=utf-8'; return 200 'message in rewrite2'; } # 臨時重定向 location /redirect { add_header Content-Type 'text/html; charset=utf-8'; rewrite ^ http://www.crane.run redirect; } # 永久重定向 location /permanent { add_header Content-Type 'text/html; charset=utf-8'; rewrite ^ http://www.crane.run permanent; } #error_page 404 /404.html; # redirect server error pages to the static page /50x.html # error_page 500 502 503 504 /50x.html; location = /50x.html { root /usr/share/nginx/html; } } }
原文:https://www.cnblogs.com/nonsec/p/13304147.html
參考:https://www.freesion.com/article/5608717826/
---------------------
nginx rewrite last和break區別
last 停止rewrite,如果沒有匹配到,會繼續向下匹配,如果匹配到,會重新發起匹配
break 停止rewrite,如果沒有匹配到,則不會向下匹配,返回404
root /www
location /break/ { default_type text/html; rewrite ^/break/(.*) /test/$1 break; } location /last/ { default_type text/html; rewrite ^/last/(.*) /test/$1 last; return 200 "last page"; } location /test/ { default_type text/html; return 200 "test page"; }
對於http://localhost/break/abc.html,如果/www/test目錄下不存在abc.html,會返回404錯誤
對於http://localhost/last/abc.html,會重新發起新請求,去匹配/test/$1即http://localhost/test/abc.html,會返回test page
--------------------------------------------------
本文使用之前製作的Docker容器<<Docker案例:搭建nginx服務>>演示Nginx四種重寫類型的區別和效果,如果尚未構建Docker服務可參考之前的文章,或者自建Nginx服務。
1 NGINX重寫簡介
Nginx重寫功能(Rewrite)由ngx_http_rewrite_module
模塊提供,可使用正則表達式改變請求的URI,返回重定向地址或內容,並可以根據條件選擇適當的配置。
1.1 REWRITE指令格式
重寫指令格式如下:
# 關鍵字 正則表達式 代替的內容 重寫類型
rewrite regex replacement [flag]
- 1
- 2
1.2 重寫類型
Nginx重寫類型 [flag]
有last
、break
、redirect
和permanent
四種,如下:
last
:本條重寫規則匹配完成後,終止匹配後續重寫規則,並重新發起請求繼續匹配新的location URI規則;瀏覽器地址欄URL地址不變break
:本條重寫規則匹配完成後,終止匹配後續重寫規則; 瀏覽器地址欄URL地址不變redirect
:返回302臨時重定向,瀏覽器地址會顯示重寫後的URL地址permanent
:返回301永久重定向,瀏覽器地址會顯示重寫後的URL地址
1.3 重寫配置
爲了演示四種重寫類型的不同,在nginx的配置中添加/last
、/break
、/redirect
、/permanent
、/rewrite
五個路由地址,完整配置如下:
server {
listen 80;
server_name localhost;
#charset koi8-r;
#access_log /var/log/nginx/host.access.log main;
root /usr/share/www/site1;
location / {
index index.html index.htm;
}
# 請求重定向測試
location /rewrite {
add_header Content-Type 'text/html; charset=utf-8';
return 200 'message in rewrite';
}
# last
location /last {
add_header Content-Type 'text/html; charset=utf-8';
rewrite ^/last /rewrite last;
}
# break
location /break {
add_header Content-Type 'text/html; charset=utf-8';
rewrite ^/break /rewrite break;
# rewrite ^/break http://www.crane.run break;
}
# 臨時重定向
location /redirect {
add_header Content-Type 'text/html; charset=utf-8';
rewrite ^ http://www.crane.run redirect;
}
# 永久重定向
location /permanent {
add_header Content-Type 'text/html; charset=utf-8';
rewrite ^ http://www.crane.run permanent;
}
#error_page 404 /404.html;
# redirect server error pages to the static page /50x.html
#
error_page 500 502 503 504 /50x.html;
location = /50x.html {
root /usr/share/nginx/html;
}
}
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
- 33
- 34
- 35
- 36
- 37
- 38
- 39
- 40
- 41
- 42
- 43
- 44
- 45
- 46
- 47
- 48
- 49
- 50
- 51
- 52
配置完成後,由於nginx服務在docker容器中,所以需要重新加載docker容器內nginx服務的配置,在宿主機執行如下docker指令:
docker exec -it nginx nginx -s reload
- 1
2 請求測試
下面通過瀏覽器訪問相關地址來測試上面幾種重寫類型。
2.1 LAST
訪問 http://localhost:8880/last,如上一步中的配置,請求重寫到/rewrite
路由,如下圖:
實際上重寫規則匹配成功之後,nginx又根據重寫路由發起了一個新的請求,並返回新請求的返回結果當做初始請求的結果
2.2 BREAK
訪問 http://localhost:8880/break,如上一步中的配置,請求重寫到/rewrite
路由,如下圖。
實際上重寫規則匹配成功之後,不再發起新的請求,也就不存在重新匹配location的過程,所以重寫的
/rewrite
路由對於當前請求來講是個不存在的資源;假如重寫的資源存在,例如替換爲可訪問的網絡地址,則請求是成功的
2.3 REDIRECT
訪問 http://localhost:8880/redirect,如上一步中的配置,Nginx返回302
臨時重定向狀態碼重定向到指定地址。瀏覽器地址變成重定向後的新地址。如下圖:
2.4 PERMANENT
訪問 http://localhost:8880/permanent,如上一步中的配置,Nginx返回301
永久重定向狀態碼重定向到指定地址。瀏覽器地址變成重定向後的新地址。如下圖:
2.5 停止NGINX服務
停止docker容器的nginx服務,指令如下:
docker stop nginx
- 1
停止nginx服務後,重新訪問http://localhost:8880/redirect
和http://localhost:8880/permanent
效果如下圖:
3 總結
通過上面的驗證,結合官方文檔,可見幾種重寫的區別:
break與last都停止處理後續重寫規則,只不過last會重新發起新的請求並使用新的請求路由匹配location,但break不會。所以當請求break時,如匹配成功,則請求成功,返回200;如果匹配失敗,則返回404。
服務器配置好redirect和permanent之後,打開瀏覽器分別訪問這兩個請求地址,然後停止Nginx服務。這時再訪問redirect請求會直接報出無法連接的錯誤。但是permanent請求是永久重定向,瀏覽器會忽略原始地址直接訪問永久重定向之後的地址,所以請求仍然成功。(這個驗證不能禁用瀏覽器的緩存,否則即使是permanent重定向,瀏覽器仍然會向原始地址發出請求驗證之前的永久重定向是否有效)
對於搜索引擎來說,搜索引擎在抓取到301永久重定向請求響應內容的同時也會將原始的網址替換爲重定向之後的網址,而對於302臨時重定向請求則仍然會使用原始的網址並且可能會被搜索引擎認爲有作弊的嫌疑。所以對於線上正式環境來講,儘量避免使用302跳轉
如果replacement以”http://”或”https://”或“$scheme”開始,處理過程將終止,並將這個重定向直接返回給客戶端。
4 參考
[1] 搞懂nginx的rewrite模塊
[2] 官方Rewrite文檔
[3] 301和302對SEO的影響