Cloudflare CDN 似乎被故意 干扰 / 阻断 了？标准的超时 3 分钟（刚测完速的 IP 就 443 端口超时了

[XIU2]

以前一直看到有人说 Cloudflare CDN 的 IP 被干扰阻断，但是我联通一直没遇到，不过最近我这边也出现了类似的情况。

而且我这次很确定是 运营商/墙 干的，干扰的很厉害。
同一个 IP，不访问时一切正常（ICMP、TCP 通顺），一旦 HTTPS 访问很快就 443 端口 TCP 超时了（但不是立马超时，会给你预留几秒，ICMP、TCP 80 通顺），而且还是标准的 3 分钟整，太规律了就显得太假了。

有类似情况的，可以电脑上装个 TCPing 工具，遇到无法使用时就 TCPing -t IP 443 持续测试，我这边是超时 90 次（超时时间 2 秒，即总共 180 秒） 就会恢复，而在超时期间，手机网络、在线网站全国检测该 IP 的 443 端口都通顺。

这让我想到了 Steam、Github 的 SNI 干扰（不过这个是根据域名来超时 IP 的，不在乎是什么 IP。而 Cloudflare 这个是针对其CDN IP 的，暂时称为 IP 干扰吧），也是一但访问可能就会超时 3 分钟整，都是只局限于单个宽带用户（即只有你超时，其他人哪怕是邻居也完全不受影响）。

不过并不是全天都这样的，时有时无的，应该是想伪装成网络质量问题，老套路了~

---

因此大家可能会遇到，测速完成后，延迟正常、下载速度也挺快，但是拿去使用却用不了（或者 IP 的 443 端口超时了），就是因为在下载测速阶段（HTTPS 访问）触发了上面说的 IP 阻断情况，导致该 IP 刚测速完就 G 了。。。

---

有时候刚用 CloudflareST 测完速（有下载速度就代表 IP 可用），得到的 IP 就 443 端口超时 3 分钟了，非常规律。

看来距离 Cloudflare "自愿" 退出中国不远了，我已经完全改用 IPv6 了，应该会多撑一段时间，且用且珍惜。

---

目前已知 Cloudflare CDN、AWS CloudFront CDN、Gcore CDN、Fastly CDN 都出现了同样的干扰阻断现象（仅 IPv4）。

---

有遇见类似情况的没有？可以讨论交流下。

[wy580477]

据说是GFW专门针对优选ip的手段，使用优选ip访问非cloudflare域名就会触发，猜测是常用的优选ip段可能有一个sni白名单。

如果是要中转梯子，解决方法其实也简单，不套tls不发sni，用80/8080等http端口连接cloudflare就行了。

[barney2022]

我也遇到同样的情况，四川联通。
用脚本优选出来的IP里，测速是速度的。但是一旦访问域名，立马就PING不通了。

[XIU2]

@wy580477
单独针对自选 IP 段没意义，因为都叫自选了，各不相同，墙直接把所有 Cloudflare IP 段加入 IP 干扰列表岂不是更简单方便~

---

自从几个月前时间 Cloudflare 节点与国内联通的某条线路出问题后，常见的 104 172 这两个 IP 段里（且它们也是默认分配 IP 的范围）大部分 IP 在我这边联通就几乎不可用了（延迟高、丢包高）。。。

不过我一直以来都用的是自选 IP（我只是用来加速访问使用 Cloudflare CDN 的网站），所以没啥感觉，直到最近（大概半个月内吧），才遇到我 1L 描述的情况。

因此我很怀疑，前者的情况也和墙脱不了干系。。。

---

总之，目前的情况就是，我这边 Cloudflare CDN 可用性大幅降低了（不管是默认还是自选）。

[chenyaofo]

我这也是，用CloudflareST测速的时候好好的，然后把优选ip写到/etc/hosts后，访问cloudflare的worker，直接就SSL连接都建立不了，同一时间挂代理又很可以，感觉cloudflare的CDN在我这网络环境下已经废了。

[XIU2]

@chenyaofo 就像我说的：一旦访问很快就超时了（但不是立马超时，会延迟几秒，所以刚开始能打开一两个网页的样子）。
虽然不是全天持续性的，但时不时来一下是真的烦人。。。

[popoer]

四川电信，现象完全一样

[peaceanddemocracy]

楼上给个测试ip

[crazypeace]

