@binghe

正确配置的规则应该完全不依赖 dns ，因为需要代理的连接在触碰到 ip rule 之前就被分流走了，dns 只用来偶尔负责兜底一些不在分流规则的网站。

关注 dns 配置的无非就是天天说 dnsleak 的人。

然而 dns 泄露是个伪命题，或者说这个用于 vpn 的名词根本没办法套用到需要分流的场景里。

举个简单的例子，假如不知道域名 A 该走代理还是直连，这个时候就需要做 dns 解析，那应该先用远程 dns 解析还是本地 dns 解析呢？

1. 用远程 dns ，会导致有海外 cdn 的网站分流错误，国内网站解析不到最优 cdn ，结果是显著影响国内网站的体验。

2. 用本地 dns ，就会出现所谓“dns 泄露”。

dns 泄露是 vpn 厂家发明出来的，他们的用户完全没有分流需求，要的就是极致的隐私保护，当然就不存在以上问题。用这种概念往分流代理工具上硬套完全就是庸人自扰。

上面这段话全是事实，教程当然可以写，但是如果实事求是把这些东西讲出来，天天发 dnsleaktest 截图那帮人就不爱听了，而不关注 dns 的其他用户又不会点，结果就是根本没人看。

y2b 上一帮哗众取宠的博主拿个概念唬小白，给出来个笑话一样的解决方案，骗到播放量跟粉丝完事，他们才不关心实际体验怎么样。

比方说某三字主播，给的方案是所有 ip rule 加上 no resolve ，那当然没泄露了，代价是所有 ip 规则的兜底作用全部废掉，用了他的规则之后，只要是没在域名列表里面的连接要么全直连要么全代理，全代理就是国内网站巨慢，全直连就是国外网站上不去。但他才不管，小白爱听就完事了。

@Livid 推广内容，go/promotions

@ob 你需要打开的是订阅转换网站。

@Hoshizora 确实，你说的这个方法更好。

@Helsing 手滑贴反了，那么请你回答一下两个问题？省心在哪里？又不方便看在哪里？

@Helsing 从你的回复我大致可以确定你完全不懂，但是为了以防可能的误解，以及你的回复误导别人，我针对你提出的两个问题详细解释一下。

第一个，关于 provider

参考 https://lancellc.gitbook.io/clash/clash-config-file/rule-provider

classic 类型的 provider 的格式是


```
payload:
- '.blogger.com'
- '*.*.microsoft.com'
- 'books.itunes.apple.com'
```

domain 类型的 provider 的格式是

```
payload:
- DOMAIN-SUFFIX,google.com
- DOMAIN-KEYWORD,google
- DOMAIN,ad.com
- SRC-IP-CIDR,192.168.1.201/32
- IP-CIDR,127.0.0.0/8
- GEOIP,CN
- DST-PORT,80
- SRC-PORT,7777
```

你说的“订阅规则都不好找”是什么意思？你要说是找不到文件，配置文件里路径写的明明白白的，正常使用情况下也不用手动找。但是如果你的意思是“- DOMAIN-SUFFIX,google.com”比“.blogger.com”更容易看我觉得更奇怪。

第二，“不如搭建 subconverter”，你真的有搭建过吗？我搭建过。你知道自定义规则需要怎么做吗？依然需要写这个格式的配置。

对比来说，我的教程只是把自建的时候写到“配置文件”部分的内容，移动到了“外部配置”这部分，我很想知道你说的省心是指省心在哪里？

给其他人：关于这部分内容，可以参考
https://github.com/tindy2013/subconverter/blob/master/README-cn.md

或许你的语言表达有误，但是单从你的这一条回复来说是基本概念没有分清的状态。

@Helsing 你真的有看正文吗？

@paststrange “subconverter 默认展开规则，但实际上 rule provider 的性能更好”，所以推荐使用 provider
要了解 provider 可以看 clash 的官方文档 https://dreamacro.github.io/clash/premium/rule-providers.html
或者 https://lancellc.gitbook.io/clash/clash-config-file/proxy-provider

要让 subconverter 不展开规则，在订阅链接末尾加上&expand=false ，但是又可能导致订阅无法使用，原因正文说过了。

说得直观一点，就是打开配置文件，如果 rule 里全部都是域名和 ip ，那么规则就是展开的，这时性能非常差，并且占内存。
如果 rule 下面是 RULE-SET ，那么就叫做不展开，这时性能更好，匹配速度更快（ 34 万规则 7 微秒），内存占用更小。

另外，rule set 也分类型，classic 没有优化作用，ip cidr 和 domain 有强力的优化作用，这部分具体还是看 https://lancellc.gitbook.io/clash/clash-config-file/proxy-provider 。

@Huelse 为了防止被滥用做了一些安全措施，自己配置的话不会有这个问题。
@superzzy 是的，主要是有被滥用风险。

@aptupdate 首先变快只是附带的，最初始的目的是你说的落地，隐私，避免 ip 变化这些。

其次，变快的原因是省去了握手，即便是 ss 协议的机场，在跨境段可能也使用了 tls ，相当于每条连接都要多花一倍的时间在握手上，这还只算了应用层，没算传输层。
连接复用之后，你透过代理访问网站的握手次数实际上等于直接访问，自然就快了。
更详细的信息你可以 google 协议名称+rtt 。

@tcpdump 猜到会有这个质疑，为了避嫌这里用的是公共服务，你可以自行 google 搜索 sublink.dev 了解一下这个转换服务哪些人在用，也可以自己替换成别的。

@Anybfans 使用 secret gist ，然后自建一个 ghproxy 。

@A01514035 可以考虑使用 grpc ，就像示例一样，这样就会只有一条 tunnel 连接。
grpc 的主要缺点是在高丢包线路上表现不佳，tunnel 基本上解决了这个问题，因此可以无成本享受 grpc 连接复用的好处。

@totoro625 是的，tunnels 的一大好处就是解决了原版内核 relay 不支持 udp 的痛点，并且如果是使用支持 uot 的协议的话，就算外层不支持 udp 也可以实现 fullcone 。

实际上 relay 还有很多奇奇怪怪的问题，比如说如 grpc 和 relay 搭配会造成延迟变高，还有内层协议是 http ，tls ，socks 的话有可能会无法连接（我收到不少人询问这个事）。

tunnel 目前看起来没有这些问题，兼容性最佳，又支持 udp 。

（上面这段话与 t.me/R_A_D_E 共同编写）

@israinbow 即便有连接复用也节省不了实际浏览网页的那个握手。
这里节省掉的是代理线路上的握手，这个依然是非常长的。
举个例子来说，如果使用 ws+tls ，那么每个连接都需要两次 tls 握手+1 次 ws upgrade ，把代理线路的握手省掉之后相当于每个连接都只要网站本身的握手，还是可以减少不少的。

当然你说的带宽在视频场景下确实影响也不小，这套方案我实际使用下来起速挺快的，不过这个就因线路而异了。

@fzls 好的好的，多谢提醒。我想着避免有宣传嫌疑就没有放，没想到还恰好躲过一劫。