安全，但是并非安全。

如果你是一个长期折腾 Clash / Mihomo 配置的玩家，你一定习惯了长长的一串 DOMAIN-SUFFIX（域名后缀）分流规则。我们理所当然地认为：只要写上 google.com 走代理，qq.com 走直连，分流就能完美运作——第三方作者、社区维护的一万个域名对应表，这一切会随着ECH的铺开而成为泡影。即便国内没有完全普及，在互联网整合赢者通吃的模式下cdn厂商的大厂压力下，似乎也算不得什么奇怪的事情。

什么是ECH？

ECH (Encrypted Client Hello) 是对于sni发送目标的加密，很多B站小登的科学上网入门教程会讲数据包传输加密是一次快递打包，只有收件人是明文。同样用这个例子，大公司的中介使得收件人可以是这个快递公司本身，再由快递公司内部进行分发，作为明文的只剩下cnd公司公开ip。我在Maodie-Launcher的最新发行中去除了sniffer，除了机制本身的逻辑冲突、部分app的纯ip内部处理方式、与完善规则赋予的网络保障，我们同样需要考虑到ECH带来的影响。

我们同样使用了cn_ip进行流量规则处理，然而这种方案总不是尽善尽美。我的微信是外行的账户外行的客户端，数据在国外服务器上，出于wechat本身规则的影响，即便我人在大陆，我的微信请求（尤其是图片类、视频类）会通过新加坡的腾讯云ip，这在我之前的match保底集合中随着机场转发与quic不良的一套组合拳打出gg。我尝试过腾讯规则、ip规则，最后还是转向了ASN辨别。

引入 ASN 进行底层分流

ASN (Autonomous System Number, 自治系统号)是任何大型互联网公司向国际机构申请 IP 资源时所关联的唯一的号码。比如，腾讯亚太区核心数据中心的 ASN 是 AS132203。无论腾讯在新加坡、香港还是硅谷增加了多少新 IP 段，这些 IP 统统归属于 AS132203。参考：https://bgp.he.net/AS132203，它忠实的记录了大陆、新加坡等腾讯云节点的ip地址是什么。所以，一行简单的

- IP-ASN,132203,直连,no-resolve

足已完成问题。

强强？

参考https://github.com/XTLS/BBS/issues/20，部分国内应用也在使用国际共享 CDN，如果我们不假思索将cf全部cdn设置成代理模式，那么部分恶意软件会携带你的设备标识符，通过你的代理节点 IP 发送给国内厂商。目前，我们是通过克制的asn规则与fake-ip来防止泄露的。

哦对了，我的Maodie-Launcher已经是很优秀的发行版了，我通过metacube界面进行管理，以及写了一个ksu webui来随时更改proxy-provider，不论你是新手还是老手，这都是一个很不错的工具。