我这也是，用CloudflareST测速的时候好好的，然后把优选ip写到/etc/hosts后，访问cloudflare的worker，直接就SSL连接都建立不了，同一时间挂代理又很可以，感觉cloudflare的CDN在我这网络环境下已经废了。

workers.dev已经确认是被干扰了, 现在有人的改用pages，有的人用自己的域名，设置路由指向worker
#205

[peaceanddemocracy]

workers很早就确认干扰了，目前cf的ip干扰现象还没发现

[peaceanddemocracy]

确实有干扰

[peter2022]

跟楼主的阻断时间重合，将来不能嵌套cf了吗？

[peter2022]

据说是GFW专门针对优选ip的手段，使用优选ip访问非cloudflare域名就会触发，猜测是常用的优选ip段可能有一个sni白名单。

如果是要中转梯子，解决方法其实也简单，不套tls不发sni，用80/8080等http端口连接cloudflare就行了。

这个原理是什么？

[wy580477]

据说是GFW专门针对优选ip的手段，使用优选ip访问非cloudflare域名就会触发，猜测是常用的优选ip段可能有一个sni白名单。
如果是要中转梯子，解决方法其实也简单，不套tls不发sni，用80/8080等http端口连接cloudflare就行了。

这个原理是什么？

sni阻断原理是根据tls握手时候的明文sni(域名)进行tcp阻断。绕过去方法有两个：

1. 不用tls协议，走cf的http端口，没有tls，就没有sni，sni阻断就无从谈起。
2. 使用quic协议，目前的信息来看，墙的sni阻断只对tcp流量生效，走udp的quic（h3）协议可以通畅无阻。

[peter2022]

据说是GFW专门针对优选ip的手段，使用优选ip访问非cloudflare域名就会触发，猜测是常用的优选ip段可能有一个sni白名单。
如果是要中转梯子，解决方法其实也简单，不套tls不发sni，用80/8080等http端口连接cloudflare就行了。

这个原理是什么？

sni阻断原理是根据tls握手时候的明文sni(域名)进行tcp阻断。绕过去方法有两个：

1. 不用tls协议，走cf的http端口，没有tls，就没有sni，sni阻断就无从谈起。
2. 使用quic协议，目前的信息来看，墙的sni阻断只对tcp流量生效，走udp的quic（h3）协议可以通畅无阻。

可以理解为把vless or vmess中的tls改为quic协议对吗？

[wy580477]

2. 使用quic协议，目前的信息来看，墙的sni阻断只对tcp流量生效，走udp的quic（h3）协议可以通畅无阻。

可以理解为把vless or vmess改为quic协议对吗？

梯子中转不能用quic过cf，cf不支持quic回源。cf中转梯子可以用vmess ws无tls协议。

梯子直连情况下遇到sni阻断，可以改成quic协议绕过去。

[peter2022]

2. 使用quic协议，目前的信息来看，墙的sni阻断只对tcp流量生效，走udp的quic（h3）协议可以通畅无阻。

可以理解为把vless or vmess改为quic协议对吗？

梯子中转不能用quic过cf，cf不支持quic回源。cf中转梯子可以用vmess ws无tls协议。

梯子直连情况下遇到sni阻断，可以改成quic协议绕过去。

Vless+ws过cf也可以把？

[wy580477]

2. 使用quic协议，目前的信息来看，墙的sni阻断只对tcp流量生效，走udp的quic（h3）协议可以通畅无阻。

可以理解为把vless or vmess改为quic协议对吗？

梯子中转不能用quic过cf，cf不支持quic回源。cf中转梯子可以用vmess ws无tls协议。
梯子直连情况下遇到sni阻断，可以改成quic协议绕过去。

Vless+ws过cf也可以把？

vless没有tls，就是明文流量。

[peter2022]

一个小时后又可以了…………

[peaceanddemocracy]

据说是GFW专门针对优选ip的手段，使用优选ip访问非cloudflare域名就会触发，猜测是常用的优选ip段可能有一个sni白名单。
如果是要中转梯子，解决方法其实也简单，不套tls不发sni，用80/8080等http端口连接cloudflare就行了。

这个原理是什么？

sni阻断原理是根据tls握手时候的明文sni(域名)进行tcp阻断。绕过去方法有两个：

1. 不用tls协议，走cf的http端口，没有tls，就没有sni，sni阻断就无从谈起。
2. 使用quic协议，目前的信息来看，墙的sni阻断只对tcp流量生效，走udp的quic（h3）协议可以通畅无阻。

