直接在防火墙里限制 80 443 端口只允许 Cloudflare CDN 的 IP 访问即可，一直都是这样干的，而且效率更高。

@mumuwen 建立团队专门研究各个手机系统的漏洞，利用漏洞获取用户手机的类似临时 ROOT 权限，并通过该权限收集用户信息，操作修改用户手机。这种行为不管放到哪里看，都是典型的 [木马病毒] 。

就是因为这个，我只敢用小程序版的拼多多，不敢去用客户端（虽然之前也是一直小程序）。
参考 “破窗效应”，像这种无底线行为有了第一次，那么大概率就会有第二次、第三次，已经无法再相信它了。

看我 21 年发的贴子：
/t/758568

CDN 就是一个加强版的反向代理。

这种反向代理是需要 SSL 加解密的。

浏览器 <=加解密=> Cloudflare CDN <=加解密=> 源站

使用 DDU （ Display Driver Uninstaller ）或者 AMD 官方推荐的 AMD Cleanuputility 一键小工具来卸载显卡驱动，它们原理都是一样的（而且也都会重启为安全模式后再去彻底卸载），不过后者只适用于 AMD 自己。

另外，补充一下，还有一种情况可能会和我上面描述的部分特征重合，那就是国内各地各运营商搞得独立 反炸 机制（黑白名单）。

如果你访问网站遇到阻断重置，可以尝试用 curl -I 等方式访问一下该域名的 http 地址（浏览器直接访问的话可能会被自动改为 https ），看是否会显示要重定向到 反炸 地址，如果不是的话，才需要进一步排查其他可能。

反炸 这玩意，真的是不同地区不同运营商，都不一样，都有一份各自维护的黑白名单？

楼上的情况，和 反炸 的情况混合起来，真的是进一步恶化了网络环境。。。

早在 2022 年 5 月，我就已经遇到了你描述的情况，并且做了详细测试：

https://github.com/XIU2/CloudflareSpeedTest/issues/217

这其实就是蔷针对 Cloudflare CDN IP 的一种干扰措施（暂时称为 IP 干扰），类似于 Github 、Steam 的 SNI 干扰，但后者是针对的特定域名，而不在乎你访问的是哪个 IP （即使你尝试向一个完全不相干的 IP 以这两个网站的域名去建立 HTTPS 链接，也会随机触发 IP 443 端口阻断超时 3 分钟整，关于这两个网站，在好些年前我就已经在 V2EX 发过帖子描述问题及稳定复现步骤了，你可以自行去看）。
而针对 Cloudflare CDN IP 的这种干扰，是只针对其 IP 段，不在乎你访问的是哪个域名（已经被彻底阻断的域名除外），只要向 Cloudflare CDN 的 IP 建立 HTTPS 链接，就有概率被随机阻断（或者说重置），也是 IP 443 端口超时 3 分钟整（至少两年前我测试的时候是这样的，现在变了没有不清楚）。


因为各个运营商都有人反馈过该问题（都来自各个地区），所以你换运营商估计是没用的。
其实在此次 IP 干扰出现后，面向国内用户的海外网站如果还套 Cloudflare CDN ，等于放弃一部分国内用户了。

但这些无法访问的用户可以说是随机的，因为不同时间、不同地区、不同运营商，随机干扰阻断的概率也是不一样的，或者说是动态的，你可以理解为蔷就是为了伪装成 “这些网站的网络问题”，很多小白新手很吃这一套，确实很多都是这样认为的，觉得网站服务器真辣鸡之类的（ Github 、Steam 被 SNI 干扰的时候，特别是 Steam 的时候，大批大批的普通网民都是这种言论，而且还说的条条道道的，甚至做视频发文章搞科普。。。

感觉当时似乎很多人混在其中故意往这方面引导舆论，再加上当时 贴吧 等地更是直接禁止讨论，然后慢慢的大家都习惯了，这才过去不到 3 年，很多人就以为上 Steam 开加速器是 "理所应当"、是 "从来便是如此" 的了。。。

其实，不管是 Github 、Steam 还是 Cloudflare CDN 的干扰，本质上就是蔷给国内用户设置了 [一个门槛，一个过滤器] ，如果你 [无法迈过去，无法解决该问题] ，那么你就被拦住，被过滤掉了，蔷就认为你不适合接触这些网站（或许是认为你的认知能力不足？容易被花花世界影响？），而对于 [有能力迈过去的人] ，那么就算是把这些网站彻底阻断了，照样能访问，而彻底阻断又会遭到舆论影响（这可就不是搞点人引导下舆论就能平息的，而是彻底摊牌是蔷干的了），影响的网站太多，影响太大，国际舆论也小不了。
所以，只做随机干扰阻断来作为门槛，似乎是个较为 “完美” 的方案。


另外，2022 年只是我正式遇到该问题的时间，并不是该问题出现的时间，更早之前（ 2021 年底吧大概，当时正好是 Steam 被 SNI 干扰的时候）就有人在我项目里反馈了，但当时我还没遇到

不过这种阻断似乎只局限于 IPv4+TCP ，用 IPv6+UDP （ QUIC/HTTP3 ）甚至还能直连本站呢。

我对微信最大的怨气还是 不接入 PUSH 的问题，要一直挂在后台，太烦人了，特别是对于我这种平时大部分时间不会收到微信消息的，为了偶尔才会收到的消息被迫挂在后台，浪费内存浪费电。。。

