建站随笔,  网络基础,  网页基础

重定向及重定向次数过多

本文于2021年1月17日由AlvinCR更新

背景

在我安装使用https协议之后,打开后台才出现的此类情况,想到了几种可能的原因及解决方法,分享出来帮助遇到同样问题的你。

什么是重定向

重定向是一种特殊的页面,使得人们在输入该名称进入条目或者点击指向该名称的内部链接时,系统能够自动导航到重定向页面内部指定的另一相关页面中,从而实现相关页面可以以多个名称进行访问。

总结:重定向相当于路标,将所有不同地方的人指向同一个地方,这样就可以人为创建出一个相关的集合,重定向的内容都是这些相关内容的子集。

重定向原理

https://developer.mozilla.org/zh-CN/docs/Web/HTTP/Redirections

在 HTTP 协议中,重定向操作由服务器通过发送特殊的响应(即 redirects)而触发。HTTP 协议的重定向响应的状态码为 3xx 。

浏览器在接收到重定向响应的时候,会采用该响应提供的新的 URL ,并立即进行加载;大多数情况下,除了会有一小部分性能损失之外,重定向操作对于用户来说是不可见的。

 

不同类型的重定向映射可以划分为三个类别:永久重定向、临时重定向、特殊重定向。

 

永久重定向

例如将http://alvincr.com/重定向为https://alvincr.com/便是永久重定向,它表示原 URL 不应再被使用,而应该优先选用新的 URL。出现下面的重定向次数过多这个问题,和这个操作息息相关。

此外cname也是一种永久重定向,将www.alvincr.com永久定向到alvincr.com

临时重定向

比如alvincr.com设置了一些固定链接,但是alvincr设置的命名方式是月份+名称的组合,如果改成朴素类型,以原有链接访问文章仍然有效,但是会自动跳转到朴素的链接上。例如https://alvincr.com/example跳转到https://alvincr.com/?p=123

特殊重定向

当你访问https://alvincr.com/ ,如果不是第一次访问,并且alvincr的网页内容并没有变动,那么浏览器将会自动查找cache中的内容,这就是304 not modified。

如何进行重定向

如果要将文章1定位到文章2,那么需要在文章1中输入命令行进行重定位:

#REDIRECT [[文章1的名称]]

取消方法:

在重定向的文章url后面添加?redirect=no

注意事项

不要多次进行重定向,这会导致服务器资源大量消耗,并且会是页面加载速度变慢,影响体验。此外重定向的位置一定要确定好,不要出现循环重定向,否则会出现死锁的情况。

一:强制转换

原因

提示“重定向次数过多”,一般是因为将HTTP链接强制跳转为HTTPS链接,然鹅,在防火墙上却只配置了一条HTTPS(对外协议)到HTTP(源站协议)的转发,防火墙强行将用户的请求进行跳转到更安全的https,所以造成死循环。

总结:防火墙心比天高,明明是一条环形路,非得让天上走的、地上爬的都走这里,最后谁都出不去,形成死循环。

解决方法

将环形道路变成非封闭道路:

通过在防火墙中修改服务器信息,配置两条HTTP(对外协议)到HTTP(源站协议)和HTTPS(对外协议)到HTTPS(源站协议)的服务器信息,就能解决此类问题。

二:循环解析

原因

CNAME记录用于域名的别名,如果网站的初始链接都有www,然而含有www的域名都要跳转到不含www的域名或是IP,如果将CNAME的解析指向域名,会使不含www的域名重新跳转到含有www的域名,最终造成了死循环。

就好像一个人有个外号叫:A,正常来说,说到A这个外号想到的应该是这个人是谁,然而防火墙偏偏不这么想,非得把外号A对应成名字B,然而在叫名字B的时候联想到的却是外号A,结果就不知道这个人是谁了。

解决方法

将CNAME的解析指向IP而非域名.

三:Cloudflare

原因

开启SSL证书后选择灵活SSL,由于灵活的SSL强制通过未加密的HTTP连接到源Web服务器,然而web服务器只能以https的方式进行访问,结果http就被拒之门外了。

解决方法

方法一:对于采用cloudflare提供的CDN加速来说,将灵活ssl切换到完全的SSL。

方法二:从个人站点服务器配置:将HTTP移动到HTTPS重定向,修改方法参考nginx的官方文档:http://nginx.org/en/docs/http/ngx_http_rewrite_module.html#rewrite

补充

灵活 SSL 选项允许在访问者和 Cloudflare 之间建立安全的 HTTPS 连接,但会强制 Cloudflare 通过未加密的 HTTP 连接到源 Web 服务器。源 Web 服务器不需要拥有SSL 证书,但访问者仍然会浏览该网站的 HTTPS 版本。如果您的网站上有任何敏感信息,则不建议使用灵活选项。只有在用户无法在自己的源 Web 服务器上设置 SSL 时,才使用灵活作为最后的手段。

完全可确保访问者与 Cloudflare 域之间以及 Cloudflare 与 Web 服务器之间的安全连接。完全 SSL 选项不会在源中验证 SSL 证书的真实性。源 Web 服务器上允许使用自签名证书。要在启用完全 SSL 选项之前避免 525 错误,请将源 Web 服务器配置为允许端口 443 上的 HTTPS 连接,并提供自签名 SSL 证书

https://developer.mozilla.org/zh-CN/docs/Web/HTTP/Redirections

NGINX配置重定向:

在 Nginx 中,你可以创建一个服务器模块来进行重定向设置:

server {

listen 80;

server_name example.com;

return 301 $scheme://www.example.com$request_uri;

}

可以使用 rewrite 指令来针对一个文件目录或者一部分页面应用重定向设置:

rewrite ^/images/(.*)$ http://images.example.com/$1 redirect;

rewrite ^/images/(.*)$ http://images.example.com/$1 permanent;

Apache配置重定向:

mod_alias 模块提供了 Redirect 和 Redirect_Match 两种指令来设置 302 响应(默认值):

<VirtualHost *:443>

ServerName example.com

Redirect / https://www.example.com

</VirtualHost>

URL https://example.com/ 会被重定向至 https://www.example.com/ ,URL 下的任何文件或目录也将重定向到该 URL(https://example.com/some-page 将重定向至 https://www.example.com/some-page)。

Redirect_Match 指令的功能与之类似,不同之处在于它可以通过正则表达式来指定一批受影响的 URL :

RedirectMatch ^/images/(.*)$ http://images.example.com/$1

Leave a Reply

邮箱地址不会被公开。 必填项已用*标注

重定向及重定向次数过多