没用的，只要连接时使用域名，http是可以探测到url的

[peter2022]

据说是GFW专门针对优选ip的手段，使用优选ip访问非cloudflare域名就会触发，猜测是常用的优选ip段可能有一个sni白名单。
如果是要中转梯子，解决方法其实也简单，不套tls不发sni，用80/8080等http端口连接cloudflare就行了。

这个原理是什么？

sni阻断原理是根据tls握手时候的明文sni(域名)进行tcp阻断。绕过去方法有两个：

1. 不用tls协议，走cf的http端口，没有tls，就没有sni，sni阻断就无从谈起。
2. 使用quic协议，目前的信息来看，墙的sni阻断只对tcp流量生效，走udp的quic（h3）协议可以通畅无阻。

没用的，只要连接时使用域名，http是可以探测到url的

哪有什么办法？昨晚到今天又稳定了

[popoer]

据说是GFW专门针对优选ip的手段，使用优选ip访问非cloudflare域名就会触发，猜测是常用的优选ip段可能有一个sni白名单。
如果是要中转梯子，解决方法其实也简单，不套tls不发sni，用80/8080等http端口连接cloudflare就行了。

这个原理是什么？

sni阻断原理是根据tls握手时候的明文sni(域名)进行tcp阻断。绕过去方法有两个：

1. 不用tls协议，走cf的http端口，没有tls，就没有sni，sni阻断就无从谈起。
2. 使用quic协议，目前的信息来看，墙的sni阻断只对tcp流量生效，走udp的quic（h3）协议可以通畅无阻。

没用的，只要连接时使用域名，http是可以探测到url的

哪有什么办法？昨晚到今天又稳定了

搜索了一下，针对SNI泄露域名的问题，后来有ESNI(Encrypted SNI)来解决，但有ESNI协议的包直接被GFW屏蔽了，最新的解决方案应该是ECH(Encrypted Client Hello, TLS 1.3协议的一个扩展)。
但还不太清楚现在的V2ray客户端可以支持这个协议吗？应该如何配置

[peter2022]

这两天稳定了

[abcd1356]

终于有人提这个了。我是联通移动双卡，今年4.15前后开始联通网突然出现CF CDN被严重丢包断流的情况。不是墙，就是运营商搞的。目前已知全国大部分联通网和少部分电信网有这个问题。移动网完全正常。
症状很简单，访问一切套了CF的网站，都会严重丢包（注意是丢包，而不是tcp阻断。自测ping丢包率80%左右），基本打不开（但CF官网一直可以正常打开，未受到任何阻断）。应该是对CF全部CDN IP的无差别断流。但不是全天断流，而是一天中有些时间断流，有些时间通畅，也可能运气好一整天都是通畅的。完全没有规律，我这里也没观察到上面提到的3分钟审查残留现象，完全是随机的，可能连续通畅几分钟到几小时，再持续断流几分钟到几小时。在抽风期里，自始至终不直接访问该网站，第一步直接起手ping，都是不通的。而且似乎和域名，sni这些没有关系（尝试过改host+伪造/不发送sni，结果无效），纯粹根据IP触发，断流时ping都不通。
目前的影响是联通网访问一切套了CF的网站，影视资源网站，个人博客，论坛，PT站，全都不定期的无法打开。目前影响最大的是PT圈，国内多数PT站都是套了CF的，这波下来联通PT用户严重受灾。而且优选IP（至少在我这里）没用，因为是CF全部IP无差别丢包，所以优选根本选不出来。
而且因为是根据IP丢包的，所以也没啥好办法，要么梯子要么换运营商（我这里联通断流CF时切成移动网，瞬间就通畅了）。
至于是技术故障还是故意的我暂时蒙古，5月初有人提到是技术故障，联通换了大量IP段路由规则结果国际出入口出故障崩了。但也至今没见修复。也有些不太好的猜想就是未来CF会逐渐得到谷歌系同级待遇（全IP黑洞）。。。我也不太好判断，因为从一方面来说：目前这是运营商而不是墙搞的；而且CF官网本身未受污染；“封锁”似乎完全随机没有规律；无差别断流CDN误伤大量正常网站，这些似乎表明是技术故障。但从另一个角度来说：断流迟迟未修复；断流IP和worker被墙，自选IP被SNI干扰等行为在时间上具有一定的同步性。所以也不能排除这种可能性，也就是上面在统一对CF进行打击（墙worker和干扰自选IP），而联通则在此基础上进一步加码，对CF全部IP进行了随机的无差别断流。

