联系方式：176140646@qq.com
菜狗摸索，有误勿喷，烦请联系

1. 关于`rewrite`后的流程摸索

1.1 前言

对于 Nginx 的rewrite指令，是 Nginx 学习使用的一大重点
rewirte指令后众所周知可以跟 4 种flag，分别是last，break，redirect，permanent
rewirte后流程到底怎么走，这里是菜狗的一点点摸索

1.2 分析

为了方便理解，这里先贴上最终的流程图
现在，我们对此图从下到下，从左右到的顺序对造成的不同情况进行演示

情况一：
- rewrite后的地址是以http://或https://开头
- 小结论：返回给客户端302状态码，并让客户端重定向到重写后的地址
情况二：
- rewrite后的地址不是以http://或https://开头
- rewrite指令后不跟flag参数
- 且此location块中rewrite指令后面还有代码，但无return指令
- 小结论：走完此location块余下代码后，再按照重写后的地址进行重新匹配
情况三：
- rewrite后的地址不是以http://或https://开头
- rewrite指令后不跟flag参数
- 且此location块中rewrite指令后面还有代码，但有return指令
- 小结论：不理重写后的地址，而是直接按照return指令配置的值返回给客户端
情况四：
- rewrite后的地址不是以http://或https://开头
- rewrite指令后跟flag参数，且值为last
- 小结论：不再理此location块内余下的代码，而是直接按照重写后的地址重新匹配
情况五：
- rewrite后的地址不是以http://或https://开头
- rewrite指令后跟flag参数，且值为redirect
- 小结论：不再理此location块内余下的代码，而是返回状态码302，让客户端进行临时重定向到重写后的地址
情况六：
- rewrite后的地址不是以http://或https://开头
- rewrite指令后跟flag参数，且值为permanent
- 不再理此location块内余下的代码，而是返回状态码302，让客户端进行永久重定向到重写后的地址
情况七：
- rewrite后的地址不是以http://或https://开头
- rewrite指令后跟flag参数，且值为break
- 小结论：直接打断处理，通常客户端表现为404

1.3 老鼠坑

对于rewrite后的新地址
如果是以http://或者https://开头的，这个重定向到新的服务器的操作，我想是没问题的
但是有没有发现，在上一节的多种情况中，除了以http://或者https://开头的这种情况外，其余 6 中情况中重写后的地址都是直接写请求路径，而不是写成以ip + 端口 + 请求路径 的方式
那么，就好奇的做下了实验，下面是结果图
如果rewrite后跟的flag为break，不管你重写后的地址是什么，直接打断处理，客户端显示为 404
而对于其余 4 种情况（有flag且有有return排除)，会发现所谓重新匹配是拿着重写后的地址去重新匹配此server块中的诸多location块后的请求路径，也就是说默认到本 Nginx 服务中重新请求
所以，可以总结为如果想重定向到其他服务器，使用https://或者http://即可，其余情况除break和(无flag且有return)外都是在本 Nginx 服务重新请求，实际开发时要注意这一点