在nginx中配置，使得访问不带www的网址自动重定向到带www的域名。

http协议的重定向

在nginx官方文档中有如下示例代码：

server {
    listen       80;
    server_name  example.com;
    return       301 http://www.example.com$request_uri;
}

server {
    listen       80;
    server_name  www.example.com;
    ...
}

对于return字段，有两点需要特别注意：

• 必须带上协议头，即http://
• 必须带上$request_uri参数

踩坑：return字段必须带上协议头

经踩坑，不带上协议头，访问example.com会重定向到example.com/www.example.com/www.example.com/www.example.com/www.example.com...(url的长度达到8k+)，最终出现414 Request-URI Too Large错误。

我在进行测试时发现chrome会自动缓存301跳转，因此就算还原了nginx的配置文件，访问example.com仍然会重定向到刚才的超长网址上，一直都是414错误。有两种方法可以解决301缓存的问题：

• 在浏览器的设置中清除缓存数据
• 使用隐私窗口进行测试(正确的打开方式✅)

踩坑：必须带上$request_uri参数

full original request URI (with arguments)

nginx文档中对该变量的描述比较简单，通过搜索可以找到历史版本的说明，(stackoverflow,博客园,新浪博客)：

This variable is equal to the original request URI as received from the client including the args. It cannot be modified. Look at $uri for the post-rewrite/altered URI. Does not include host name. Example: "/foo/bar.php?arg=baz"

通过这个详细的描述，可以了解$request_uri参数表示从客户端发送来的原生请求URI，包括参数。

经踩坑，不带上$request_uri参数，访问example.com/abcd?123会重定向到www.example.com，即无论访问任何子路径，都会自动重定向到首页。

https协议的重定向

参考http协议的重定向，我们添加了如下的配置：

server {
    listen       443 ssl;
    server_name  example.com;
    return       301 https://www.example.com$request_uri;
}

server {
    listen       443 ssl;
    server_name  www.example.com;
    ...
}

重新加载nginx配置后，我们发现 https://example.com 无法访问，通过curl测试，返回下述错误信息：curl: (35) Server aborted the SSL handshake，很明显是ssl方面的问题。

而在配置前，https://example.com 和 https://www.example.com 都是可以正常访问的，原始配置如下：

server {
    listen          443 ssl;
    server_name     www.example.com;
    server_name     example.com;
    ssl_certificate      ssl/www.example.com.crt;
    ssl_certificate_key  ssl/www.example.com.key;
    ...
}

因此，我尝试在重定向的配置中也添加ssl_certificate的配置信息：

server {
    listen       443 ssl;
    server_name  example.com;
    ssl_certificate      ssl/www.example.com.crt;
    ssl_certificate_key  ssl/www.example.com.key;
    return       301 https://www.example.com$request_uri;
}

再次加载nginx配置后，发现 https://example.com 正常访问，并且可以自动重定向到 https://www.example.com 。

301还是302

• 301: 永久性转移(Permanently Moved)
• 302: 暂时性转移(Temporarily Moved)

共同点：二者都表示重定向，浏览器在获取服务器的返回码后会自动根据头部的Location值跳转到新的URL地址；

不同点：301表示旧地址被永久地移除了，已经不可访问；302表示旧地址还在，只是临时进行跳转，后续还是访问旧地址。

问题来了：什么情况下用301跳转？什么情况下用302跳转？

实际案例1，知乎：

• http://www.zhihu.com 跳转到 https://www.zhihu.com 用的是301跳转
• /za-js-sdk@latest/dist/zap.js 跳转到 /za-js-sdk@2.4.5/dist/zap.js 用的是302跳转

实际案例2，小米：

• http://mi.com/ 跳转到 http://www.mi.com/ 用的是301跳转
• http://www.mi.com/ 跳转到 https://www.mi.com/ 用的是302跳转

实际案例3，百度：

• http://tieba.baidu.com/ 跳转到 https://tieba.baidu.com/index.html 用的是301跳转
• http://baidu.com/ 跳转到 https://www.baidu.com/ 用的是302跳转

个人感觉，知乎的使用比较有代表性，从http到https做301永久跳转，表示知乎采用的是https的方式访问，不会在回退到http的方式；而在获取zap.js的时候，使用了302临时跳转，跳转到当前的版本，后续zap.js有更新的时候，也会302跳转到更新后的地址。

注：文章中使用到的域名 example.com 为示例代码，请根据项目需要自行修改。