Cloudflare的强大之处无需多言，在对客户网站进行DDoS防御方面，它若称第二，基本无人敢称第一。
不过可惜的是，Cloudflare除了Enterprise版本可以额外付费启用中国节点外，其他版本都无法开启，并且Enterprise套餐+中国大陆节点的起步价格基本上是$3000/月。（所以为什么我不是外国人啊，一分钱都不用花就能拿到等值几千美金的服务）
因此，使用Cloudflare免费版保护网站速度便不是很理想，这就是为什么许多站长都喜欢叫它“网站减速器”。
那么这篇博文，就来教学一下如何利用Cloudflare免费版（以下简称Cloudflare）保护网站，同时又不过多影响网站的访问速度。
动静分离
网页中的内容基本上都可以分为动态和静态两部分（有些网页是纯静态）。其中，HTML部分基本上都是动态，其中会包含许多实时性的内容，比如博客页面上的浏览量、留言；而剩下的CSS、JS以及音乐、图片、视频等媒体文件基本上都是静态的，一般不会因为访客的交互而更改。
当然，还有一种更高级的方式，即HTML部分也是静态的，而浏览量、留言等这些动态内容则由另外的接口提供，然后使用JS在用户的浏览器上动态渲染。
Cloudflare在国内的网络质量也许并不像大多数站长想得那样糟糕。目前来说，它的网络在国内的特点是传输小文件时不会怎么拖慢速度（在正常的跨国传输延迟之内），而且稳定性也不错，不会出现隔三岔五无法访问的情况；而如果传输大文件则网速会很不稳定（尤其是高峰期），并发请求则容易导致其中的部分请求响应慢或者失败。
因此，相信各位读者基本上已经知道为什么要做动静分离了。一个完整的网页在加载时会产生很多请求，其中大多数都是对静态资源的请求，而这恰好就是Cloudflare网络在国内的弱点。
很多时候，访问使用了Cloudflare的网站很慢，并不是因为HTML部分未加载完毕，通常都是因为静态资源没有传输完。
对于个人站长而言，动静分离还是很好做的。很多主题都有“静态资源CDN”的选项，如果条件允许，我更建议使用自己的CDN而不是公共CDN。公共CDN一般都只会收录一些较为知名的开源前端项目，因此它们不包含的主题私有静态资源往往还需要从原站点加载，即通过Cloudflare传输；但如果是自建就没这个问题。
例如我的博客，静态资源和图片都是从和主站不同的域名加载的，只有动态部分走的是Cloudflare，整体的加载速度和全局使用境内CDN的差别并不是很大。
总的来说，就是动静分离一定要做得彻底，除非你并不介意网页加载缓慢，亦或是静态资源加载失败导致的网页样式怪异。
关闭不必要功能
Cloudflare内置了许多优化功能，即使是免费版也可以使用。其中有两个位于“速度->优化->内容优化”中的功能，虽然是用来优化网页加载速度、提升访客隐私安全性的，但实际上对于国内网络环境而言，它们会拖慢网页的加载速度。
第一个建议关闭的功能是Cloudflare Fonts，其作用是自动将网页中对Google Fonts引用的部分更改为从站长自己的域名上引用，并且字体文件Cloudflare会自动提供，不需要自行上传到源服务器。
这项功能可以减少Google对网站访客的数据收集。用户在请求Google Fonts的时候，会携带上当前正在访问的网址作为referer头一并发送，Google只需要对用户访问的网页进行一次爬取，即可了解用户的上网偏好。同时，复用已经请求过的域名和连接获取字体文件可以加快网页的加载速度。
这项功能可以说是相当不错的，但很可惜它并不适合国内访客。Google Fonts到目前为止已经有很多个中国大陆的节点（以前是没有的，甚至还会被屏蔽），而Cloudflare免费版并没有；加之字体文件一般比较大，对于国内访客而言，Cloudflare的字体库会比Google的字体库慢得多，甚至会请求失败。
不过因为历史问题，国内的商业主题一般很少会有对Google Fonts的引用，需要注意这个问题的，大多数是使用国外开发者开发的主题或Github上开源主题的站长。
第二个建议关闭的功能是Rocket Loader，其作用是缩短包含JavaScript的页面的绘制时间，大致原理就是让页面上的JavaScript异步加载，防止它们阻碍页面内容的渲染。
这项功能开启后，Cloudflare会自动在所有网页内添加两个对外部JS的引用，其顶级域名都是cloudflare.com，并且这两个JS文件的体积都不算小。因此对海外地区的访客而言，这项功能可能还算有用；但对国内访客而言，就会严重拖慢网页加载速度。
综上，这部分内容本质上和“动静分离”都是一样的，即都是只让网页中的动态内容经过Cloudflare，并尽最大可能不让网页上的任何静态内容从Cloudflare上加载。
设置合理的WAF规则
WAF所提供的保护功能，才是我们忍着速度慢也要使用Cloudflare的根本目的。但Cloudflare的灵活性远超其他同行，因此为了防止过多影响网站的访问，初始规则基本上无法满足我们保护网站的需求。
但WAF规则的设置其实比较棘手，很难做到对安全和访问体验的完美平衡。尤其是Cloudflare的托管质询页面，有对Cloudflare静态资源的大量引用，国内访客在遇到这个页面的时候体验一般都很不好。
首先，要过滤掉一些垃圾爬虫，这些爬虫大多数都来源于境外，基本上都是一些做SEO、互联网反链收集的。对中文站长而言，这些爬虫完全没有任何用处，并且它们每天都在大量、反复爬取，完全就是在浪费服务器资源。下面是通过UA过滤这些垃圾爬虫的WAF规则示例。
接下来，便是配置一些其他规则以阻止可能的L7应用层攻击。比较实用的做法是对HTTP版本进行判断，不是2或3，并且不是合法的爬虫，就对其进行质询。通常情况下，我们使用的浏览器都会优先使用较高的HTTP版本，很少会有“服务端支持HTTP/2，但是浏览器仍旧使用HTTP/1.1”的情况出现。
也就是说，我们在Cloudflare仪表板上开启了对HTTP2和QUIC的支持后，基本上真实访客用的都是这两个协议，用HTTP/1.1的则大概率是爬虫和僵尸网络的攻击。而我们的规则又排除了对合法爬虫的质询，因此这一条规则效果相当不错，而且很少有误拦截。
剩下的规则，基本上就需要站长根据自己站点的实际情况进行增补了，没有什么规则是适合所有网站的，一味照搬只可能会适得其反。最好的办法便是经常性查看自己站点的访问日志，定期总结一下最近一段时间恶意请求的特征，根据它们编写适合自己站点的WAF规则。
后话
还有几个比较小的细节给各位站长分享一下，可选，不做也不会有什么大的影响。
第一，国内站点使用Cloudflare的时候最好使用CNAME接入，不要NS接入，Cloudflare的域名服务器都在国外，速度不快（基本感觉不出来）。接入的子域名没办法，但至少可以让没接入的子域名解析速度快一些。可参考《通过CNAME将域名接入Cloudflare》一文。
第二，不要再尝试“Cloudflare自选IP”之类的操作了，已经相当过时。目前，Cloudflare给所有用户分配的都是Anycast IP（不了解可搜索“泛播IP”），泛播的路由是由Cloudflare管理的，因此理论上，不管怎么选最终结果基本都一样。而且使用自选IP，很可能会因为官方维护而导致该IP不可用，因此还是老老实实的别动它最好。
第三，使用站点可用性监控一类的产品，并且一定要用国内的。像UptimeRobot之类的服务商，检测都是从海外地区发起的，以Cloudflare的实力，海外监控真没什么必要，除非自己的源站挂了。这里比较推荐阿里云的云监控，首次开通还能免费领100万次，基本上挥霍一年没啥问题。在国内监控到站点不稳定时，可以考虑切换回境内CDN，待一段时间后再做尝试。
最后，一定不要滥用Cloudflare的服务，免费是情分不是本分，人家的网络规模再庞大也不是用户随意挥霍的理由。且不说国内能不能做出来这么好的产品，就算做出来，也不知道价格得飙到什么程度去，且用且珍惜。