这个其实很早以前就做过测试了，一直想着发文说说，但是一直鸽了，今天先写文，把别的事情放一放哈哈。

首先先说Railgun官方介绍的是大幅度减少动态内容传输并减少带宽，但是这里有个大坑官方并没有说明

什么大坑呢，也就是在大流量的站启用Railgun之后并不会减少你的服务器带宽使用，反而会大大增加，在自己的一个小项目上启用了之后发现带宽使用增加了大概2.5-3倍，这个比例其实是很可怕的

下面我们来一个完整的流程演示吧

测试正常访问cloudflare加速后的站点和开启了railgun之后的站点，测试页面为phpinfo

首先是正常访问经过cloudflare cdn加速的站点

我们可以看到正常访问时的headers请求(因为我开着某种工具，所以cloudflare分配到了台湾节点)，和源站服务器的日志文件，可以看到我们开启gzip后cloudflare的去源节点从我们的源站服务器获取了24395字节的文件

接下来我们开启railgun功能

我们可以看到在开启railgun加速功能后，浏览器的headers里可以看到railgun的特有信息，经过railgun加速后的页面只传递了原始页面13%的内容

但是我们去检查我们的源站服务器web日志会发现，流程依然是初次访问分配到cloudflare的去源节点(图中的162.158.241.34)，后续访问都是经过我们的railgun节点，

问题所在

仔细看，你就会发现问题所在了，就是cloudflare官方所说的大幅度减少动态内容传递从而减少带宽使用其实没有完整的介绍，这个大幅度减少动态内容是指railgun节点跟cloudflare通讯传递的内容，但是railgun节点去你的源站服务器的访问读取动态内容源时，并未使用任何压缩(是的，就是这里导致了在大流量的情况下，源站服务器的带宽消耗增加数倍)

可能这时候有人会说了，是不是你设置问题，或者是你用的http，没使用cloudflare里https的brotli压缩，那个比gzip还压缩得多呢，
其实我全都测试了，gzip和brotli压缩是cloudfalre节点到用户端的压缩，无论你怎么修改相关设置，railgun节点到你源站是不会使用任何压缩方式的。

至此

cloudflare的railgun加速功能深入解析完毕，感谢您的观看

问题描述完毕 End

对了，如果您是自己用自己的cfp，让源站和railgun在同一台服务器或者是内网里，就不用担心这个无形中消耗流量的问题拉

但是如果您是用cloudflare的官方套餐里的railgun节点或者是使用cfp接入用别人的railgun节点，就存在这个问题哦

railgun的其他说明

什么时候使用railgun

假如源站的带宽比较大，你的站流量不大的情况下玩玩还是很推荐railgun的

但是如果你源站只有一点点带宽，你的站点流量又大的情况下，还是尽量不要用这个功能了
除非你能接受源站带宽翻倍跑换来握手成功后减少TTFB值(源站不限流量之类的情况)

railgun 最好安装在本机 或者同一个子网内

原理是长时间保持动态请求通道 越近越好

railgun 加速的页面最好大于100kb 有压缩效果

页面太小 会有判断的时间 反而效果不好

railgun 亚洲数据中心 好像只有一个节点 在新加坡

理论上 railgun 服务器离新加坡数据中心越近越好

用了别的CF PRO后再用自己的railgun

先在自己cfp接入，开启railgun，
调试成功之后，然后在去别的提供cfpro里接入 就行了，railgun不会掉