记录一次由jsDelivr引起的FF14工具失效日志
事情是这样的，最近 FF14 的 6.0 国服实装了，于是这几个月一直在高强度打狒狒。主线做完后想着就把所有生产/采集干满级吧，于是就用回了以前一直在用的 TeamCraft 工具。作为生产系玩家，TC 的用途可以说一直是生产辅助工具的天花板，但由于其服务器架设在国外，所以对国内的玩家不是很友好，或者加载太慢，或者直接没法工作。
但我是没啥意见的，毕竟自己一直有在路由上架设全局代理的习惯，于是 TC 的服务器自然也在代理的规则里面，所以用起来一直都很舒适。但是到了最近，TC 开始出现了一些问题。具体情况如下：
有时报错信息还会是类似于这样：
其中，报错信息中提到的IP地址大多为 Twitter 和 Facebook 相关，考虑到 TC 的功能，也许是一些 CDN 的线路。
从报错提示不难推测这是个网络问题，而且和TLS加密有些关系。但是只知道这些，问题的范畴还是过大了一些，因为作为一个实时联网的工具，总是要和上游的服务器进行通讯的，那么如果采用 HTTPS 通讯，TLS 自然就是到处都是，难以去测试问题所在。
还有一个问题，尽管 TC 的源代码在 Github 上已经开源，但由于其使用的是Node.js编写，我对此一窍不通，因而想要去从源代码解决问题显然是过于为难我了，我只能从用户侧角度去看看究竟是怎样的问题影响了软件的通讯。
首当其冲想到的就是软件的更新，TC 的更新迭代一直很频繁，大概每隔一两周就会有一些小版本更新，来进行一些 bug 的修复，那么会不会是进行漏洞修复的过程中引入了这样的问题？抱着这样的疑惑点开了 Github 的 issue 的界面，结果在其中没有找到类似的问题提交，于此相关的问题最新也得追溯到 21 年，显然应该不是更新引起的问题。但抱着试一试的心态，我还是下载了最近的 3 次更新的安装包，测试结果无一例外，都是类似于这样的报错。
既然不是代码的问题，那么一定就是我的环境出现了问题了。既然是和网络相关的问题，那么自然也和代理脱不了干系。一直以来，我用 TC 都是依靠路由端的代理，从未去动过软件本身的代理设置。于是，我尝试在软件本身的代理设置中启动 SOCK5 代理，看看能不能有效。 结果依然如此，问题依然出现，似乎问题也和网络没什么关系了？
就这样摆烂了几天，最终还是忍受不了，依然觉得应该是网络的配置出现了问题。但既然 TC 本身的代理没法看出什么端倪，那么只能通过外部手段来进行分析了。当然一开始也还不至于祭出 Wireshark 之类的工具，而是先用 Proxifier 来观察被代理的链接。应该说这次的成果确实不错，从 Proxifier 的日志中，看到 TC 一共走了三个外部域名，分别是 Google Analysis 、北美 FF14 官网，以及 jsDelivr 的 CDN 线路。
我想看到有 jsDelivr 在其中，大部分人大概都能知道发生了什么了。jsDelivr 的国内线路一直是时好时坏，以至于代理的线路无法实时判断是否需要对 jsDelivr 的线路进行代理，因而才出现了这样的问题。于是，将 jsDelivr 的 CDN 线路写入到强制代理的规则当中，再次启动 TC ，一切功能都完好如初。
2022 年 5 月 19 日更新
在向原作者提交了一个 issue 希望他能增加一个网络环境检测工具【类似于POI中那样直接确认联通与否，或者更高级一些，能有详细报告之类的】之后，原作者表示 JsDelivr 是专门给大陆用户用来 CDN 加速的。因为直接抓取 Github 的 raw 在大陆很大概率是没法用的，没想到 JsDeliver 也会出问题（从百度检索的结果来看，大概是在 17 号左右开始出问题的）。于是我俩换个备用方案，内容如下。
我 fork 了需要被抓取的仓库，然后我在自己的仓库里写了两个 workflow， 一个的内容是定时更新 fork 的内容，保证每次原仓库更新后我的仓库能及时更新；第二个内容是将我的仓库和在 Gitee 的同名仓库保持同步，确保我的仓库在更新完后 Gitee 那边也能正常更新。【从道理上来说，直接写个 commit 给仓库作者也不是不行，但这样太不守规了】。最后 TC 的作者将 CN 的规则写为走 Gitee 的 raw 抓取，这样就保证国内用户的使用体验了。
其实这样的问题也蛮多的，首当其冲的就是 5 月 18 号 Gitee 修改了自己的开源政策，虽然现阶段来看大部分的仓库还是可以正常进行公开并抓取，但是未来不好说。
第二个就是更新的时效性。目前设置是每 4 小时进行一次更新，因为原仓库那边只是在每次版本更新后（一两天内？）才会进行内容的修改，所以大部分情况下我的仓库更新脚本是没有用的，但最优的解决方法还是和上面一样【指直接把 Github Action 写在原仓库里】，所以目前只能采用这样的方法。具体时间间隔还会随着未来的效果进行调整。
说到底，其实只要 JsDelivr 在国内稍微再稳定一些，完全可以回归到使用 JsDelivr 上来，但未来的变数有多少，尚且不是很明朗。