@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 好的好的，多谢提醒。我想着避免有宣传嫌疑就没有放，没想到还恰好躲过一劫。

可以试试我的帖子
https://www.v2ex.com/t/933469

@liubing851 教程网上随便搜都有，服务器不清楚，别人送的，我只有 ssh 权限。

@Tender08 好耶

@wonderfulcxm 算不上，本身没有跨境能力。