[barney2022]

这段时间vless+ws+tls用cf优选节点中转一直被阻断，于是我按大佬提到的方式改为vmess+ws直接连cf的80端口中转，然后发现所有的cf优选节点都能用了，尽管cf的优选节点ping不通，但是还是能连上，速度也很快，就不知道vmess+ws不套tls有什么风险？

[crazypeace]

这段时间vless+ws+tls用cf优选节点中转一直被阻断，于是我按大佬提到的方式改为vmess+ws直接连cf的80端口中转，然后发现所有的cf优选节点都能用了，尽管cf的优选节点ping不通，但是还是能连上，速度也很快，就不知道vmess+ws不套tls有什么风险？

不套tls意味着GFW可以知道你用了某种加密协议，理论上vmess加密后应该看起来是随机的数据，GFW不知道你想通过梯子访问的最终目的地。如果GFW想通过某种猜测来封禁的话，是可以采取“我不认识的就是翻墙，除非你主动向我报备”的策略的。

[peter2022]

这两天稳定了………

[barney2022]

这段时间vless+ws+tls用cf优选节点中转一直被阻断，于是我按大佬提到的方式改为vmess+ws直接连cf的80端口中转，然后发现所有的cf优选节点都能用了，尽管cf的优选节点ping不通，但是还是能连上，速度也很快，就不知道vmess+ws不套tls有什么风险？

不套tls意味着GFW可以知道你用了某种加密协议，理论上vmess加密后应该看起来是随机的数据，GFW不知道你想通过梯子访问的最终目的地。如果GFW想通过某种猜测来封禁的话，是可以采取“我不认识的就是翻墙，除非你主动向我报备”的策略的。

是不是意味着我用VMESS+WS套上CF，服务器IP被隐藏了不会被墙，但是域名有可能被墙对吗？

[crazypeace]

这段时间vless+ws+tls用cf优选节点中转一直被阻断，于是我按大佬提到的方式改为vmess+ws直接连cf的80端口中转，然后发现所有的cf优选节点都能用了，尽管cf的优选节点ping不通，但是还是能连上，速度也很快，就不知道vmess+ws不套tls有什么风险？

不套tls意味着GFW可以知道你用了某种加密协议，理论上vmess加密后应该看起来是随机的数据，GFW不知道你想通过梯子访问的最终目的地。如果GFW想通过某种猜测来封禁的话，是可以采取“我不认识的就是翻墙，除非你主动向我报备”的策略的。

是不是意味着我用VMESS+WS套上CF，服务器IP被隐藏了不会被墙，但是域名有可能被墙对吗？

是的。

[MFWT]

理论上这些ip都是直接中转数据的，一般是4层代理（端口转发）或者7层代理（SNI代理，但没有做SNI判断），所以数据安全性理论上没有问题，毕竟都是跑的TLS（梯子的SNI泄露没办法了，毕竟是明文的，除非你eSNI），你实际传输的内容不会泄露
但是还是那句话，以防万一
而且这个确实如楼主所说不保证稳定性，毕竟不是官方提供的ip，都是某些大冤种不小心开放出来的，人人都去白嫖的话，对面很快就会发觉并采取限制，这个ip就失效了

厉害了…居然还有人自愿做cf的节点？这是不是pcdn了哈哈哈哈哈哈

实际情况是，很多这样的节点都是『不小心』泄露出来的，比如我写的『SNI代理但没有校验主机名』

[hecarli555]

理论上这些ip都是直接中转数据的，一般是4层代理（端口转发）或者7层代理（SNI代理，但没有做SNI判断），所以数据安全性理论上没有问题，毕竟都是跑的TLS（梯子的SNI泄露没办法了，毕竟是明文的，除非你eSNI），你实际传输的内容不会泄露
但是还是那句话，以防万一
而且这个确实如楼主所说不保证稳定性，毕竟不是官方提供的ip，都是某些大冤种不小心开放出来的，人人都去白嫖的话，对面很快就会发觉并采取限制，这个ip就失效了

厉害了…居然还有人自愿做cf的节点？这是不是pcdn了哈哈哈哈哈哈

实际情况是，很多这样的节点都是『不小心』泄露出来的，比如我写的『SNI代理但没有校验主机名』