@ZeroClover 不懂问下哈，也是其他商家的正常续费零售价，比批发成本价还低？

如果是这样，那要么是这些商家真的是贴钱留用户（特别是在 Cloudflare 也开始搞域名后），要么就是 Cloudflare 说谎？或者说 Cloudflare 的批发成本价比其他商家的更高？

不过，如果 Cloudflare 是说谎的话，那么其他同行不可能发现不了，但好像没人曝光。。。

那是 Cloudflare 批发成本价更高？有没有懂这个的？这种批发价是大家都一样，还是规模大的更便宜？

@villivateur 最早在 2022 年 5 月 24 日左右，我这边联通就遇到了针对 Cloudflare CDN IP 的 HTTPS 干扰（只要与 CF 的 IP 建立 HTTPS 连接，就有概率被阻断，IP 的 443 端口就会超时 3 分钟整），和 Steam 、Github 的 SNI 干扰比较类似（但他们两个这个是根据域名来超时 IP 的，不在乎是什么 IP 。而 Cloudflare 这个是针对其 CDN IP 的，暂时称为 IP 干扰吧）。

而在此之前，其实就已经有人陆续在我项目反应该问题了（可能有半年了？），只不过之前我这边联通一直没遇到过，我遇到之后自己简单检查并可以稳定复现确认问题后，就发了个 Issues 已经累计了两百多条讨论，很多人也表示遇到了。

另外，后来我也观测到 AWS CloudFront CDN 、Gcore CDN 、Fastly CDN 也出现了类似情况，不过相对较轻？时有时无的样子。

问下 AWRP 的 MASQUE 协议（也就是 HTTP/3 QUIC ）的 SNI 域名是什么？应该是固定的吧？那岂不是直接 SNI 阻断就 G 了？。。。还是说搭配了 Cloudflare 推广的 ECH 加密方案？

我记得之前一段时间，在官匹时不时就会遇到丢包卡顿的情况，甚至有时候能卡到游戏掉线，我也观察询问过，每次卡的时候并不只有我一个人卡，而是大家都卡，或者一部分人卡一部分人不卡（或者轮流随机来？）。

当时在贴吧什么的地方也见到有人说这个问题，我记得之前不是说 Steam 被攻击了？不知道和这个有没有关系，不过最近几天倒是没有卡顿情况出现了。

我记得以前比较关注这些应用上传的情况时，发现电视上的腾讯视频在观看视频的时候，会一直存在上传速度，我也知道这应该就是 PCDN 了，我当时尝试限制电视的上传速度到很低（比如几十 KB/s ），结果发现腾讯视频的播放速度（也就是下载速度）也会变得很低很卡，不是很懂这是为啥（难道说是腾讯视频做了上传速度检测？），后来也没去管了。。。

@XIU2 嗳？。。。我把这个帖子内的第一个 URL 刚才回复时发出去后，被网站识别自动转为 img 图片元素了，不过 img 的 src 域名是 i. v2ex. co 这个真正的图片 URL ，A 标签的 href 也去掉了域名变成相对路径了。

那这样的话，我好像也没必要再去优化脚本单独处理这个了？。。。

@superrichman 因为你说的这个 "上面第一张图"：
https://www.v2ex.com/i/vZthp43U.png
其实不是一个图片 URL ，而是一个网页，你点进去访问该 URL 后，看到的第一张图片才是真正的图片 URL：
https://i.v2ex.co/vZthp43Ul.png
当然，还有下面的第二张图片（也就是本贴所说的图片 IPFS 地址）也是真正的图片 URL 。

我很早之前随手写的 V2EX 增强脚本里面的 链接转图片 功能非常简单粗暴，就是直接把帖子内所有含有 图片后缀 的 a 链接（且本身不是网站支持的图床没有被网站自动转为 img 的）转为 img 图片元素。

稍后我会检查一下，看能不能排除下这些特殊情况。

你可以看一下另一个功能类似但开源的 fishjar/kiss-translator 代码是怎么实现的。
我记得这个作者好像也在 V2EX ？反正我也是在 V2EX 里发现这个项目的。

但是我直接从 YTS 下载 BT 的话，也能随随便便突破 10MB/s 的下载速度呀。。。

主要还是空间太小，有点鸡肋。。。

几十块钱买了个二手的双飞燕 A91 （挑了个底部垫片看不出来磨损的，比较新的。另外全新的也才一百出头），就是因为看重了 光微动+光编码器（滚轮），据说这种都很耐用（我也网上搜了这个型号，确实很多评价都用了很多年不坏），不过缺点是中键和侧键的微动都是普通的，但考虑到用的比较少就算了。

不过我才用了 5 个月，时间太短倒也没出过什么问题。

TLS 、HTTPS 、HTTPS3 协议的 DNS 都是需要握手证书加密的，是无法像明文的 UDP DNS 那样被抢答的（除非搞中间人攻击）。

但是可以被劫持、干扰、阻断、重置等等操作，让你无法正常使用，或者可用性差。

至少我这边，Cloudflare 、Google 的 DoT 、DoH 是都被阻断了，DoH3 的话，也只有部分 IPv6 的还能用，有几个 IP 似乎是全协议封禁了。