在大家开始阅读此文之前，小编先陈述下自己的观点：非必要的情况，国内站点尽可能不使用Cloudflare的CDN服务。除非你所搭建的WordPress网站所使用的服务器不在境内，否则国内有很多CDN服务可以满足你的网站加速需求，比如阿里云、腾讯云，七牛云、UPYUN等服务商提供的CDN。

但，如果你非得要使用Cloudflare的CDN，不妨看看sleele这篇教程，思路清晰且易于理解，enjoy！

前言

最近再一次着手优化博客的访问速度，基于上次的优化再次提升，这次用上了我之前放弃的cloudflare cdn加速方案，现在有了新的思路和新的工具。

cloudflare的cdn节点都在海外，国内访问速度其实并不理想，如果自己的vps线路质量可以的话，用cloudflare cdn反倒会减速，这是我之前的想法，但是自cloudflare推出了cloudflare partner计划，可以通过partner免费使用cname解析，从而可以使用某些奇淫巧术实现自定义cdn节点。

dnspod dns解析

本来想按逻辑顺序来写，但是考虑到实际操作是按照工具顺序来执行，就先从dns解析说起吧！

以往如果我们要使用cloudflare的免费cdn，就要使用cloudflare的dns解析，现在有了partner计划，可以免费使用cname解析，这次我们选用dnspod提供的dns解析，dnspod还提供d监控服务，d监控可以监控网站线路，并根据网络情况自动切换节点

先说说什么是d监控

什么是D监控？
D监控就是：当您的一个服务器确认宕机后，系统会自动给您切换到可用的服务器，宕掉的服务器恢复后自动切换回原ip（注意：系统不默认开启D监控，需要您手动启用D监控）
检测的原理：所有监控点会向目标服 务器发起一次 http请求，当且仅当所有监控点都得不到应答时，我们会认为服务器宕机，从而进行操作。（这里需要注意的是，403等错误返回只提示警告，不进行ip切换，500以上错误返回提示宕机，进行切换）

要使用dnspod dns解析,首先要注册dnspod，并把域名挂在上面，这个相信有能力建站的人都会操作，我就不赘述了

域名放在dnspod dns解析后，暂时不要设置d监控，现在可以去搞cname了

cloudflare partner

