在jsDelivr被吊销ICP许可证四个月后的4月28日,cdn.jsdelivr.net
开始遭到污染,这一个赫赫有名的静态资源库面向中国大陆的服务最终倒在了政策和监管双重压力之下。
零、写在前面
虽然从四个月前那次宕机失去中国大陆CDN开始,很大一部分网站已经陆陆续续将静态资源切出jsDelivr,但是碍于jsDelivr多年的深耕以及服务的独特性,仍有不少场景下引用有jsDelivr的链接。不同于以往的短时间宕机,这次的“污染”几近于死刑,意味着cdn.jsdelivr.net
在中国大陆服务的彻底终结,从此这个网站将不再是慢,而是不可及。
*再次提醒:建议各位站长细致检查个人站点前端主题、插件、脚本等内容中对jsDelivr的引用,以避免由于jsDelivr不可及导致的加载卡顿和前端无法正常加载的情况。
Update 2022.04.29
污染已解除,文章内容仅供参考,应该是当局发现影响范围实在太大了吧~
Update 2022.05.17
再次被污染,并且增加了伴随的sni阻断,hosts不再有效。二进宫实惨,尽快着手转移吧。
壹、jsDelivr的命运
2022年4月28日,jsDelivr得到了与Facebook、Twitter等如出一辙的安排,主要的服务域名遭到DNS污染。在正常状态下,当你请求网站域名域名时,你的DNS服务器会逐级向上寻找这个域名的解析记录,并通过这个链条将它指向的服务器返回给你,实现域名与服务器的融合。若你的DNS逐级向上请求记录的过程中,出现了一个中间人提前抢答了错误的记录,而非来自域名权威服务器的正确回复,导致返回的结果并不是指向正确服务器的,连接因此不能建立,这便是DNS污染。其中的原因,还是要从一开始说起。
惊艳四座的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的替代方案
遭到DNS污染,基本宣告这个域名面向大众的服务失去价值,因为你无法让每个人学习像极客一样学会修改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的资源的话,可以考虑通过NGINX反代cdn.jsdelivr.net
这一个资源库自用。建议通过海外优化线路落地+国内中转缓存,不过要注意添加防盗链以及尽量隐藏反代路径,以防止被其他人滥用。具体配置这里给一个简单的范例,博主不是很推荐这样做,可靠性上很打折扣。NGINX反代jsDelivr示例
#针对/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;
}
服务·切换国内静态库
推荐一些国内比较稳定、全面的静态资源库吧,其中不乏完全同步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(失效)
DoH/DoT博主研究的很少,因为jsDelivr只是单纯的DNS污染可以通过DNS分流走海外加密DNS绕过污染。比如CloudFlare的1.1.1.1
都是可用的,但是修改DNS一定要做好分流,以免影响GeoDNS对日常上网导致的CDN分配的问题。
本地·其他可能的思路
目前有通过油猴替换reCAPTCHA使用的API中的google.com
为recaptcha.net
实现中国大陆加载,理论上也是可以通过这样的方法将jsDelivr替换到大陆可加载的链接上,期待各位大佬的实践。
叁、结语
于是,到底是谁杀死了jsDelivr呢?是jsDelivr审核不够严谨?是网宿的不辞而别?是政策的“一刀切”?博主不知道,相信各位看官自己心里都有自己的答案吧。
本来只是想简单讲几句,没想到就说了这么多,一篇文章难免会参杂有个人情感,文中如果有不够严谨的地方请多指点。
最后,晚安jsDelivr,感谢您和诸多的赞助商这么多年来为用户无偿提供这样便捷的服务~
本站所有引用jsdelivr的链接全部换成本地链接或者后台设置了一个自定义CDN加速链接