好吧。。。果然不加密放上网默认就是共享。。。

[MFWT]

实际情况是，很多这样的节点都是『不小心』泄露出来的，比如我写的『SNI代理但没有校验主机名』

好吧。。。果然不加密放上网默认就是共享。。。

你可以做个实验，用国外VPS开个socks代理，不鉴权，就默认1080端口

这么做了之后，很大概率的是，三天内你的服务器IP会出现在各大免费代理网站

[faker1987]

又开始阻断了5月6日开始。又是碰某个cfcdn的网页或者app 就直接断3分钟

[kotonamishion]

开启cdn就访问不了，关了才能用自己搭建的节点

[basten1899]

公司专线就没事, 家里电信宽带 测完ip就不能用了 糟心啊

[starllll]

目前好像只要访问cf的cdn服务就会阻断

[RTM945]

上海电信又在作妖，ss+v2ray plugin在上海电信下用不了，google one vpn 也连不上了

[MFWT]

上海电信又在作妖，ss+v2ray plugin在上海电信下用不了，google one vpn 也连不上了

google one vpn看了一下，似乎是2153/UDP和443/UDP，可能是自家协议（至于你说是不是用的QUIC，这难讲），但是据我了解呢，443/UDP运营商很多都block，而且只要是UDP也有干扰

SS+V2Plugin不知道你外层（V2插件）用的是什么插件（毕竟从第三人看来，他只能看到你的外层协议，WS就看到WS，WS+TLS就只看到TLS，除非主动探测），如果是用WS+TLS过CF CDN的话，阻断的可能性比较高，但这和协议无关，主要还是目标IP是CF的IP的问题

[RTM945]

ss只有域名没上cdn，应该是ws，没有tls，只用来打游戏或连google one vpn，我的操作是，pixel点开vpn ，连的过程中点开ss，最终是vpn 连接成功，ss关掉。 昨晚ss 能ping 通但无法访问外网，于是我就换了个没上cdn 的vless ws tls 成功了，刚才试了下ss 可以访问外网了，但vpn 连不上，换了之前能用的vless 也连不上了，所以怀疑是运营商针对google one vpn 做了什么。 在另一个地方的联通网络下都正常。

…

On Sat, May 13, 2023, 10:46 AM MFWT ***@***.***> wrote: 上海电信又在作妖，ss+v2ray plugin在上海电信下用不了，google one vpn 也连不上了 google one vpn看了一下，似乎是2153/UDP和443/UDP，可能是自家协议（至于你说是不是用的QUIC，这难讲），但是据我了解呢，443/UDP运营商很多都block，而且只要是UDP也有干扰 SS+V2Plugin不知道你外层（V2插件）用的是什么插件（毕竟从第三人看来，他只能看到你的外层协议，WS就看到WS，WS+TLS就只看到TLS，除非主动探测），如果是用WS+TLS过CF CDN的话，阻断的可能性比较高，但这和协议无关，主要还是目标IP是CF的IP的问题 — Reply to this email directly, view it on GitHub <#217 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AB5B7HBUIRZXMS4SOWIG5X3XF3YXXANCNFSM5WXU624Q> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[MFWT]

ss只有域名没上cdn，应该是ws，没有tls，只用来打游戏或连google one vpn，我的操作是，pixel点开vpn
，连的过程中点开ss，最终是vpn 连接成功，ss关掉。
昨晚ss 能ping 通但无法访问外网，于是我就换了个没上cdn 的vless ws tls 成功了，刚才试了下ss 可以访问外网了，但vpn
连不上，换了之前能用的vless 也连不上了，所以怀疑是运营商针对google one vpn 做了什么。
在另一个地方的联通网络下都正常。

google one vpn毕竟还是VPN，单单是UDP这个就足够你喝一壶了

[RTM945]

对没错，现在我无法访问一些屏蔽云服务机房的服务了，比如chatGPT ，好烦，或许我该试试cf warp了

…

On Sat, May 13, 2023, 11:03 AM MFWT ***@***.***> wrote: google one vpn毕竟还是VPN，单单是UDP这个就足够你喝一壶了 — Reply to this email directly, view it on GitHub <#217 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AB5B7HEQ26DREXH7JFPR2UDXF32ZVANCNFSM5WXU624Q> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[MFWT]

对没错，现在我无法访问一些屏蔽云服务机房的服务了，比如chatGPT ，好烦，或许我该试试cf warp了

