深度硬核文:Nginx的301重定向处理过程分析

一，序言

“晚上九点，办公室里烟雾缭绕，工作进度依然没有什么进展。王二胖打开了十来个页面，一篇篇技术文章打开，关闭，Nginx不停的重启测试，在试过十来篇技术文章中的方案，经过两个小时的测试之后，王二胖终于找到了一个解决301错误跳转的可行解决方案。时间已经到了晚上十一点多."

这样的场景，在我们的办公室里天天可见。互联网上有很多Nginx 301问题处理方案的错误解答，比如自动加斜杠，端口丢失，暴露内部端口号等，极多量的文章基本就是人云亦云，没有完全弄明白Nginx如何处理301状态码的。甚至对于一些关键性的配置信息的解释是完全错误的。本着源代码就是最正确的文档的原则，我阅读了一遍Nginx处理301问题的相关源代码。

最终发现，Nginx处理301 Moved Permanently的逻辑相当简单，只有六种分支。

二，Nginx的301状态码处理逻辑设计

让我们先看看Nginx的逻辑设计是怎么样的。
　　HTTP协议中3xx开头的状态响应码都是表示重定向的响应。根据RFC的定义
　　301 Moved Permanently
　　302 Found
　　303 See Other
　　307 Temporary Redirect

301是永久重定向。如果使用Nginx作为HTTP 服务器，那么当用户输入一个不存在的地址之后，基本上会有两种情况，返回404状态码，或者301状态码。404 Not Found不做讨论，只是说下301 Moved Permanently的处理过程。

首先的关键问题是：页面重定向功能会在什么样的情况下被触发？

答案是：**Nginx负责设置301 Moved Permanently状态码。但nginx.conf控制Nginx如何处理301 Moved Permanently状态码！**换句话说，要不要进行页面重定向，和怎么重定向，完全是用户配置的结果！六种分支的选择完全是根据用户的配置来决定的。

根据源代码，Nginx的算法逻辑设计是分成两个部分的。第一部分是设置状态码，第二部分是对应状态码的实际响应处理。

Nginx和浏览器之间的通讯过程，比如一次正常的HTTP 访问过程，如下图。