最近Github的白嫖Pages是越发的访问不稳定了，想使用CF的CDN加速一下，先正常托管DNS域名mbstudio.cn到CF上，解析mbstudio.cn和www到CNAME值meineson.github.io（只是启用了DNS解析，没打开Proxy代理加速开关，一切正常）。
github pages使用的是HEXO搭建，已经手工修改掉源码里的CDN缓存js文件，但还是慢的发指，git pages仓库的setting里已经启用了自定义域名（会在meineson.github.io的git仓库的根目录下自动创建一个CNAME文件，里面值就是自定义域名mbstudio.cn）。
回到CF上启用proxy，以为万事大吉，结果301无限死循环来了。
甚至直接输入原始的meineson.github.io也会立即被跳转到mbstudio.cn然后301死循环（另外的www也一样）。
尝试去git仓库后台删除自定义域名，即仓库里的CNAME文件被删掉，可通过原始meineson.github.io访问了，但再次通过mbstudio.cn自定义域名访问时，就提示404了。
简单分析了下原理：
因为无论是通过IP地址还是CNAME记录跳转到github pages的服务器（大概是4个ip地址，给所有用户共用），它都要检测被访问域名，如果git仓库没有设置自定义域名时，它只认meineson.github.io这个原始二级域名，而如果设置了自定义域名，访问目标是二级域名meineson.github.io时，会被强制301重定向到自定义域名mbstudio.cn（因为CF没启用代理，还是回到github服务器上）再获取网站内容。
所以当CF开启CDN加速后，理论上是用户输入自定义域名mbstudio.cn访问时，CF会返回它的随机CDN服务器地址给用户而隐藏实际地址，用户实际访问的是应当是CF服务器上缓存的HTML文件，会非常快速。
但问题出在CF的CDN服务器转发了用户的请求到达github服务器时，github服务器并没有识别到被访问域名是mbstudio.cn，并没有直接返回网站内容HTML数据，而是返回301让以自定义域名重新访问github服务器，CDN服务器也直接转发了该301回复，用户浏览器收到301再次访问301目标mbstudio.cn时，再次到达CDN服务器重复上述逻辑，造成死循环……
由于截至目前仍未找到有效的解决办法，取消CDN可以恢复github pages的访问但还是速度感人，暂时通过CF的Workers & Pages功能，新建一个Pages发布，直接连接github仓库，自动克隆github的hexo源码仓库，build命令使用：
1 | npx hexo generate |
build输出目录设置为：public
然后再启用CF的Pages的自定义域名并正常启用CF的CDN proxy功能，mbstudio.cn终于达到可用的访问速度了。
同时，CF也会自动监测github上的新提交，自动build发布，所以和github自己的pages使用体验是一样的，只需在本地正常编写文章并push到github，就可以更新网站内容。