当前位置: 代码网 > 服务器>服务器>Nginx > nginx重写和重定向关系与配置方式

nginx重写和重定向关系与配置方式

2024年07月03日 Nginx 我要评论
前言一直对nginx的重写和重定向都是只有一个模糊的认识,只是知道在nginx里return、rewrite、proxy_pass能实现我想要的转发。每次查阅资料时,各种关键词充斥在眼前:&ldquo

前言

一直对nginx的重写和重定向都是只有一个模糊的认识,只是知道在nginx里return、rewrite、proxy_pass能实现我想要的转发。

每次查阅资料时,各种关键词充斥在眼前:“重写”、“重定向”、“隐式转发”、“内部重定向”......一直没有区分清楚他们之前的区别或联系。

随之产生几个问题,想要花点时间搞清楚它们:

  • 重写和重定向的区别是什么?
  • nginx中“重写”、“重定向”、“隐式转发”、“内部重定向”......这些名词的关系是什么?在nginx是否都由一个独立的模块、关键字来实现这些的?
  • nginx中return、rewrite、proxy_pass它们的区别是什么?对于重写和重定向,它们是否各自实现不同的功能?

1.重写和重定向的区别是什么?

首先说说关联

首先重写和重定向的最终目的是一样的。假如你通过浏览器和固定的链接经常访问一张“好看的图片”,有一天图片的维护者将它移动了位置(服务器上的目录、移动到其他域名),那意味着你访问不到这张图片了?

为了避免这样的情况给用户带来的困扰,可以使用重写、或者重定向,将你的请求转向新的位置(这张图片新的位置),对你来说还是用老的固定的链接访问到了你喜欢的图片。

那他们的区别呢?

重定向:重定向是用户请求服务端后,服务端向客户端发送http 301、302(303、304、307、308),告诉客户端需要去尝试另一个url。意味着客户端知道使用另一个url并去访问。(客户端发起两次请求)

重定向的请求路径如下:

  • request1(来自客户端):访问“好看的图片”
  • response1(来自服务端):你要访问的图片不在这了,你需要去访问“好看的图片新的位置”
  • request2(来自客户端):访问“好看的图片新的位置”
  • response2(来自服务端):拿去吧,你要的“好看的图片新的位置”对应的图片

重写:重写发生在服务器上。服务器内部将一个url转到另一个url,然后返回给客户端。客户端并不知道自己的请求被转过一次,浏览器中的url也始终是一开始访问的那个。(客户端发起一次请求)

重写的请求路径如下:

  • request1(来自客户端):访问“好看的图片”
  • 重写(服务端处理):将“好看的图片”改到“好看的图片新的位置”,获取到图片
  • response1(来自服务端):拿去吧,你要的“好看的图片”对应的图片

粗暴总结

从浏览器的反馈来看。重写-客户端只会发送一次请求;重定向-客户端会发送两次请求。

2.“重写”、“重定向”、“隐式转发”、“内部重定向”......这些名词的关系是什么?

重写和重定向在上面已经解释过了。关于其他名词的解释,在网上搜罗了一下:

  • 隐式转发/隐形转发/隐藏式跳转:将请求跳转到另一个网站的页面,并且浏览器中url保持不变。
  • 显示转发:将请求跳转到另一个网站的页面,浏览器中url会发生改变。
  • 内部重定向:内部重定向(重写)发生在server端内部,client端不知情,浏览器上url不会改变。
  • 外部重定向:外部重定向是server端通知client端需要访问新的url,client端进行第二次访问。浏览器中url也变成新的url。

思来想去,似乎就是对重写和重定向取了好多名字。所以个人理解的总结:

  • 重写 = 隐式转发 = 内部重定向
  • 重定向 = 显示转发 = 外部重定向

3.nginx中return、rewrite、proxy_pass它们的区别是什么?实现的功能是什么?

  • return和rewrite都是nginx的ngx_http_rewrite_module模块中的;
  • proxy_pass是nginx的ngx_http_proxy_module模块中的。

3.1 return

语法:return code [text];
return code url;
return url;
默认:
语境:server, location, if

停止处理请求并返回指定的状态码个客户端。非标准代码444关闭连接而不发送响应头。

  • return的状态码为301、302、303、307、308时,则为重定向;
  • return的状态码为其他时,可以返回响应主体[text]。

3.2 rewrite

语法:rewrite regex replacement [flag];
默认:
语境:server, location, if

  • 如果指定的regex表达式与请求uri匹配,则按照replacement中指定的规则更新url。
  • rewrite指令会根据配置文件中的顺序依次执行,可以使用[flag]参数终止指令向下继续执行。
  • 如果replacement中替换字符串以“http://”、“https://”、"$scheme"开头,则处理停止,并将重定向返回给客户端

可选[flag]参数:

  • last——停止当前处理的ngx_http_rewrite_module指令集,重新开始搜索与修改后的uri匹配的location;(重写)
  • break——停止当前处理的ngx_http_rewrite_module指令集;(重写)
  • redirect——返回带有302状态码的临时重定向;如果替换字符串不以“http://”、“https://”、"$scheme"开头,则使用;(重定向)
  • permanent——返回带有301状态码的永久重定向。(重定向)

如果"rewrite ... last;"在location中,且location和rewrite的匹配规则能匹配到相同的url,则"rewrite ... last;"的flag需要改成break。

