0%

hexo + CloudFlare = 速度飞起

昨天配置了 Google、Baidu、Bing搜索引擎提交,不过比较悲催的是 Github Pages 服务器拒绝 BaiduSpider ,整个站点根本不能出现在 Baidu 里面好么!! 另一方面,速度过慢,github pages 在国内速度,不太理想,所以用 CloudFlare 老牌 cdn 加速整站,还可以被 BaiduSpider 收录。

参考了这篇文章: 基于 Hexo 的 GitHub Pages 配置 CloudFlare CDN_qhh0205-CSDN博客

准备好 GitHub 和 CloudFlare

有一个 github 账户,添加 username.github.io 库,把 hexo 发布到存储库,不多说了。

注册 CloudFlare 账号并登录。

在 CloudFlare 添加站点

在 CloudFlare 添加站点,并检查 DNS 记录,确认导入 CloudFlare 中。

在域名购买商处修改 DNS 服务器为 CloudFlare 提供的两个 DNS 服务器,等待生效之后继续操作

注意 :修改 DNS 服务器可能会导致某些记录丢失(像 Google 域名验证、letsencrypt 域名验证)(因为不是全部同步过去),所以在更改之前可以在旧 DNS 控制台,记录下各个 DNS 记录(截屏或手抄),后期可再写入新纪录

Ps:实验表明: CloudFlare 会同步大部分DNS记录,但是还是有部分子域名会漏掉,看个人情况是否手动记录原 DNS

image-20200210152724656

image-20200210112341702

修改 DNS 服务器:

image-20200210112513410

等待生效,可用 nslookup -q=ns tcpsoft.app 查询 DNS 解析服务器情况(本地的好像更新有点慢),其实 CloudFlare 在检测到 DNS 服务器修改成功之后会发邮件通知的。

然后在 CloudFlare 检查域名服务器,进行下一步操作,设置一些网站的自定义选项,包括是否开启浏览器到CF

的安全连接,是否开启CF到源服务器的安全连接,是否启用 Brotli 压缩来传输数据等。

然后就可以查看 DNS 设置,有黄色云图标的就是 CloudFlare 开启代理的

image-20200210120918605

我们可以用 dig (linux)或 nslookup (linux、Windows)查看域名解析情况。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
[email protected] /m/c/U/CP# dig blog.tcpsoft.app

; <<>> DiG 9.10.3-P4-Ubuntu <<>> blog.tcpsoft.app
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 45170
;; flags: qr rd ra; QUERY: 1, ANSWER: 5, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;blog.tcpsoft.app. IN A

;; ANSWER SECTION:
blog.tcpsoft.app. 900 IN CNAME tcpsoftware.github.io.
tcpsoftware.github.io. 900 IN A 185.199.110.153
tcpsoftware.github.io. 900 IN A 185.199.108.153
tcpsoftware.github.io. 900 IN A 185.199.111.153
tcpsoftware.github.io. 900 IN A 185.199.109.153

;; Query time: 1990 msec
;; SERVER: 223.5.5.5#53(223.5.5.5)
;; WHEN: Mon Feb 10 12:12:47 CST 2020
;; MSG SIZE rcvd: 133

[email protected] /m/c/U/CP# nslookup blog.tcpsoft.app
Server: 223.5.5.5
Address: 223.5.5.5#53

Non-authoritative answer:
blog.tcpsoft.app canonical name = tcpsoftware.github.io.
Name: tcpsoftware.github.io
Address: 185.199.110.153
Name: tcpsoftware.github.io
Address: 185.199.108.153
Name: tcpsoftware.github.io
Address: 185.199.109.153
Name: tcpsoftware.github.io
Address: 185.199.111.153

[email protected] /m/c/U/CP#

我们可以看到解析了四个 IP,而我的 DNS 设置只有一个 CNAME,查询这个 IP,发现是 CDN,设置成功。

开启DNSSEC,防止 DNS 劫持

在 CloudFlare 的 DNS 管理面板往下翻可以看到 DNSSEC 选项,DNSSEC 是 DNS 安全扩展,采用加密方式,防止 DNS 劫持

image-20200210122448916

CF 提供了十多个参数,转到域名注册商处,填入注册商要求的对应参数即可。

等待十多分钟至一个小时,CloudFlare 上的 DNSSEC 会检测到设置成功,提示 Success!

image-20200210125156256

又掉坑:“重定向次数过多”

刚才的配置好之后,满以为可以运行的飞起来了,结果,打 !不 !开 !了 !

image-20200210143346231

一番查询发现是:CloudFlare SSL 选项开的是 Flexible。

image-20200210143616798

下面文字摘自 参考链接:WordPress 网站使用 CloudFlare 后提示“将您重定向的次数过多” 的原因及解决办法 _WordPress智库

Cloudflare CDN 配置

  • Off:不开启https。

  • Flexible:当我们的源网站没有配置 HTTPS 支持时,启用这个选项,Cloudflare 会在回源的时候通过 HTTP 协议访问我们的网站。

  • Full:当我们的源网站支持 HTTPS,但是 HTTPS 证书和域名不匹配或者是自签名证书时,Cloudflare 会通过 HTTPS 协议访问源网站,但不会验证证书,也就是说,即使我们的源网站提供的 HTTPS 证书不受浏览器信任,Cloudflare 也会通过 HTTPS 回源网站。

  • Full(strict):当我们的源网站支持 HTTP ,并且证书有效时(未过期且受信任)。Cloudflare 会通过 HTTPS 协议访问源网站,并在每个请求过程中验证证书。

了解了上面各个设置的功能,我们来看一下 Cloudflare 的循环重定向问题是怎么出现的,在 Cloudflare 中开启了 SSL 后,访问网站时出现循环重定向需满足下面两个条件:

  1. SSL 中设置了 Flexible,CDN 以 HTTP 协议回源网站。
  2. 源网站支持 HTTPS,并且设置了通过 HTTP 协议访问时,自动跳转到 HTTPS 协议。

到这里,可能就有朋友发现问题了,我们访问 Cloudflare 的 CDN 服务器的时候,是通过 HTTPS 访问的,CDN 访问源网站的时候,是通过 HTTP 访问的,源网站上 HTTP 又自动跳转了 HTTPS,完美的一个循环重定向。重定向的次数多了,浏览器就撂挑子报出了 ERR_TOO_MANY_REDIRECTS 的错误。

CloudFlare 造成重定向的次数过多问题的解决办法

知道了循环重定向的原因,我们也就知道了怎么解决这个问题,通过测试,下面的两种设置方法都可以解决 Cloudflare 循环重定向的问题。

  • SSL 中选择 Full 或者 Full(strict),让 CDN 回源的时候使用 HTTPS 的方式回源,没有 HTTP 什么事了,就不会跳来跳去了
  • 源网站不设置 HTTPS 支持或者 不设置 HTTP 跳转 HTTPS,让 Cloudflare 回源的时候使用 HTTP 方式获取资源。

修改了 CloudFlare 设置后,可能需要过几分钟或清理浏览器缓存后才能生效。

除了 Cloudflare,使用其他 CDN 提供商的时候,也可能会出现这个问题,如果设置了 CDN 后,遇到了 Chrome 报重定向次数过多的问题,可以通过上面的思路查找问题。

坚持原创技术分享,您的支持将鼓励我继续创作!