Cloudflare CDN 似乎被故意 `干扰 / 阻断` 了？标准的超时 3 分钟（刚测完速的 IP 就 443 端口超时了
XIU2 opened this issue · 242 comments
以前一直看到有人说 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）。
有遇见类似情况的没有？可以讨论交流下。
据说是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阻断。绕过去方法有两个：
- 不用tls协议，走cf的http端口，没有tls，就没有sni，sni阻断就无从谈起。
- 使用quic协议，目前的信息来看，墙的sni阻断只对tcp流量生效，走udp的quic（h3）协议可以通畅无阻。
据说是GFW专门针对优选ip的手段，使用优选ip访问非cloudflare域名就会触发，猜测是常用的优选ip段可能有一个sni白名单。
如果是要中转梯子，解决方法其实也简单，不套tls不发sni，用80/8080等http端口连接cloudflare就行了。这个原理是什么？
sni阻断原理是根据tls握手时候的明文sni(域名)进行tcp阻断。绕过去方法有两个：
- 不用tls协议，走cf的http端口，没有tls，就没有sni，sni阻断就无从谈起。
- 使用quic协议，目前的信息来看，墙的sni阻断只对tcp流量生效，走udp的quic（h3）协议可以通畅无阻。
可以理解为把vless or vmess中的tls改为quic协议对吗？
- 使用quic协议，目前的信息来看，墙的sni阻断只对tcp流量生效，走udp的quic（h3）协议可以通畅无阻。
可以理解为把vless or vmess改为quic协议对吗？
梯子中转不能用quic过cf，cf不支持quic回源。cf中转梯子可以用vmess ws无tls协议。
梯子直连情况下遇到sni阻断，可以改成quic协议绕过去。
- 使用quic协议，目前的信息来看，墙的sni阻断只对tcp流量生效，走udp的quic（h3）协议可以通畅无阻。
可以理解为把vless or vmess改为quic协议对吗？
梯子中转不能用quic过cf，cf不支持quic回源。cf中转梯子可以用vmess ws无tls协议。
梯子直连情况下遇到sni阻断，可以改成quic协议绕过去。
Vless+ws过cf也可以把？
- 使用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阻断。绕过去方法有两个：
- 不用tls协议，走cf的http端口，没有tls，就没有sni，sni阻断就无从谈起。
- 使用quic协议，目前的信息来看，墙的sni阻断只对tcp流量生效，走udp的quic（h3）协议可以通畅无阻。
没用的，只要连接时使用域名，http是可以探测到url的
据说是GFW专门针对优选ip的手段，使用优选ip访问非cloudflare域名就会触发，猜测是常用的优选ip段可能有一个sni白名单。
如果是要中转梯子，解决方法其实也简单，不套tls不发sni，用80/8080等http端口连接cloudflare就行了。这个原理是什么？
sni阻断原理是根据tls握手时候的明文sni(域名)进行tcp阻断。绕过去方法有两个：
- 不用tls协议，走cf的http端口，没有tls，就没有sni，sni阻断就无从谈起。
- 使用quic协议，目前的信息来看，墙的sni阻断只对tcp流量生效，走udp的quic（h3）协议可以通畅无阻。
没用的，只要连接时使用域名，http是可以探测到url的
哪有什么办法？昨晚到今天又稳定了
据说是GFW专门针对优选ip的手段，使用优选ip访问非cloudflare域名就会触发，猜测是常用的优选ip段可能有一个sni白名单。
如果是要中转梯子，解决方法其实也简单，不套tls不发sni，用80/8080等http端口连接cloudflare就行了。这个原理是什么？
sni阻断原理是根据tls握手时候的明文sni(域名)进行tcp阻断。绕过去方法有两个：
- 不用tls协议，走cf的http端口，没有tls，就没有sni，sni阻断就无从谈起。
- 使用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被隐藏了不会被墙，但是域名有可能被墙对吗？
是的。
黑龙江联通，从4月29日开始，出现的这种情况的…最初104段明显，172段相对宽松一些，然后5月下旬的时候172段也是这种情况。
请教ipv6如何使用，就是优选出来的ipv6地址直接替换原来的ipv4就可以了吗？ 其他不用改什么配置？谢谢 ~
感觉有的域名是阻断ip，但也有可能是劣化tcp链接。感觉应当尽量避免测速url的域名中出现steam、github和google等字眼，避免sni干扰造成测速不准确。
如果不优选，直接vmess+ws+tls+cf嵌套，也是会出现被随机阻断因为cf的ip 是随机或固定的？
奇怪的，我用v4的地址，移动网络下是可以用的 用v6就是不行，本机的v6是通的
说下我很久之前就观察到的：PPPoE认证通过之后首次访问任意cf站速度非常快，但是过段时间之后就近乎阻断，如果日常浏览连续使用cf的IP那么就会导致所有使用cf的服务处于完全不可用的状态。
此时手动挂断PPPoE重新认证更换一个新的动态IP之后又会变得一切OK，所有的网站（包括非raw域的GitHub）都可以正常访问，进入新一轮循环。
这些现象符合 @XIU2 的推断，GFW是在有意降低某些IP的通讯质量，可以算得上最新手段了。我自上网冲浪伊始碰上的从最初的DNS污染，到抢答RST重置包，再到针对IP的路由黑洞，再细致到针对不同端口、协议走不同路由，直到近年全面封杀DoT的853端口和ESNI数据包出墙、用哪个IP哪个IP就断一会通一会，让人误以为服务劣化主动放弃使用，不得不说GFW的手段越来越诛心了。
反正我是放弃幻想，cf公开的IP段一律加到代理规则里了。早日肉翻才是正道。
因为从一方面来说：目前这是运营商而不是墙搞的；
@abcd1356 你搞错了一点，GFW从来就不是什么具象的、单一类型的、设备/手段，而是笼统的一个复杂体系，其中ISP就是重要的一环。比如DNS污染就是从ISP提供的默认DNS开始的，绕过了这一级后面还有DNS抢答，即使费尽千辛万苦拿到了正确的IP，后面还有针对IP的黑路由...这个体系是复杂而又庞大的，分布在不同地市的ISP正是其重要的一环。据我自己的观察，大部分需要被阻断/劣化的流量甚至都不需要出省就已经被处理掉了。
有解决方案吗？vmess可以吗？
因为从一方面来说：目前这是运营商而不是墙搞的；
@abcd1356 你搞错了一点，GFW从来就不是什么具象的、单一类型的、设备/手段，而是笼统的一个复杂体系，其中ISP就是重要的一环。比如DNS污染就是从ISP提供的默认DNS开始的，绕过了这一级后面还有DNS抢答，即使费尽千辛万苦拿到了正确的IP，后面还有针对IP的黑路由...这个体系是复杂而又庞大的，分布在不同地市的ISP正是其重要的一环。据我自己的观察，大部分需要被阻断/劣化的流量甚至都不需要出省就已经被处理掉了。
目前有些功能确实很大程度上下放到地方运营商了，像东部沿海地区的http劫持反炸，墙中墙，泉州白名单，等等。不过这些（小范围的措施）能不能称之为墙的一部分，可能算是个人定义问题吧。。
最近又观测了几天，发现我这里遇到的联通网CF丢包的问题，好像确实和这个issue说的不是同一件事，很多细节特征都不同。
而从时间线上来看，似乎是分三波，首先是4.15左右联通网出现大面积Cf丢包现象（我观察到的问题）。然后到5月初worker被墙，然后5月中旬出现自选IP段的干扰（楼主描述的问题）。后两者在特征上更符合墙的统一动作（三分钟审查残留，真连接后TCP阻断等），目的应该是针对性的打击那些用CF搭梯子的人。而联通这个的目的就很奇怪了，无差别AOE全部用Cf建站的，直接对全部IP段进行无差别丢包，往坏里想难道是想让Cf全面得到谷歌待遇（拒之墙外+大面积IP黑洞）？不过也有说法是联通修改Cf全部IP段的路由规则导致的技术问题。
编辑，最近几天联通断流Cf的问题好像出现了规律（是刚出现，而不是我刚发现，之前确实是完全无规律的），就是断流时间完全集中在下午和晚上。每天凌晨到上午联通Cf都是十分通畅，随时打开都能通，而从中午开始到晚上就开始高强度丢包，期间丢包率维持在80左右，基本别想直连打开套Cf的网站。
如果不优选，直接vmess+ws+tls+cf嵌套，也是会出现被随机阻断因为cf的ip 是随机或固定的？
不优选基本都是正常的，ping到的是ipv6，优选ipv6时断时好的...
据说是GFW专门针对优选ip的手段，使用优选ip访问非cloudflare域名就会触发，猜测是常用的优选ip段可能有一个sni白名单。
如果是要中转梯子，解决方法其实也简单，不套tls不发sni，用80/8080等http端口连接cloudflare就行了。
请问你说的这个方法，就是vmess+ws 走80或者8080端口，不套tls，但是cloudflare还是正常指向vps ip，小云朵橘色已代理。其他都不变是吗？这个方法还可以优选吗
你们被SNI阻断 是不是小姨子?
我这里是山东移动，优选ip的时候（比如改成cf的ip）有时候会出现cloudflare的提示，跟网站本身没有关系，不自选好好的，改成cf官方域名解析的时候就有问题，估计这件事和cf本身也有关系
而且目前来看移动连接cf的ipv4基本上都有很不错的速度（不是所有网段都走香港），而ipv6就有严重的晚高峰现象（移动ipv6美国直连），白天用不着优选也非常快，晚上访问速度就大大下降，和ipv4直连的反差极大
“改成cf官方域名解析的时候就有问题”
一些 Cloudflare CDN IP 是有限制的（针对免费/低级套餐），比如 Cloudflare 官方域名的那些解析 IP 都只能官方自己用。
你手动指向，通过这些被限制的 CDN IP 去访问免费套餐的域名，就会提示 Error 1034 错误。
一些 Cloudflare CDN IP 是有限制的（针对免费/低级套餐），比如 Cloudflare 官方域名的那些解析 IP 都只能官方自己用。
你手动指向，通过这些被限制的 CDN IP 去访问免费套餐的域名，就会提示 Error 1034 错误。
原来是这样。
有没有可能就是墙或者运营商在发现你访问域名时连接的ip和dns解析不一样的时候就会触发干扰？
@wjr050430 不排除，但可能性很低，因为它们可能没那么闲。。。（我也完全没遇到过类似情况
而且这样做需要消耗不少算力，任何行为放到到全国，上了规模都不是一件小事。
另外，想起来很简单，真正做起来要考虑的就很多了，比如：
如果域名是分地区解析呢？这样的话不同地区解析的 IP 不一样。
或者刚更新完域名解析记录，此时因为缓存的原因，48 小时内很多地区的用户依然通过旧 IP 去访问，此时也不一样。
各种问题数不胜数，因此要完全实现（减少误伤）要考虑的东西很多，局限性很大，也不是几行代码就能完成的。
各种问题数不胜数，因此要完全实现（减少误伤）要考虑的东西很多，局限性很大，也不是几行代码就能完成的。
我认为对cf能够随便搞梯子代理能够产生干扰对墙来说就足够了。
目前我这里筛选出的ip只要能用就可以用好长时间。
而且也不完全排除是路由故障。前段时间移动ipv4没有香港直连了，效果大大衰减，只剩下移动直连美国的节点效果可以好一点。但是最近又换回来了。况且根据这个回答里面的一些叙述，跟晚高峰qos估计也有关系
这个问题我尝试着求证过，用脚本测试了一下，但没引起大家的关注以为我是个例，就关掉了issue。#208
-
考虑到年初，一个重要的CNAME接入方式被Cloudflare干掉了。当时的我个人的猜测正如 issue 标题中写的
Cloudflare 对某些接入点施加了并发限制
——我觉得是cloudflare干的 -
后来群友结合“泉州风闻”、“worker污染”等，提出似乎GFW一直相对 cloudflare 的“高风险业务”进行解构、特征阻拦，总结了以下猜测
是 GFW 会比对 SNI 的 DNS 记录与访问的 IP 值，不对应会触发阻断。
——嘶，还挺有道理
正如 #217 (comment) 中提到的算力消耗问题，可能cloudflare更具备这一实施的可能性。但是从目的上来说这又更像GFW想要达到的效果。至于真相如何……
没想到这么快就两个月了。据闻该限制开始放松，特地回来拜访一下。
更新，重新跑了一下我当时写的脚本，初步判断这个限制有所放松。但自选的 IP 短时间内摸多了，还是会有TCP阻断。再摸，再摸ICMP都给你丢了。。
我也是有这个问题 不过我最近不止3分钟。有时候直接tcpout卡一天 只能换ip而且经常ip。这招也会失效。所有cf服务都无法访问
四川联通，我这里凡是套用CF CDN的站，全部都很难打开，ping IP 丢包超级严重，估计有90%以上，但是又不是完全ping不通，偶尔有极个别时间很畅通，基本不丢包。 搭上梯子就怎么都秒开。我估计是故意这样做的，但不知道目的是为何，真不想让用，直接掐断不就得了，还做这种下三滥的勾当。
@pyyii
直接掐断影响太大（无论是国内还是国外），因此不会这样干，现在它们都学聪明了，都喜欢搞成随机干扰，模拟为网络问题，毕竟大部分网民对网络方面都只是一知半解，根本不清楚这些条条道道，遇到类似情况就会认为是网站自身网络辣鸡，而这些网站又不可能撕破脸皮下场回应缘由。。。
比如去年 12 月，Steam 被 SNI 干扰，即使我与众人都发了技术实锤，也很容易验证，但是也只能让懂行的人明白，不懂行的依然坚持认为是 Steam 网络辣鸡，Steam 客服也只能解释是国内运营商方面的问题，不敢说的太清楚，毕竟还要在国内混呢。。。
再加上一些人故意放风引导，然后就是懂技术的和不懂技术的各吵个的，谁都不服谁，吵了一段时间就懒得吵了，再加上国内各论坛社区都逐渐禁止讨论该事件，慢慢的大家就认命了，成功分化了群众，将该次事件引起的影响降到了最低。
而到今天为止，我偶尔看到关于 Steam 网络方面的话题时，很多人还依然认为是 Steam 自身网络问题。。。
从 Github 到 Steam，很显然它们已经尝到甜头了，以后这种 SNI/IP 随机干扰方案应该会逐渐普及下去，来针对那些不适合一刀切封死的互联网服务，Cloudflare CDN 可能就是首次针对海外 CDN 的一次尝试。
毕竟相比其他 CDN，Cloudflare 免费且用的人多，很多国内不允许的网站都使用了 Cloudflare CDN，且前几年开发出来的代理套 CDN 玩法也是导致其被针对的主要原因（基本用的都是 Cloudflare CDN，毕竟付费 CDN 太昂贵）。
随机干扰现在已经按照段来执行了，同一个段一个时间打不开，这时其它的段可以打开，过一段时间，这个段又可以打开了，然后其它的某个段肯定相应地打不开
四川联通，我这里凡是套用CF CDN的站，全部都很难打开，ping IP 丢包超级严重，估计有90%以上，但是又不是完全ping不通，偶尔有极个别时间很畅通，基本不丢包。 搭上梯子就怎么都秒开。我估计是故意这样做的，但不知道目的是为何，真不想让用，直接掐断不就得了，还做这种下三滥的勾当。
我上面描述的就是一模一样的问题，联通cf丢包。再说下后续，情况有些复杂。
我6月前在武汉，用武汉联通，遇到上述cf严重丢包问题，时好时坏，每天大约70%的时段会触发丢包，和你体验的应该基本一样。
6月底到北京，改用北京联通，仍然丢包但情况有所缓解，大概每天50%的时段会丢包，ping丢包率从80降到六七十。猜测是干扰仍然存在，但因为我离国际出口物理距离更近了（五月联通改路由规则后cf的IP段一律走北京国际出入口），所以有所缓解。
7越月初，大概5号左右，出现了巨大变化，丢包情况突然极大的好转了，丢包率直线下降，到10号左右，访问cf已经基本不受任何影响，几乎回到了五月以前。这种情况一直持续到8月底。
然后到9月也就是前几天，仍然北京联通，出现了另一个意料之外的情况，大部分cf的ip段仍然正常，全天通畅，但我经常看的两个R18网站（都套了cf，域名未被墙，都是104开头的ip段）又受到了五月同款的IP丢包干扰。但是这次只有这俩网站受灾，其他套了cf的站都正常。
而这次这两个网站被阻断的特征也和之前无差别丢包不一样，这次ping和tcping是全时畅通的，但真连接时就会干扰。干扰方式仍然是丢包而非tcp阻断，所以网站不会立刻被rst超时也不会立刻打开，而是持续加载转圈很长时间，然后可能能加载出一部分东西，也可能超时。未见3分钟审查残留现象，完全是按时段随机的。干扰仍然是针对ip进行，伪造sni无效。
这种新的情况，首先可确定这次应该不再是线路故障而是故意的干扰了，因为联通cf都走的北京出入口一条线，ping都能通说明线路没问题。刚刚又测试了十几个套cf的网站，其中有的被干扰有的正常，似乎发现了一点规律：
1.被干扰的无一例外都是r18类网站，有的域名已被墙，有的尚未被墙。其他非r18正常网站未受干扰
2.干扰似乎是无状态的。没干扰的正经网站我在一小时内持续高强度访问，也未见阻断。被干扰的r18网站无论何时访问，都是干扰状态。干扰仅限特定网站，不会出现cf全体IP被连坐阻断三分钟的现象。
以上仍然仅限联通网，换成移动后一切通畅。
从这方面来看，显然cf内部不同的IP也有不同的待遇，有些涉黄网站的敏感IP受到了单独的IP干扰，属于正经网站的IP未受任何影响。也许联通也想搞一个墙中墙？
原联通有干扰，换电信就一点没有了且行且珍惜
浙江联通同样情况
@feizhuqwq 这个针对的是 Steam 域名而非 akamai CDN IP，去年底我就测试过了，哪怕你指向任意海外可用的 IP，该 IP 都会超时，且这个超时仅仅局限于你个人宽带，哪怕是你的邻居也完全不受影响。
该情况我称之为 SNI 干扰，即针对的是 SNI 域名。
https://v2ex.com/t/824179
Cloudflare
我没有遇到这种阻断超时的情况，但是丢包极其严重，大部分IP ICMP 4个丢3个 特别是 104和172段 只要网站套了CF且ip是这两个段的基本无法访问
联通的路由好像是有问题的。另外我这里移动104段几乎不可用，但是172完全正常
@feizhuqwq 这个针对的是 Steam 域名而非 akamai CDN IP，去年底我就测试过了，哪怕你指向任意海外可用的 IP，该 IP 都会超时，且这个超时仅仅局限于你个人宽带，哪怕是你的邻居也完全不受影响。
该情况我称之为 SNI 干扰，即针对的是 SNI 域名。 https://v2ex.com/t/824179
我突然在想，如果检测到大量不同ip连接同一个域名，且都能连接成功，这是否算是cloudflare自选ip的特有现象？
这样貌似就能轻松实现对自选ip针对性的干扰？
@feizhuqwq 这个针对的是 Steam 域名而非 akamai CDN IP，去年底我就测试过了，哪怕你指向任意海外可用的 IP，该 IP 都会超时，且这个超时仅仅局限于你个人宽带，哪怕是你的邻居也完全不受影响。
该情况我称之为 SNI 干扰，即针对的是 SNI 域名。 https://v2ex.com/t/824179我突然在想，如果检测到大量不同ip连接同一个域名，且都能连接成功，这是否算是cloudflare自选ip的特有现象？ 这样貌似就能轻松实现对自选ip针对性的干扰？
结合我这里刚测出来的ip不可用，但是几个月前测出的ip相当稳定，我估计ip优选被特征识别了
@wjr050430 墙真要针对，也没必要搞得这么细。
墙之所以讨厌 Cloudflare CDN，主要就两点：大量违法网站使用、大量代理套 CDN。
而之所以有这两种情况，主要是因为 Cloudflare CDN 免费，其他 CDN 都是按流量收费的搞不起。
- 违法网站：这个除了 SNI 域名外，和其他网站没什么不同，但是传统的 SNI 阻断太低效了。
- 代理套 CDN：这个大都是 WebSocket 协议链接，倒是可以针对下，但也必然会影响其他使用 WS 的正常网站。
无论如何，想要高效的解决这两点，都会影响其他使用 Cloudflare CDN 的正常网站。
而是不是自选 IP 根本不重要，不是说自选 IP 就一定是干这个的，很多正常网站也这样干（特别是一些高级套餐的），迫使 Cloudflare 前段时间关掉了免费 CNAME 接入的途径。
而且难道你现在用默认分配的两个 IP 也很稳定吗？我这边是都一样的几乎不可用，你自选的 IP 就是分配给别人的 IP，且一些加了钱的网站也能有好几个 CDN IP。
所以说，目前墙想解决掉这两点，但又无法避免大量误伤情况，又不能一刀切封掉全部 IP，所以只能采取现在这种方案了，即针对性的干扰 Cloudflare CDN，迫使干（违法网站、代理套 CDN）这些的人放弃该 CDN，普通网民的话也会自认为是网站网络垃圾~
“我这里刚测出来的ip不可用，但是几个月前测出的ip相当稳定”
除非你当前使用默认分配的 2 个 IP 相当稳定，唯独自选 IP 不行，否则这并不能证明墙在针对 自选 IP。
除非你当前使用默认分配的 2 个 IP 相当稳定，唯独自选 IP 不行，否则这并不能证明墙在针对 自选 IP。
同联通。默认分配的2个ip似乎一直可用，但自选ip刚配好时是可以的，过一段时间（还在找规律）后就完全访问，而且换另一个自选ip也无法访问，表现为连接超时。
不确定和这个issue是否相关。
对于自选ip，我遇到的问题是通5分钟，断3分钟，通5分钟，断10分钟，之后能ping通但tcp不通。此时换另一个ip也不会立即通
@PikuZheng 我这边联通已经是所有 IPv4 都几乎不可用（时能用时不能，间歇/随机 超时），我也懒得研究了，直接改用 IPv6 了，要舒服很多（回到以前的使用体验），不过这几天 Cloudflare CDN IPv6 突然丢包严重，不知道是不是单纯的网络问题。。。
进入九月以来也碰到这个问题了。小鸡在RN和Oracle上各有一台，出口是上海联通9929，之前稳定跑了两个月的配置（NAT+CF+VLess+ws+TLS）现在时不时无法连接，V2rayN客户端报错：
failed to handler mux client connection > proxy/vless/outbound: connection ends > proxy/vless/outbound: failed to write A request payload > transport/internet/websocket: failed to dial WebSocket > transport/internet/websocket: failed to dial to (wss://[NAT_IP]:[Port]/path): > read tcp 192.168.1.66:6348->[NAT_IP]:[Port]/path: wsarecv: An existing connection was forcibly closed by the remote host.
开始以为是炭云的问题，毕竟一直很拉，但是发现中转的QUIC流量就很正常。如果是直连VPS，也不会有以上报错。
以上一个朋友的描述跟我的经历很像，上海电信5-7月期间网络状况好到匪夷所思的地步，不知道是不是跟打击网络电信诈骗的活动有关系。眼前大会在即，网络状况马上就拉胯了，而且还是以前没碰到的情况。
除非你当前使用默认分配的 2 个 IP 相当稳定，唯独自选 IP 不行，否则这并不能证明墙在针对 自选 IP。
然而确实是这样。
山东移动，不使用自选ip，直接使用IPv4连接kali.download下载文件，香港路由，一切正常（104.18网段）。
使用几个月前测试出的自选ip，一切正常（无论网段）。
使用刚测出的104网段ip，无法连接。
使用刚测出的172网段ip，一切正常。
由于移动已经完全掌握了SNI阻断的技术来搞墙中墙，而且移动可以利用自选ip达到极其离谱的效果（无视晚高峰的香港路由），所以移动是有动机搞出这种特征识别来针对自选ip的，但也如前面所说，只针对104这个常用网段。但是分配的几个ip就十分稳定，无论哪个网段，怎么路由，都可以稳定连接，而且除了21~24点移动炸网之外还有不错的速度。至于有时候网页打不开，是HTTP3的锅，移动到了晚上就会大量丢弃UDP包，换成HTTP2就没问题。另外貌似移动会阻断某些websocket连接，比如在cloudflare编辑workers的时候，有时候会报websocket的错，用v2的时候也有少数报错。
另外我一个朋友也是联通，198网段websocket用的十分正常。但也不是我在用，这种情况就不是很了解了。
难不成还能随机干扰？
@wjr050430 除非是任何自选 IP 都不行才能实锤，你这自选 IP 有的行 有的不行的，也可能是其他原因造成的。
而且你列出的各种条件互相交织，却产生了各种不同的结果，因此也难以判断到底是什么原因导致的。
另外，即使移动要做，也没必要只针对 104 呀，那如果别人都去用 172 的话，岂不是白折腾了。。。
不过我对这些也不感兴趣，因为我这边联通 IPv4，无论是默认还是自选，都是一样的干扰。
@PikuZheng 我这边联通已经是所有 IPv4 都几乎不可用（时能用时不能，间歇/随机 超时），我也懒得研究了，直接改用 IPv6 了，要舒服很多（回到以前的使用体验），不过这几天 Cloudflare CDN IPv6 突然丢包严重，不知道是不是单纯的网络问题。。。
198的确不会断。真见鬼。
断的规律的确如楼上所说。大概3分钟左右触发（感觉是并发连接数触发？由于pt。零星连接不会触发），第一次断5分钟（ping不通）。然后大概通5分钟。然后ping通但数据不通。
比较了下默认的两个ip和优选测速结果都是走德国AS5511。考虑到edns，自选IP和默认IP效果应该是相同的。
稍微看了一下其他段可能是到美西甚至绕美到澳。我认为在当前环境下，只要dns正确，做不做自选IP结果是一样的。除非DNS给出的两个IP都无法连接，换IP才有意义。
另外，即使移动要做，也没必要只针对 104 呀，那如果别人都去用 172 的话，岂不是白折腾了。。。
我认为104的确是被针对了，因为这个段ip数量大，域名触发很容易导致一个小段都不可用。。。
@wjr050430 除非是任何自选 IP 都不行才能实锤，你这自选 IP 有的行 有的不行的，也可能是其他原因造成的。
104自选绝对不行，172就没事。他确实只针对104，不自选104网段一点事没有。
如果你是联通，你可以试试我提到的198网段
奇怪上面都是联通么？我上海电信今年5月就出现 有时候点一个cf网站忽然会断3分钟443端口情况。最近更加严重甚至有时候忽然所有cf无法访问 ping的通但是tcping就全部out的情况。只能重播ip。但是如果多次出现重播换ip也会失效。我是上海电信的。
奇怪上面都是联通么？我上海电信今年5月就出现 有时候点一个cf网站忽然会断3分钟443端口情况。最近更加严重甚至有时候忽然所有cf无法访问 ping的通但是tcping就全部out的情况。只能重播ip。但是如果多次出现重播换ip也会失效。我是上海电信的。
有没有测过是走哪个出口的，有没有可能是到欧洲要绕联通线路呢
那到没有，我路由过基本都是美国加利福尼亚圣何塞。出口就是普通电信163出口
奇怪上面都是联通么？我上海电信今年5月就出现 有时候点一个cf网站忽然会断3分钟443端口情况。最近更加严重甚至有时候忽然所有cf无法访问 ping的通但是tcping就全部out的情况。只能重播ip。但是如果多次出现重播换ip也会失效。我是上海电信的。
有没有测过是走哪个出口的，有没有可能是到欧洲要绕联通线路呢
那到没有，我路由过基本都是美国加利福尼亚圣何塞。出口就是普通电信163出口
不要tcp路由没有试过 不过正常情况tcp延迟也是150～180所以应该没有绕欧洲
奇怪上面都是联通么？我上海电信今年5月就出现 有时候点一个cf网站忽然会断3分钟443端口情况。最近更加严重甚至有时候忽然所有cf无法访问 ping的通但是tcping就全部out的情况。只能重播ip。但是如果多次出现重播换ip也会失效。我是上海电信的。
有没有测过是走哪个出口的，有没有可能是到欧洲要绕联通线路呢
而且我觉得这个阻断和出口无关我觉得是在进入国外出口前就阻断了。因为我无法访问时候借邻居电信网是正常的
我就举个我现在此时此刻的列子 大家不知道用过哔咔app不，我这里就是只要访问app的分流2，就会百分之百出现cf套所有网站被tcp阻断3分钟情况。3分后恢复可以访问cf套。不过你再去点哔咔分流2的话又会如此。基本就是百分之百触发。再次说明是上海电信网络。联通没用过 移动不会触发。
我就举个我现在此时此刻的列子 大家不知道用过哔咔app不，我这里就是只要访问app的分流2，就会百分之百出现cf套所有网站被tcp阻断3分钟情况。3分后恢复可以访问cf套。不过你再去点哔咔分流2的话又会如此。基本就是百分之百触发。再次说明是上海电信网络。联通没用过 移动不会触发。
我是联通，一直用哔卡分流3。同时还在用大量其他套Cf的资源网站，BT或PT站点。目前的情况是打开其他Cf网站基本正常，打开哔卡会随机干扰，但完全没有规律，不会一开始能上去然后一两分钟后阻断，也没有3分钟审查残留。就是纯随机的，可能一开始就上不去，也可能能正常连续用一个小时也没问题。而且阻断方式也不是rst，而是随机丢弃tcp包。从未出现过全体Cf被连坐阻断的情况。另外访问一些其他套Cf的R18网站也出现类似的情况。
至于移动，有墙中墙是根本上不去哔卡的。也不会触发其他Cf被连坐的现象。但移动访问其他套Cf的R18网站基本都是正常的，无干扰。
对于非优化线路（163，cn2什么的），移动对出国流量的确更友好。移动的主要问题是udp随机丢包（一种限流措施）。
可能一开始就上不去，也可能能正常连续用一个小时也没问题。而且阻断方式也不是rst，而是随机丢弃tcp包。
这里我觉得要看目标ip段，可能你的不在104，或是比较符合付费cf线路的丢包行为。
我就举个我现在此时此刻的列子 大家不知道用过哔咔app不，我这里就是只要访问app的分流2，就会百分之百出现cf套所有网站被tcp阻断3分钟情况。3分后恢复可以访问cf套。不过你再去点哔咔分流2的话又会如此。基本就是百分之百触发。再次说明是上海电信网络。联通没用过 移动不会触发。
我是联通，一直用哔卡分流3。同时还在用大量其他套Cf的资源网站，BT或PT站点。目前的情况是打开其他Cf网站基本正常，打开哔卡会随机干扰，但完全没有规律，不会一开始能上去然后一两分钟后阻断，也没有3分钟审查残留。就是纯随机的，可能一开始就上不去，也可能能正常连续用一个小时也没问题。而且阻断方式也不是rst，而是随机丢弃tcp包。从未出现过全体Cf被连坐阻断的情况。另外访问一些其他套Cf的R18网站也出现类似的情况。 至于移动，有墙中墙是根本上不去哔卡的。也不会触发其他Cf被连坐的现象。但移动访问其他套Cf的R18网站基本都是正常的，无干扰。
朋友试试分流2看看。我电信分流3也是随机 大部分时间正常。不过也偶尔出现无法访问后导致其他cf无法访问情况
我就举个我现在此时此刻的列子 大家不知道用过哔咔app不，我这里就是只要访问app的分流2，就会百分之百出现cf套所有网站被tcp阻断3分钟情况。3分后恢复可以访问cf套。不过你再去点哔咔分流2的话又会如此。基本就是百分之百触发。再次说明是上海电信网络。联通没用过 移动不会触发。
我是联通，一直用哔卡分流3。同时还在用大量其他套Cf的资源网站，BT或PT站点。目前的情况是打开其他Cf网站基本正常，打开哔卡会随机干扰，但完全没有规律，不会一开始能上去然后一两分钟后阻断，也没有3分钟审查残留。就是纯随机的，可能一开始就上不去，也可能能正常连续用一个小时也没问题。而且阻断方式也不是rst，而是随机丢弃tcp包。从未出现过全体Cf被连坐阻断的情况。另外访问一些其他套Cf的R18网站也出现类似的情况。 至于移动，有墙中墙是根本上不去哔卡的。也不会触发其他Cf被连坐的现象。但移动访问其他套Cf的R18网站基本都是正常的，无干扰。
朋友试试分流2看看。我电信分流3也是随机 大部分时间正常。不过也偶尔出现无法访问后导致其他cf无法访问情况
这几天用分流2感觉没太大变化，仍然是各种丢包。五分钟才能加载出来一张图。不过目前为止还没被rst直接阻断过，也没影响过其他套cf的网站
有没有什么方式能实现动态分流/负载?
既然某个IP访问三分钟内只能访问几次, 那么能不能 访问几次后自动切换IP, 有这种代理么?
我一开始想着用 Nginx 的负载均衡来着, 准备做的时候发现 没有站点的 ssl 证书, 还没法配置
Nginx 的负载均衡来着, 准备做的时候发现 没有站点的 ssl 证书, 还没法配置
nginx 可以用stream透传吧？不需要证书
我这边昨天开始，不光cf，cloudfront也遇到同样问题
我这边昨天开始，不光cf，cloudfront也遇到同样问题
是的，广东地区联通蜂窝网，cft也被阻断了，不清楚是短期政策还是长期就这样了。
说起来我这联通从前两天（不确定是哪天）连不上cf的付费ip了，自选的倒是正常（也可能是我没怎么用
联通就是有问题，你们可以用拨测工具测试套 cf 的域名，联通基本全阻断，电信基本正常，移动部分阻断
@PikuZheng 我这边联通已经是所有 IPv4 都几乎不可用（时能用时不能，间歇/随机 超时），我也懒得研究了，直接改用 IPv6 了，要舒服很多（回到以前的使用体验），不过这几天 Cloudflare CDN IPv6 突然丢包严重，不知道是不是单纯的网络问题。。。
问一下最近几天IPV6开可以吗？可以的话我就试一下。谢谢！
我也遇到了，电信，tcping 443 正常，设置科学上网一连接马上就完蛋了，过会tcping 443 又正常了,连接又崩了，shit
移动172开头连香港的之前还好，今天也这样了。。104早就这样了
说一下我这边的情况 不仅TLS会阻断. vmess +ws 也开始掐了.. Ipv4宣告GG 现在只剩下IPV6 一片净土了.
说一下我这里的情况，如果 TLS 会调用。vmess +ws 也开始掐了.. ipv4宣布GG现在只剩下IPV6一片净土了。
vmess 本身也会进行 TLS 加密啊，现在 GFW 已经开始通过 TLS fingerprint 封节点了，换协议吧
那么有没有大佬弄出来nginx负载均衡了 自己弄了半天没成功 看网上教程要自己编译加个module 结果编译失败了
编辑：
搜索了一下 发现还有别的负载均衡软件可以用 经测试haproxy可以实现
扔了3000个ip进去 但是连接次数多了还是会被阻断
把配置文件里的ssl相关配置删掉 用tcp模式就好了 我参考的这篇
我这边昨天开始，不光cf，cloudfront也遇到同样问题
我也是这样
大佬你这么操作了还阻断不，我现在用172的ip访问YouTube总是加载不出视频，别的倒没啥异常的。
网络环境不同 建议自行尝试 我这里是还会
广州联通cft 已恢复
那么有没有大佬弄出来nginx负载均衡了 自己弄了半天没成功 看网上教程要自己编译加个module 结果编译失败了 编辑： 搜索了一下 发现还有别的负载均衡软件可以用 经测试haproxy可以实现 扔了3000个ip进去 但是连接次数多了还是会被阻断 把配置文件里的ssl相关配置删掉 用tcp模式就好了 我参考的这篇
可以给个参考配置么
我写了个
在 移动网络下表现很好, TCP check 绿的 肯定能访问
但是在联通下面完全不行 联通 TCP check 全绿 但是无法访问
但是又不能开 http check 开完之后 前两轮大部分是绿的, 然后 过一会几乎全红
又陷入死局了看着...
可以给个参考配置么 我写了个 在 移动网络下表现很好, TCP check 绿的 肯定能访问 但是在联通下面完全不行 联通 TCP check 全绿 但是无法访问 但是又不能开 http check 开完之后 前两轮大部分是绿的, 然后 过一会几乎全红 又陷入死局了看着...
看了你的配置，就是这样的，我没开check，还有就是弄了挺多ip的。我这边也是访问多了还是阻断。
上海电信 vless ws tls cf 这两天断的厉害
nslookup 域名得到两个ip 其中一个ping不通 于是改host恢复了 不知道这样改对不对
另一个ip也被墙了该怎么办呢
上海电信 vless ws tls cf 这两天断的厉害 nslookup 域名得到两个ip 其中一个ping不通 于是改host恢复了 不知道这样改对不对 另一个ip也被墙了该怎么办呢
试试gcore cdn或者cloudfront
trojan套CF应该没问题
trojan套CF应该没问题
好像没看到过trojan套cf自选的教程