CF WARP 也有概率不行，不过显然比Google VPN（出口就是Google机房）要好那么一点

[panbofeng]

AWS非tls仅http也断流…请问你们都只有cf断流吗

[AmBeta]

从昨天开始 cf cdn tls 被随机阻断，无法完成握手

[befantasy]

从昨天开始 cf cdn tls 被随机阻断，无法完成握手

宽带断线重拨试试。

[Cyyking]

晚上移动这种情况特别频繁，现在有什么好办法解决么？

[aTenb]

正常访问 plex.tv 然后就所有访问CF的网站都被阻断了 这啥情况啊

[MFWT]

正常访问 plex.tv 然后就所有访问CF的网站都被阻断了 这啥情况啊

大概率运营商搞鬼

[MFWT]

晚上移动这种情况特别频繁，现在有什么好办法解决么？

世界加钱可及
要么就转投v6的怀抱，v6直连都可以

[faker1987]

电信表示有些时候v6也会阻断

[handsomevvv]

云南联通表示也遇到了, 域名加www 一会儿访问不到 换成 不加的又行了, 来来回回 反反复复 我还以为我的问题呢

[hecarli555]

成都电信5月13日开始，感受到gfw发疯的威力了，做的vless+ws+tls的节点全部用不了，换ip挂上直接又用不了，各方打听后是gfw发威精准识别tls。。。。这是6月提前禁言了？

[hecarli555]

实际情况是，很多这样的节点都是『不小心』泄露出来的，比如我写的『SNI代理但没有校验主机名』

好吧。。。果然不加密放上网默认就是共享。。。

你可以做个实验，用国外VPS开个socks代理，不鉴权，就默认1080端口

这么做了之后，很大概率的是，三天内你的服务器IP会出现在各大免费代理网站

懂了，被扫了。。。

[XIU2]

你们的遇到的不是错觉，3 天前 Cloudflare CDN 就发现了来自中国的流量有所下降（显然是异常/罕见的明显下降，否则也不会引起 Cloudflare 官方关注），最后调查结果是：该问题和 Cloudflare 网络无关，并且可能会继续下去。
https://www.cloudflarestatus.com/incidents/7gd0nkh3tqd7

[MFWT]

我说说我的看法，我还是相信TLS连接到CF IP段的，都会遭到一定程度的干扰。实话实说，GFW怎么可能不知道CF IP段是多少，把本项目的ip.txt拉下来导入到那边的软件就可以重点监控了

对于确实是用CF的大公司的网站，SNI白名单也没有我们想象中的那么难（你想想，PAC文件不是一个道理？只是一个白名单一个黑名单罢了），这部分网站跳过就行了

对于一些非常小众的域名后缀（特别是便宜那些），我感觉GFW还会额外关照，毕竟还会有什么正经大公司用那么奇怪的域名呢：egfitoltihgg114514.top？是生怕客户找到了你的网站吗？

平时，这种可能性可能小一点，但是现在是五月十五号，距离下个月四号也就两周多一点，很难让人不怀疑GFW那边正在进行『相对激进的流量屏蔽方法』的相关试验，在他们看来，现在就是『宁可错杀一千，不可放过一个』的时候了

我还是建议，多备几个协议，多备几条线路，我们的辛苦时期要来了

[ghost]

企业网段可解，看 @pressdot 的 https://github.com/pressdot/Cloudflare_IP

如果知道怎么绕过域名限制error code: 1034，甚至可以用 1.1.1.0/24 和 1.0.0.0/24。

[XIU2]

@rabbit2123 治标不治本，这种 IP 段用的人多了，按照以往的经验，要么被 Cloudflare 发现并限制域名，要么就会被加到墙的干扰阻断黑名单里了（当初就是这样一点一点加 IP 段的）。。。无非就是延长一会儿死亡时间罢了~

只要代理套 CDN 的情况还存在，这种问题就不会停止，慢慢的所有国外 CDN 都会 G 了（目前已知 Cloudflare CDN、AWS CloudFront CDN、Gcore CDN、Fastly CDN 都出现了干扰阻断现象，即常见的 CDN 已经废了一半了）。

建议大家使用 新协议、冷门协议、冷门 IDC 去做代理，代理套 CDN 这条路已经能看到尽头了。。。
这整天干扰阻断的，搞得我这个只是想要单纯在本地加速访问所有套了 Cloudflare CDN 网站的简单需求都被影响了。。。