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

前言

一直对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，则为重写

以上为个人经验，希望能给大家一个参考，也希望大家多多支持脚本之家。