否则,nginx将进行10次循环匹配,并最终返回500状态码报错。

location /download/ {
    rewrite ^(/download/.*)/media/(.*)\..*$ $1/mp3/$2.mp3 break;
    rewrite ^(/download/.*)/audio/(.*)\..*$ $1/mp3/$2.ra  break;
    return  403;
}

如果replacement字符串包含新的请求参数,则修改之前的请求参数会附加在修改后的uri后面。

如果不需要参数,则在replacement字符串末尾添加问号,这样修改后的请求不会被附加之前的请求参数。

rewrite ^/users/(.*)$ /show?user=$1? last;

如果正则表达式中包含";"、"}"这种结束符,则整个表达式应该用单引号或双引号引起来。

3.3 proxy_pass

ngx_http_proxy_module该模块允许将请求传递到另一台服务器。

语法:proxy_pass url;
默认:
语境:location, if in location, limit_except

设置代理服务器的协议、地址、端口、可选的uri。

  • 协议:http、https
  • 地址:域名、ip、upstream
  • 端口:(可选)
  • uri:(可选)
  • 可以使用变量,如:“proxy_pass http://127.0.0.1$request_uri;”
  • 可以代理到unix套接字路径,如:“proxy_pass http://unix:/tmp/backend.socket:/uri/;”

地址——除了ip+端口外,还可以指定域名和upstream。如果指定的是域名,会在配置文件中寻找对应的服务器组(upstream),找不到才会按域名解析来;如果域名解析到多个ip,会以循环的方式使用这些ip。

uri——如果proxy_pass指定了uri,则请求传递到服务器时使用指定的uri替换location部分匹配的uri;如果proxy_pass没有指定uri,则原始请求的uri会传递给服务器。

某些情况下,无法确定请求uri中替换的部分,需要用到正则表达式。可以在location中通过rewrite重写:

location /name/ { 
    rewrite /name/([^/]+) /users?name=$1 break; 
    proxy_pass http://127.0.0.1; 
}

3.4 nginx模块实现重写/重定向总结

nginx的模块在实现重写或者重定向时,并不是独立的。不是某个模块只能实现重写,而另一个模块只能实现重定向,并不是这种关系(至少对于rewrite来说不是)。

重定向:

  • return状态码为301、302、303、304、307、308时,则为重定向
  • rewrite的replacement中替换字符串以“http://”、“https://”、"$scheme"开头,则为重定向
  • rewrite的flag为redirect,则为302重定向
  • rewrite的flag为permanent,则为301重定向

重写:

  • rewrite的flag为last时,且replacement中替换字符串不以“http://”、“https://”、"$scheme"开头,则为重写
  • rewrite的flag为break时,且replacement中替换字符串不以“http://”、“https://”、"$scheme"开头,则为重写
  • 使用proxy_pass,则为重写

4.关于重写/重定向时规则的匹配效率

在重写和重定向时,经常会用到正则表达式来匹配我们想要的uri。但是我们需要注意的时,应该努力保持正则的整洁,越复杂会越影响效率。

下面的示例,通过尽量避免捕获或匹配,从而提高效率:

  • bad:
rewrite ^/(.*)$ http://example.com/$1 permanent;
  • good:
rewrite ^ http://example.com$request_uri? permanent;
  • better:
return 301 http://example.com$request_uri;

5.总结

5.1 什么是重写和重定向?

重定向:重定向是用户请求服务端后,服务端向客户端发送http 301、302(303、304、307、308),告诉客户端需要去尝试另一个url。意味着客户端知道使用另一个url并去访问。(客户端发起两次请求)

重写:重写发生在服务器上。服务器内部将一个url转到另一个url,然后返回给客户端。客户端并不知道自己的请求被转过一次,浏览器中的url也始终是一开始访问的那个。(客户端发起一次请求)

5.2 相关名词是什么对应关系?

人理解的总结:

  • 重写 = 隐式转发 = 内部重定向
  • 重定向 = 显示转发 = 外部重定向

5.3 nginx模块实现重写和重定向地对应关系

nginx的模块在实现重写或者重定向时,并不是独立的。不是某个模块只能实现重写,而另一个模块只能实现重定向,并不是这种关系(至少对于rewrite来说不是)。

重定向:

  • return状态码为301、302、303、304、307、308时,则为重定向
  • rewrite的replacement中替换字符串以“http://”、“https://”、"$scheme"开头,则为重定向
  • rewrite的flag为redirect,则为302重定向
  • rewrite的flag为permanent,则为301重定向

重写:

  • rewrite的flag为last时,且replacement中替换字符串不以“http://”、“https://”、"$scheme"开头,则为重写
  • rewrite的flag为break时,且replacement中替换字符串不以“http://”、“https://”、"$scheme"开头,则为重写
  • 使用proxy_pass,则为重写

以上为个人经验,希望能给大家一个参考,也希望大家多多支持代码网。

(0)

相关文章:

版权声明:本文内容由互联网用户贡献,该文观点仅代表作者本人。本站仅提供信息存储服务,不拥有所有权,不承担相关法律责任。 如发现本站有涉嫌抄袭侵权/违法违规的内容, 请发送邮件至 2386932994@qq.com 举报,一经查实将立刻删除。

发表评论

验证码:
Copyright © 2017-2025  代码网 保留所有权利. 粤ICP备2024248653号
站长QQ:2386932994 | 联系邮箱:2386932994@qq.com