jsDelivr域名遭到GFW封锁
前情提要--jsDelivr 备案被吊销
2021年12月20日，jsDelivr 团队主要负责人 Dmitriy Akulov 在 jsDelivr 官方 GitHub 仓库的一条 issue 下发表了以下说明：
Thank you all for your tests, feedback and support. I am personally sorry for the issues we had today.
We can consider the issue as resolved, now its a question of DNS propagation getting to everyone.
Our official announcement regarding the problems today:
Unfortunately today jsDelivr unexpectedly lost its ICP license in China. As effect the regional CDN disabled our account.
This resulted in the extended outage we had in mainland China and Taiwan.
Other regions were unaffected.
We understand how difficult it was for our users to experience this unique situation.
From now on all Chinese traffic will be served by "near China" locations provided by global CDN providers.
This will have the additional benefit of better failover logic in the future.
译文：
感谢大家的测试、反馈和支持。我个人对我们今天遇到的问题感到抱歉。
我们可以认为这个问题已经解决，现在它是一个 DNS 传播问题。
我们今天关于问题的官方公告：
不幸的是，今天 jsDelivr 意外失去了在中国的 ICP 牌照。结果，区域 CDN 禁用了我们的帐户。
这导致我们在中国大陆和台湾的停电时间延长。
其他地区不受影响。
我们了解我们的用户体验这种独特的情况是多么困难。
从现在开始，所有中国流量都将由全球 CDN 提供商提供的“中国附近”位置提供服务。
这将在未来获得更好的故障转移逻辑的额外好处。
当天jsDelivr 在国内的故障，并不是偶发的 SSL 证书出现问题导致资源下线，而是域名备案被吊销，导致国内 CDN 提供商网宿移除了 jsDelivr 的账号。当时 jsDelivr 国内线路为 Fastly：
2021年12月20日 - 可喜可贺的一天，jsDelivr 的 ICP 没了。最少在短时间内，jsDelivr 是无法也不会提供基于国内节点的托管服务了。可以想象，也是可能的下一步，就是 jsDelivr 完全被 GFW 阻断，成为连 Google Hosted Libraries 和 cdnjs 都不如的开源 CDN - 最少这两个国内还极其勉强地能用。
封锁历程
DNS 污染
2022.04.28 GFW开始实行dns污染：
可以看到，jsDelivr的域名已经被解析到Twitter，Facebook等被阻断的IP地址上。
2022年4月28日，jsDelivr得到了与Facebook、Twitter等如出一辙的安排，主要的服务域名遭到DNS污染。在正常状态下，当你请求网站域名域名时，你的DNS服务器会逐级向上寻找这个域名的解析记录，并通过这个链条将它指向的服务器返回给你，实现域名与服务器的融合。若你的DNS逐级向上请求记录的过程中，出现了一个中间人提前抢答了错误的记录，而非来自域名权威服务器的正确回复，导致返回的结果并不是指向正确服务器的，连接因此不能建立，这便是DNS污染。
此轮封锁于2022.04.29解除。
SNI阻断
2022.05.17 jsDelivr 的域名再次被污染，同时伴随SNI阻断，即改host的方法不在有效。
此轮封锁于2022.06.11解除。
jsDelivr的命运
惊艳四座的jsDelivr
不知道提到jsDelivr，大家都是从哪一项服务开始接触到它的？由中国最大的传统CDN提供商网宿（QUANTIL）赞助，支持cdnjs和GitHub内容直接加速引用，它的应用可以说是迄今为止所有静态库中最为广泛的了。大到各种门户网站，小到个人博客，乃至去广告规则订阅、图床、插件静态库等等种种衍生场景，都能见到它的身影。
在网宿的协助下，2016年12月jsDelivr挂名在上海幻文信息科技有限公司下完成了企业ICP备案，取得了备案号【沪ICP备15005128号-2】。这是一家网宿用于代理备案的公司，通过天眼查等工具很容易看出来，历史上共有8个网站在这个公司挂名进行备案，目前除了所谓的主页已全部注销。
这是历史上第一个以较为正规的方式进入中国大陆的海外静态资源库项目，在网宿与诸多海外赞助商协同下，5年中jsDelivr提供了非常稳定且出色的服务。jsDelivr官方毫不掩饰对自己能够在中国大陆合法提供服务的喜悦，专门在节点页面中写下了“我们拥有中国政府的ICP许可证，拥有数百个服务节点的巨大中国网络”的字眼。
然而千里之堤溃于蚁穴，纵使拥有网宿这样强有力的支撑，也难抵运营以来遇到的重重阻碍。
一波三折的大陆服务
在网宿负责中国大陆的CDN节点这几年中，因为网宿方面的问题导致了几次SSL证书过期而宕机，博主有印象的在2019、2020年都有出现过。如果说那些都是网宿单方面的失误的话，2019年10月的暂时退出是jsDelivr官方面临的第一次危机。2018年工信部对域名备案政策颁布了新的规定，只有注册局在中国大陆拥有代理公司并完成申报、且域名停放在在中国大陆注册商的情况下才可以进行备案。jsDelivr挂名的公司在2019年需要进行了负责人信息的变更，备案主体信息需要进行修改，这在多个域名中都可以查到记录。
当时，jsDelivr暂时关闭了中国大陆的节点，转而使用网宿位于中国台湾和韩国首尔的节点提供服务，加载速度一落千丈。当时博主还向官方发送了一封邮件进行了咨询，官方也亲切地回应是在更新ICP备案，将在不久之后恢复。较早的issue中，官方人员进行了更详细的解释，他们在更新ICP备案的过程中遇到新规的要求将备案域名转入至中国大陆的服务商的问题，在评估后他们认为没有一种安全的方式能够确保在服务不中断的前提下将域名转移至中国大陆，因此暂时关闭中国大陆的节点等待进一步的探讨。最终在一个月后，jsDelivr恢复了位于中国大陆的节点，这次风波算是告一段落。
接下来的三年中大体相安无事，除了几乎每年一度的网宿忘记更新SSL证书。但是由于支持对GitHub项目的完整加速，对jsDelivr的滥用日趋严重，GitHub+jsDelivr图床、视频床甚至网盘层出不穷。如果说以上只是对免费资源的滥用，在GitHub中储存成人、邪教等文件通过jsDelivr向中国大陆分发，则是将jsDelivr一步步推向万丈深渊。
在2020年的8月15日，jsDelivr在官方GitHub项目中首次更新了使用限制说明，这是官方第一次明确表示禁止多种滥用行为并添加了对中国大陆政策的额外说明。在这之后，官方在网宿方向屏蔽了一系列不符合中国大陆法律内容的项目。但是由于是针对整个GitHub项目的通用加速，官方的封禁显然远远比不过肆意滥用的脚步。
命中注定的结局
jsDelivr对中国大陆的态度一直颇为暧昧，在2019年风波平息后，有不少人提议针对中国大陆的服务中GitHub加速项目应当审核开放或关闭此项以防止滥用，但官方认为将项目推送cdnjs也是很容易的事，单单禁用GitHub并不能解决不合理利用的问题，于是便没有了后文。
于是在2021年12月20日，当项目组成员在另一个半球睡得正香的时候，自上而下的命令压力下网宿直接关闭了jsDelivr的大陆CDN，几个小时后jsDelivr的ICP备案也被注销。当jsDelivr项目工作人员起来时，一脸茫然地发现网宿在未告知原因的情况下关闭了中国大陆的CDN，在愤怒之余将DNS记录切换至了Fastly恢复了jsDelivr的访问，这次的风波暂时告一段落。
但是网宿这次为何突然关闭CDN的原因依然众说纷纭，有内部人士称是因为网安部门发现了通过jsDelivr的链接传播邪教内容，但这些无从考证，官方自始至终也未对此给出任何解释。但无法改变的是，jsDelivr失去了ICP许可证，不再拥有位于中国大陆的CDN节点，加载速度大幅下降，官方也不再通过区域服务商对内容进行过滤。
在这之前有一个同样支持GitHub加速的静态资源库statically.io已被SNI阻断，与曾经的jsDelivr唯一的不同便是没有ICP许可证的保护。它走过的路，冥冥中暗示着jsDelivr注定的结局。
2022年4月28日，jsDelivr在中国大陆确认遭到DNS污染，乐章到此戛然而止。
jsDelivr的替代方案
遭到GFW封锁，基本宣告这个域名面向大众的服务失去价值，因为你无法让每个人学习像极客一样学会修改hosts、使用DoH分流。特别是前端引用这样面向用户的场景，应当更多考虑用户的便利性。以下提供几种可行的方案供大家参考，希望对大家有所帮助。
针对恢复访问主要分为服务和本地两种场景，服务场景修改则是替换jsDelivr资源到可访问的资源上，本地场景修改恢复访问的目的是针对海外引用jsDelivr的站点，这是两种不同的操作和目标。
官方子域
这次的污染只针对cdn.jsdelivr.net这一个域名，jsDelivr有很多的CDN赞助商共同支持，每一个服务商都会有自己的专有子域名，通过替换访问资源到其他的二级域名可以恢复访问。但这些CDN普遍速度一般，而且前途并不明朗，建议仅供临时使用。
CloudFlare：test1.jsdelivr.net
CloudFlare：testingcf.jsdelivr.net
Fastly：fastly.jsdelivr.net
GCORE：gcore.jsdelivr.net
反向代理
如果一定要使用jsDelivr的资源的话，可以考虑通过反代cdn.jsdelivr.net这一个资源库自用。建议通过海外优化线路落地+国内中转缓存，不过要注意添加防盗链以及尽量隐藏反代路径，以防止被其他人滥用。
nginx配置文件：
#针对/gh目录的反代
location /gh
{
proxy_pass https://104.16.86.20;
proxy_set_header Host cdn.jsdelivr.net;
proxy_ssl_server_name on;
proxy_ssl_name cdn.jsdelivr.net;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header REMOTE-HOST $remote_addr;
}
Cloudflare Workers 配置文件：
const hostname = "https://cdn.jsdelivr.net"
function handleRequest(request) {
let url = new URL(request.url);
return fetch(new Request(hostname + url.pathname,request))
}
addEventListener("fetch", event => {
event.respondWith(handleRequest(event.request))
})
由于Cloudflare Workers也被GFW封锁了，所以需要绑定一个域名：
如添加cdn.example.com指向8.8.8.8，类型可添加A或CNAME类型，并勾选Cloudflare代理。
(此处ip地址或CNAME可随意填写，因为只是为了让域名走Cloudflare。)
添加路由，配置Route:cdn.example.com/*指向创建的Workesr，到此等待DNS生效即可。
切换国内静态库
推荐一些国内比较稳定、全面的静态资源库吧，其中不乏完全同步cdnjs内容的，可以逐步将静态资源替换过去。
字节静态库：cdn.bytedance.com
- 完整同步了cdnjs的内容，通过自家CDN加速，缺点是没有海外节点而且链接比较凌乱。
360静态库：cdn.baomitu.com
- 完整同步了cdnjs的内容，并且有提供Google fonts加速，通过自家CDN加速，前段时间启用了AWS CloudFront的海外节点，是目前国内公共CDN做的比较好的了。
七牛静态库：staticfile.org
- 通过自家融合CDN加速，海外节点较少不过也表现尚可，缺点就是担心org域名后续备案维护的问题。
修改Hosts（失效）
一般情况下，DNS污染通常伴随着SNI阻断，不过比较幸运的是jsDelivr只是单纯的DNS污染，可以通过本地指定正常的IP恢复访问。这样操作可以解决作为用户本地无法加载页面包含jsDelivr资源的问题。Hosts文件在UNIX系统下位于/etc/hosts，Windows系统下位于C:\Windows\System32\drivers\etc\hosts，在末尾处添加适当的以下条目即可恢复访问。
#CloudFlare（不推荐联通使用）
104.16.85.20 cdn.jsdelivr.net
104.16.86.20 cdn.jsdelivr.net
104.16.87.20 cdn.jsdelivr.net
104.16.88.20 cdn.jsdelivr.net
104.16.89.20 cdn.jsdelivr.net
#Fastly（不推荐电信使用）
151.101.1.229 cdn.jsdelivr.net
151.101.129.229 cdn.jsdelivr.net
使用DoH/DoT（失效）
因为jsDelivr只是单纯的DNS污染可以通过DNS分流走海外加密DNS绕过污染。可以参考：https://blog.gd1214b.icu/post/Zr3HDqj6D/，但是修改DNS一定要做好分流，以免影响DoH/DoT对日常上网导致的CDN分配的问题。
其他可能的思路
目前有通过油猴替换reCAPTCHA使用的API中的google.com为recaptcha.net实现中国大陆加载，理论上也是可以通过这样的方法将jsDelivr替换到大陆可加载的链接上，期待各位大佬的实践。
结语
到底是谁杀死了jsDelivr呢？是jsDelivr审核不够严谨？是网宿的不辞而别？还是是政策的“一刀切”？博主不知道，相信各位看官自己心里都有自己的答案吧。
本来只是想简单讲几句，没想到就说了这么多，一篇文章难免会参杂有个人情感，文中如果有不够严谨的地方请多指点。
最后，晚安jsDelivr，感谢您和诸多的赞助商这么多年来为用户无偿提供这样便捷的服务~
