论坛 › nginx › nginx rewrite模块探究与实验

nosilence 发表于 2018-11-15 06:15:43

nginx rewrite模块探究与实验

　　关于nginx中的rewrite，之前的理解总感觉有些不精确。比如以下问题，经过rewrite之后：
　　什么情况会返回200？
　　什么情况会返回301/302？
　　什么情况浏览器里的url不变？
　　什么情况浏览器里的url会变？
　　什么情况匹配一次就不再匹配之后的规则或location？
　　什么情况匹配到一条规则后，会以rewrite之后的url再到server段走一遍
　　如果读者能理解清楚以上问题，则说明对nginx的rewrite整体上已经有了全面的认识。
　　接下来我们针对以上问题，来通过试验逐一解答
　　实验环境：nginx 1.8
　　网站根目录：nginx/html
　　注：在http段或者server段添加rewrite_log on;并且设置error_log为notice级别，可以在error og里捕捉到rewrite的过程
　　一、先实验一个最简单的：http://172.16.25.162/ljk.html。该文件不在在html下，而在在html/wordpress下
　　server {
　　listen      80;
　　server_namelocalhost;
　　rewrite_log on;
　　location / {
　　root   /usr/local/nginx/html;
　　indexindex.shtml index.php index.html;
　　if (!-e $request_filename) {
　　rewrite ^/(.+\..+)$ /wordpress/$1;
　　}
　　}
　　观察nginx访问日志和错误日志
　　access_log:
　　"GET /ljk.html HTTP/1.1" 200
　　error_log:
　　*98 "^/(.+\..+)$" matches "/ljk.html", client: 172.16.25.3, server: localhost, request: "GET /ljk.html
　　*98 rewritten data: "/wordpress/ljk.html", args: "", client:172.16.25.3, server: localhost, request: "GET /ljk.html
　　浏览器里的url没有改变，状态码返回200

　　由此可见，如此配置实现了一个最简单的内部跳转。
　　二、再进一步，看一个两级的rewrite。将html/wordpress/下的ljk.html移到html/ljk/下，并且在location /wordpress 下配置重写规则
　　location / {
　　root   /usr/local/nginx/html;
　　indexindex.shtml index.php index.html;
　　if (!-e $request_filename) {
　　rewrite ^/(.+\..+)$ /wordpress/$1;
　　}
　　}
　　location /wordpress{
　　if (!-e $request_filename) {
　　rewrite ^/wordpress/(.+\..+)$ /ljk/$1;
　　}
　　}
　　access_log:
　　"GET /ljk.html HTTP/1.1" 200
　　error_log:可以看到两次匹配与重写的过程
　　*99 "^/(.+\..+)$" matches "/ljk.html", client: 172.16.25.3, server: localhost, request: "GET /ljk.html
　　*99 rewritten data: "/wordpress/ljk.html", args: "", client:172.16.25.3, server: localhost, request: "GET /ljk.html
　　*99 "^/wordpress/(.+\..+)$" matches "/wordpress/ljk.html", client: 172.16.25.3, server: localhost, request: "GET /ljk.html
　　*99 rewritten data: "/ljk/ljk.html", args: "", client: 172.16.25.3, server: localhost, request: "GET /ljk.html
　　浏览器url依然不变

　　以上两个实验对用户透明，用户通过返回码或者地址栏url均不可感知rewrite的存在，可以看做‘内部重定向’；那么什么时候会产生‘外部重定向’呢，现在先试试Permanent、redirect两个标志
　　三、重写规则后加上 permanent 标志
　　location / {
　　root   /usr/local/nginx/html;
　　indexindex.shtml index.php index.html;
　　if (!-e $request_filename) {
　　rewrite ^/(.+\..+)$ /wordpress/$1 permanent;
　　}
　　}
　　访问http://172.16.25.162/ljk.html
　　access_log:
　　GET /ljk.html HTTP/1.1" 301   返回301
　　GET /wordpress/ljk.html HTTP/1.1" 200
　　注意此处产生了两个请求
　　error_log:
　　*107 "^/(.+\..+)$" matches "/ljk.html", client: 172.16.25.3, server: localhost, request: "GET /ljk.html
　　*107 rewritten redirect: "/wordpress/ljk.html", client: 172.16.25.3, server: localhost, request: "GET /ljk.html
　　浏览器地址栏变成了rewrite后的url

　　四、重写规则后加上 redirect 标志
　　location / {
　　root   /usr/local/nginx/html;
　　indexindex.shtml index.php index.html;
　　if (!-e $request_filename) {
　　rewrite ^/(.+\..+)$ /wordpress/$1 redirect;
　　}
　　access_log:    两个请求
　　"GET /ljk.html?sds HTTP/1.1" 302    临时重定向302
　　"GET /wordpress/ljk.html HTTP/1.1" 200
　　error_log:
　　*108 "^/(.+\..+)$" matches "/ljk.html", client: 172.16.25.3, server: localhost, request: "GET /ljk.html
　　*108 rewritten redirect: "/wordpress/ljk.html?sds", client: 172.16.25.3, server: localhost, request: "GET /ljk.ht         ml?sds
　　浏览器地址栏变成了rewrite后的url

　　由三四得出结论：Permanent、redirect两个标志控制是否将重过程在用户端体现出来（即将重写后的url显示在客户端）同时返回301 or 302。
　　然后再试试last和break两个标志（需要两层及以上跳转来测试）
　　按照网上较为普遍的说法：
　　假如一个location里有多条rewrite规则，都是不在该location继续往下匹配，但是
　　last： 匹配完该条语句后得到的url，重新到server标签下走一遍
　　break：到此为止（直接以重写后的url在服务器寻找资源）
　　实验环境：删除html/wordpress下的ljk.html，将ljk.html放置在html/ljk/ljk.html,然后在server标签下配置location /wordpress 的rewrite规则
　　五、先来看下两次rewrite 规则不加标志的情况
　　location / {
　　root   /usr/local/nginx/html;
　　indexindex.shtml index.php index.html;
　　if (!-e $request_filename) {
　　rewrite ^/(.+\..+)$ /wordpress/$1;
　　}
　　}
　　location /wordpress{
　　if (!-e $request_filename) {
　　rewrite ^/wordpress/(.+\..+)$ /ljk/$1;
　　}
　　}
　　access_log:
　　GET /ljk.html HTTP/1.1" 200
　　error_log:    经历两次匹配和重写
　　*111 "^/(.+\..+)$" matches "/ljk.html",
　　*111 rewritten data: "/wordpress/ljk.html", args: "",
　　*111 "^/wordpress/(.+\..+)$" matches "/wordpress/ljk.html",
　　*111 rewritten data: "/ljk/ljk.html", args: "",
　　浏览器地址栏url不变
　　六、实验break标志
　　location / {
　　root   /usr/local/nginx/html;
　　indexindex.shtml index.php index.html;
　　if (!-e $request_filename) {
　　rewrite ^/(.+\..+)$ /wordpress/$1 break;
　　}
　　}
　　location /wordpress{
　　if (!-e $request_filename) {
　　rewrite ^/wordpress/(.+\..+)$ /ljk/$1;
　　}
　　}
　　access_log:
　　GET /ljk.html HTTP/1.1" 404
　　error_log:
　　*112 "^/(.+\..+)$" matches "/ljk.html",
　　*112 rewritten data: "/wordpress/ljk.html", args: "",
　　*112 open() "/usr/local/nginx/html/wordpress/ljk.html" failed (2: No such file or directory),
　　加了break，所以在重写成‘wordpress/ljk.html’就没有再走到location /wordpress
　　七、实验last标志
　　location / {
　　root   /usr/local/nginx/html;
　　indexindex.shtml index.php index.html;
　　if (!-e $request_filename) {
　　rewrite ^/(.+\..+)$ /wordpress/$1 last;
　　}
　　}
　　location /wordpress{
　　if (!-e $request_filename) {
　　rewrite ^/wordpress/(.+\..+)$ /ljk/$1;
　　}
　　}
　　访问http://172.16.25.162/ljk.html
　　access_log:
　　GET /ljk.html HTTP/1.1" 200
　　error_log:
　　*113 "^/(.+\..+)$" matches "/ljk.html",
　　*113 rewritten data: "/wordpress/ljk.html", args: "",
　　*113 "^/wordpress/(.+\..+)$" matches "/wordpress/ljk.html",
　　*113 rewritten data: "/ljk/ljk.html", args: "",
　　由五六七可得出结论：
　　加break标志时，url一旦找到匹配额规则，就会停止继续匹配并以该rewrite后额url去服务器请求资源；
　　加last标志或者不加任何标志，其‘过程’和‘结果’一致，会以rewrite后的url再重新到server段下走一遍配置。
　　并且这两个标志都不会改变浏览器地址栏的url，且返回码亦为200或404等（即对用户透明）
　　八、涉及到域名重定向的实验
　　server {
　　listen      80;
　　server_namelocalhost;
　　rewrite_log on;
　　rewrite ^(.*)$ http://www.baidu.com;
　　}
　　若rewrite规则后不加标志或者加redircet标志，都会返回“GET / HTTP/1.1" 302”临时重定向
　　当rewrite规则后加permanent 标志，会返回“GET / HTTP/1.1" 301”永久重定向
　　希望这篇文章能对理解nginx的rewrite有一些帮助！

查看完整版本: nginx rewrite模块探究与实验