nginx 301重定向 设置

本文详细介绍了如何在Nginx中配置HTTP和HTTPS协议下的重定向,确保访问不带www的网址能自动跳转至带www的域名。强调了在return字段中正确使用协议头和$request_uri参数的重要性,避免出现无限重定向和URL过长的错误。

在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.comhttps://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,知乎:

实际案例2,小米:

实际案例3,百度:

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

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

nginx 301重定向死循环是指在使用nginx进行301永久重定向时,由于配置错误或者逻辑问题导致请求在重定向过程中陷入无限循环的情况。 通常情况下,nginx301重定向是通过配置server块中的location指令来实现的。当客户端发送请求时,nginx会根据配置的location规则进行匹配,并将匹配到的请求重定向到指定的URL。 如果配置的重定向规则存在问题,比如将请求重定向到了自身或者循环重定向到其他URL,就会导致死循环的情况发生。例如,以下是一个可能导致死循环的nginx配置示例: ``` server { listen 80; server_name example.com; return 301 http://example.com; } ``` 在这个示例中,无论客户端请求任何URL,nginx都会将其重定向到http://example.com。这样就会导致请求不断地被重定向,从而形成死循环。 为了避免nginx 301重定向死循环,需要确保重定向规则正确配置。可以通过以下几种方式来解决问题: 1. 检查重定向规则:仔细检查nginx配置文件中的重定向规则,确保没有将请求重定向到自身或者形成循环重定向的情况。 2. 使用301重定向的目标URL:在配置重定向规则时,确保将请求重定向到一个有效的URL,而不是一个无效的URL或者自身。 3. 使用302临时重定向:如果无法确定正确的重定向规则,可以暂时使用302临时重定向代替301永久重定向,以避免死循环的问题。
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值