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 添加站点，并检查 DNS 记录，确认导入 CloudFlare 中。

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

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

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

修改 DNS 服务器：

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

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

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

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

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

root@Mi-CP /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

root@Mi-CP /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

root@Mi-CP /m/c/U/CP#

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

开启DNSSEC，防止 DNS 劫持

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

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

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

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

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

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

下面文字摘自参考链接：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 后，访问网站时出现循环重定向需满足下面两个条件：

SSL 中设置了 Flexible，CDN 以 HTTP 协议回源网站。
源网站支持 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 报重定向次数过多的问题，可以通过上面的思路查找问题。