CloudflareSpeedTest
CloudflareSpeedTest copied to clipboard
XIU2
Cloudflare CDN 似乎被故意 `干扰 / 阻断` 了？标准的超时 3 分钟（刚测完速的 IP 就 443 端口超时了
以前一直看到有人说 Cloudflare CDN 的 IP 被干扰阻断，但是我联通一直没遇到，不过最近我这边也出现了类似的情况。
而且我这次很确定是 运营商/墙 干的，干扰的很厉害。 同一个 IP，不访问时一切正常（ICMP、TCP 通顺），一旦访问很快就超时了（但不是立马超时，会给你预留几秒），而且还是标准的 3 分钟整，太规律了就显得太假了。
有类似情况的，可以电脑上装个 TCPing 工具，遇到无法使用时就
TCPing -t IP 443持续测试，我这边是超时 90 次（超时时间 2 秒） 就会恢复，而在超时期间，手机网络、在线网站全国端口检测都通顺。
这让我想到了 Steam、Github 的 SNI 干扰（不过这个是根据域名来超时 IP 的，不在乎是什么 IP。而 Cloudflare 这个是针对其CDN IP 的，暂时称为 IP 干扰吧），也是一但访问可能就会超时 3 分钟整，都是只局限于单个宽带用户（即只有你超时，其他人哪怕是邻居也完全不受影响）。
不过并不是全天都这样的，时有时无的，应该是想伪装成网络质量问题，老套路了~
有时候刚用 CloudflareST 测完速（有下载速度就代表 IP 可用），得到的 IP 就 443 端口超时 3 分钟了，非常规律。
看来距离 Cloudflare "自愿" 退出中国不远了，我已经完全改用 IPv6 了，应该会多撑一段时间，且用且珍惜。
另外，这种情况我在 Fastly CDN 上也遇到过类似的。
有遇见类似情况的没有？可以讨论交流下。
据说是GFW专门针对优选ip的手段，使用优选ip访问非cloudflare域名就会触发，猜测是常用的优选ip段可能有一个sni白名单。
如果是要中转梯子，解决方法其实也简单，不套tls不发sni，用80/8080等http端口连接cloudflare就行了。
@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 就像我说的：一旦访问很快就超时了（但不是立马超时，会延迟几秒，所以刚开始能打开一两个网页的样子）。 虽然不是全天持续性的，但时不时来一下是真的烦人。。。
我这也是，用
CloudflareST测速的时候好好的，然后把优选ip写到/etc/hosts后，访问cloudflare的worker，直接就SSL连接都建立不了，同一时间挂代理又很可以，感觉cloudflare的CDN在我这网络环境下已经废了。
workers.dev已经确认是被干扰了, 现在有人的改用pages，有的人用自己的域名，设置路由指向worker https://github.com/XIU2/CloudflareSpeedTest/issues/205
据说是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被隐藏了不会被墙，但是域名有可能被墙对吗？
是的。
