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

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

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

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

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

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

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

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

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

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

四川电信，现象完全一样

楼上给个测试ip

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

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

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

确实有干扰

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

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

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

这个原理是什么？

据说是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）协议可以通畅无阻。

据说是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协议对吗？

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

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

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

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

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

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

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

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

Vless+ws过cf也可以把？

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，就是明文流量。

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

据说是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的

据说是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的

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

据说是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客户端可以支持这个协议吗？应该如何配置

这两天稳定了

终于有人提这个了。我是联通移动双卡，今年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进行了随机的无差别断流。

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

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

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

这两天稳定了………

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

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

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

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

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

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

是的。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

上海电信又在作妖，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的问题

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这个就足够你喝一壶了

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

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

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

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

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

宽带断线重拨试试。

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

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

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

大概率运营商搞鬼

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

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

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

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

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

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

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

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

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

懂了，被扫了。。。

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

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

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

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

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

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

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

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

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

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

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