疑问

远程同步配置有CNAME选项，一定要CNAME到GitHub绑定的域名，因为Gridea要覆写根目录下的CNAME文件，如果配置不正确，GitHub绑定的域名将无法访问。
我未理解的结果：我使用了EdgeOne加速，理论上将，如果直接访问GitHub，应该就是原生站点，结果访问原生站点，页面也会转到CDN的域名，暂时没有搞懂。不过结果是好的：速度快。

认识

通过实践的新认识：

CNAME文件：为了让GitHub知道该用哪个域名来访问您的网站，需要在仓库的特定位置放置一个名为CNAME（注意，文件名必须全部大写，且无后缀）的文件。这个文件是关键配置，其作用包括：告诉GitHub“我是谁”。文件内只包含一个域名（如：blog.yourdomain.com）。GitHub Pages系统会优先读取此文件来确定网站的自定义域名，其优先级高于在GitHub网页端的设置。每个GitHub Pages仓库的CNAME文件只能指定一个主域名。如果需要多个域名访问，需要在DNS服务商层面进行转发配置。
双向同步：您既可以在GitHub仓库设置中填写域名自动生成此文件，也可以手动创建并提交，GitHub会自动检测并同步。实践证明：CNAME文件修改后，GitHub Pages-Pages-CustomDomain会自动更新。

进阶

如果在Gridea的远程同步配置-CNAME选项，从应用来看，仅有的作用就是写Github的CNAME文件，并不会在生成静态页面时有任何作用。所以一般这里配置GitHub绑定域名，是标准操作，没有问题。
但如果使用了CDN加速，那么访问CDN网站的域名，首页是没问题，CDN加速成功。但点击页面链接时，Gridea使用的是GitHub原生域名（name.github.io）。如果此时网络正常，GitHub会返回绑定域名的URL，但实际上，此时访问的是GitHub，CDN是被架空的；如果此时网络不正常，直接反馈name.github.io访问失败。
如果在Gridea的远程同步配置-CNAME选项，配置了CDN域名，这就有意思了。首页是没问题，CDN加速成功。点击页面链接时，访问GitHub原生域名（name.github.io）。如果此时网络正常，GitHub会返回绑定域名的URL（注意，此时GitHub绑定的域名是CDN域名），所以实际上是访问的CDN；如果此时网络不正常，直接反馈name.github.io访问失败。有个小问题：Custom domain会提示DNS Check in Progress——必然的，域名解析到了CDN，自然不会解析到GitHub。
问题根源：Gridea在生成页面时，应当使用CNAME嵌入页面URL，而非使用GitHub原生域名（name.github.io）。这样，如果访问GitHubPages原生域名，除首页外，博页面访问都将提交到CDN，相当于被架空；如果直接访问CDN域名，则更不存在问题。流程就是：Gridea提交页面到GitHubPages，CDN从GitHubPages抓取页面，用户通过CDN域名访问。GitHubPages就是一个仓库的作用。

Tips

由于域名解析和CDN的问题，直接访问GitHub，页面也会转到CDN的域名，应该是DNS缓存和CDN缓存的问题。
相信自己，时间过了就应该不存在这个问题了。

结论

Gridea远程同步配置CNAME选项，配置CDN域名。