先注册cloudflare账号(http://cloudflare.com/)，之后去cloudflare partner处登录。

我使用的是笨牛网提供的cloudflare partner服务：https://cdn.bnxb.com/，

注册登录笨牛网的cloudflare partner服务，然后选择添加域名，使用cname方式接入。

BNXB管理后台

提交后会给出cname地址，把cname地址填写进dnspod的dns解析中。

CNAME回源设置

过一会就会生效，ping一下的网站，看是否走了cloudflare cdn,如果这时候走了cloudflare cdn，那么ping网站的时候会出现cname地址。

重头戏来了

cname接入cloudflare cdn最大的好处就是可以自定义cdn节点，这样我们就可以选择国内访问最快的cloudflare cdn节点，从而实现加速访问，并且在d监控的加持下防止网站因线路的缘故中断访问。

目前cloudflare所提供的免费节点很多都被玩烂了，所以需要大家自行测试。

我这里分享一些网上的提供的ip，这些ip段，从中选择ip段后修改ip地址，填写到dnspod中，例172.64.32.56，并且按照运营商填写，每个运营商填写两个节点，海外为默认：

172.64.32.1/24 （推荐移动，走香港）

104.28.14.0/24 （推荐移动，走新加坡）

104.23.240.0-104.23.243.254 （推荐联通、移动，线路未知）

108.162.236.1/24 （推荐联通，走美国）

104.20.157.0/24 （推荐联通，走日本）

104.16.160.1/24 （推荐电信，走洛杉矶）

172.64.0.0/24 （推荐电信，走旧金山）

172.64.32.* （走欧洲）

108.162.236.1/24 联通 走美国

172.64.32.1/24 移动 走香港

104.16.160.1/24 电信 走美国洛杉矶

172.64.0.0/24 电信 美国旧金山

104.20.157.0/24 联通 走日本

104.28.14.0/24 移动 走新加坡

104.18.62.1/24 香港hkix.net

104.16.35.1/24 香港hkix.net

104.16.36.1/24 香港hkix.net

104.18.35.1/24 香港hkix.net

104.18.36.1/24 香港hkix.net

104.16.54.1/24 香港

104.16.55.1/24 香港

104.18.128.1/24 香港

104.18.129.1/24 香港

104.18.130.1/24 香港

104.18.131.1/24 香港

104.18.132.1/24 香港

104.19.195.1/24 香港

104.19.196.1/24 香港

104.19.197.1/24 香港

104.19.198.1/24 香港

104.19.199.1/24 香港

#适合电信的节点

104.23.240.*

#走欧洲各国出口 英国德国荷兰等 延迟比美国高一些 适合源站在欧洲的网站

172.64.32.*

#虽然去程走新加坡，但是回程线路的绕路的，实际效果不好，不推荐

104.16.160.*

#圣何塞的线路，比洛杉矶要快一点，推荐

108.162.236.*

#亚特兰大线路，延迟稳定，但是延迟较高

#适合移动的节点

162.158.133.*

#走的丹麦，这一段ip只有部分能用，可以自己试一下，绕美国

198.41.214.*

198.41.212.*

198.41.208.*

198.41.209.*

172.64.32.*

141.101.115.*

#移动走香港的IP段有很多，以上并不是全部。CF移动走香港的分直连和走ntt的效果都挺不错的，不过部分地区晚上还是会丢包。

172.64.0. *

#这是走圣何塞的，一般用香港的就行

172.64.16.*

#欧洲线路.绕

#1.0.0.1效果较好

电信部分

大多数省直接使用1.0.0.0即可，延迟低，丢包少，

# 移动部分

#新加坡

104.18.48.0-104.18.63.255

104.24.112.0-104.24.127.255

104.27.128.0-104.27.143.255

104.28.0.0-104.28.15.255

# 移动部分

#圣何塞

104.28.16.0-31.255

104.27.144.0-243.254

104.23.240.0-243.254

#香港cloudflare1-100g.hkix.net

1.0.0.0-254

1.1.1.0-254

#香港直连

104.16.0.0-79.255

104.16.96.0-175.254

104.16.192.0-207.255

还有奇淫巧术

如果不想测试那么多节点，或者担心节点挂掉，可以把除默认外所有的记录值都写成1.0.0.1这样，cloudflare会自己判断，解析后dns记录会全都转到1.0.0.1，看起来很秀：

域名DNS管理

开启D监控

点击下图标示的图标，把节点都勾选上；

D监控设置

查看节点情况，目前免费节点的延迟都是忽高忽低，只要对应运营商线路的节点没红就没事。

DNSPod域名监控

之后如果对节点不满意就在dnspod里更换节点即可，生效很快，d监控里就可以及时查看新节点情况

cloudflare page rules

cloudflare默认不会缓存html文件，所以为了把数据尽可能多的放到cloudflare节点里，我们需要对缓存内容进行设置。

这是cloudflare官方的 page rules讲解，建议看一看，懒得看也没有关系，按照我的设置来也行：

Page rules设置

注意！有先后顺序

sleele.com/wp-admin*

sleele.com/*preview=true*

sleele.com/*

cloudflare缓存需要时间，所以edge cache ttl设置时间长一些最好，否则还没缓存到cdn就过期了，我设置的7天，后台和预览文章不缓存。

这里再插一句，因为免费账户只有3条规则，对于WordPress是不够用的，为了节省规则，需要修改WordPress登录地址，将其变为wp-adminxxxx；

安装Rename wp-login.php插件，修改登录地址为wp-adminxxxx。

WordPress后台登录地址

测试是否缓存成功

这个可能要等一会才能看到效果，不过是否走cdn节点当时就能够看出来，

关掉代理软件，打开Chrome开发者模式，Network 选项卡，Disable cache 禁用浏览器缓存，选择自己的网站网址，Headers标签，查看Remote Address是否为之前在dns解析处设定的地址。

缓存命中查看

cf-cache-status: HIT则为命中缓存，查看Timing标签，看TTFB时间，越短越好。

TTFB信息查看

经过CDN后访客IP地址不正确的解决办法

使用cloudflare cdn后，访客的ip和留言ip都会变为cloudflare cdn的ip，解决办法也非常简单，cloudflare官方给出解决办法。

Cloudflare将访问者的 IP 地址包含在  X-Forwarded-For 标头和 CF-Connecting-IP 标头。

修改Nginx配置文件，在http内容里添加如下内容，把cloudflare的ip段添加进去：

location / {

set_real_ip_from 103.21.244.0/22;

set_real_ip_from 103.22.200.0/22;

set_real_ip_from 103.31.4.0/22;

set_real_ip_from 104.16.0.0/12;

set_real_ip_from 108.162.192.0/18;

set_real_ip_from 131.0.72.0/22;

set_real_ip_from 141.101.64.0/18;

set_real_ip_from 162.158.0.0/15;

set_real_ip_from 172.64.0.0/13;

set_real_ip_from 173.245.48.0/20;

set_real_ip_from 188.114.96.0/20;

set_real_ip_from 190.93.240.0/20;

set_real_ip_from 197.234.240.0/22;

set_real_ip_from 198.41.128.0/17;

set_real_ip_from 199.27.128.0/21;

set_real_ip_from 2400:cb00::/32;

set_real_ip_from 2606:4700::/32;

set_real_ip_from 2803:f800::/32;

set_real_ip_from 2405:b500::/32;

set_real_ip_from 2405:8100::/32;

set_real_ip_from 2c0f:f248::/32;

set_real_ip_from 2a06:98c0::/29;

# use any of the following two

real_ip_header CF-Connecting-IP;

#real_ip_header X-Forwarded-For;

}

# 加载配置

nginx -s reload

WordPress再加速

WordPress是动态生成网页，为了进一步提高加载速度，使用WP Super Cache可以生成静态页面，同时开启gzip压缩选项，Cache Everything可以把gzip压缩后的html缓存进cdn，以提升加载速度。另一款Autoptimize插件也提供非常优秀的WordPress优化支持。

WP Super Cache页面压缩开启

WP Super Cache压缩生效与否

除此之外，建议安装官方插件cloudflare

可以手动和自动清除缓存，查看数据分析，非常有用。

cloudflare插件安装

速度测试

首先说一下，这些速度测试的分数只能作为参考，没有太大的实际意义，特别是谷歌测试。

boce全国速度测试

boce网站速度测试

Google PageSpeed Insights

Google PageSpeed Insights

Pingdom Website Speed Test

Pingdom

关于网站测速，可以阅读网站测速性能测试深入浅出教程[附15款常用网站测速工具]和如何做到Google PageSpeed Insights测试满分/100分两篇文章！

结语

目前免费的cloudflare cdn加速手段就这些了，在page rules里我禁用了性能优化，不推荐开启。还有一个付费的据说能够大幅提升速度，我没用过。经过以上优化，大部分人应该能够在3秒内打开我的网站 https://sleele.com/。

Railgun 是 Cloudflare 专门为 Business 和 Enterprise 企业级客户提供的终极加速方案。要使用它，先需要升级网站套餐为 Business 或 Enterprise，然后还需要在服务器上安装必要软件并在 Cloudflare 上完成配置。这相当于是一个双边加速的软件，其实现原理是让服务器与 Cloudflare 建立一个长久的 TCP 加密连接，使用 Railgun 独有协议而不是 HTTP 协议，这样显然能减少连接延迟。此外，它还会对动态页面缓存：考虑到大多动态页面都包含了大量相同的 HTML 信息，在用户请求一个新的页面时，服务器将只发送那些变化了的内容。这相当于一种多次的 Gzip 压缩。

文章转自《sleele的博客》，稍有改动。