jsdelivr 出现 Failed to fetch @latest from GitHub 原因分析+解决办法

今早起来发现采用jsdelivr加载静态资源的链接访问出现了404，取其中一个404状态的链接单独访问，出现Failed to fetch version info for GithubName/仓库名 。

奇怪的是，同一个仓库下，有的链接却没有问题，而本站的链接，也有一个静态文件出现404。而本站的链接跟前面的链接不是同一个Github用户，并且我也没做什么改动。

jsdelivr 404

于是Google搜索，看到有人说是release包大于50MB导致，特意下载查看大小，压缩包只有17MB，解压后不到45MB，不管如何都没超出50MB的范围，可见也不是这个原因导致。

如果是release包大的问题导致，那么本站的release包肯定不大，解压都不超过10MB，又继续搜索，见有人说是github仓库许久不更新的原因，两个月不更新就会出现这个状况。

当然，也不推荐使用jsdelivr cdn加速你的Github上存在的大量图片，这会让jsdelivr以为你使用图站从而导致给禁用的风险增加。

但我的前几天才更新了，都不到一个礼拜，可见也不大可能是这个原因。但还是重新推送了一次，更新下看看，后面果然不行。

大概又过了十多分钟后，发现问题自己解决了。但本站的那个静态文件还是404，并且不是同一个Github用户，出现这个问题的原因我猜想有两种情况。

第一种情况，就是jsdelivr的节点问题，获取不到Github文件信息，版本信息，这种可能性是最大。

第二种情况，可能与你网站访问有关，我前面的两个网站，主要用来测试，因此日常没有任何访问量，可能是因为好几天没有访问，CDN节点把缓存给清理了，导致现在访问一下不能获取文件信息。

不过，第二种猜想也经不起推敲，如果是这样，那么本站站点就不应该出现任何jsdelivr的404链接，因为昨天晚上我才推送文章更新了，并且自己访问了。

因此我还是倾向于第一种情况，版本号我直接用的是@latest。测试的两网站分别是由Wordpress程序构建的网站和Hugo生成的网站，Wordpress的静态文件全部是404，Hugo网站的静态文件70%是404，而这两个网站的静态文件资源都是存放到一个Github仓库。

WordPress用的是Serverless搭建了，为了减少云函数计算的调用次数，我把静态文件都用jsdelivr cdn加速了。想体验serverless搭建博客的可参考《Serverless云函数计算搭建Typecho和Wordpress网站》

不清楚jsdelivr背后的原理，问题比较玄的还不止这一次。之前，我的静态文件链接都是没有取用版本号的形式来用的，也能正常使用。后来某一天，发现忽然都不能访问了，全部404，搜索后发现可能是链接没有指定版本号的缘故，于是立马添加版本号然后指定，问题得以解决。

而后我又时不时的手动测试，加版本号和不加版本号访问，都能正常，并且排除浏览器缓存问题。给我的感觉好像是加了版本号访问稳定些的样子，而今天的这个问题，我指定其他版本号也不能访问，去掉版本号还是404。

所以猜测是jsdelivr用的网宿节点，而网宿的某些节点出现问题导致的状况。如果你直接搜索jsdelivr挂了，会出现不少相关的讨论话题。

如果你的站点访问量大，最好准备另一套CDN作为备用。而静态网站解决这个问题的方法也很简单，就是复制一份主题，改写静态资源调用的相关文件，写好你的备用CDN链接即可。如果挂了，及时更新即可。当然你也可以选择一个跟jsdelivr相似的CDNstatically.io，不过这个CDN目前没有国内节点，访问速度也不算快。

还可以采用本地一套配置，Coding上配置另一套，比如本地走的是jsdelivr cdn路线，那么在coding上我配置的是七牛的CDN，如果jsdelivr不正常了，只需在coding发动一次更新即可。具体还得参考《Coding持续集成自动同步到GitHub》和《Github Actions自动部署Hexo博客》两篇文章，需要用到Coding的持续集成推送到Github，然后由Github Actions来执行Hexo g生成静态网页推送到Github Pages。

文章都写完了才想起了，当故障发生的时候，我应该在移动和电信网络之间切换看看，会不会出现同样的状况。