假设我有个一组节点,其中 n1 n2 n3 为低倍率节点,我希望通常情况都优先使用低倍率节点。
我想要配置如下优先级
我按照我对文档的理解,大概做了如下配置,通过 proxy-group 的嵌套功能:
proxy-groups:
- name: PROXY
type: fallback
proxies:
- Select
- Fallback
- UrlTest
- name: Select
type: select
use:
- ...
- name: Fallback
type: fallback
use:
- ...
filter: "低倍率"
- name: UrlTest
type: url-test
use:
- ...
这里我有两个疑虑:
1:这里我让最终的 PROXY 组进行嵌套,使用 fallback 类型,并自动尝试 Select -> Fallback -> UrlTest
不知道这样的 fallback 类型是不是合理?
2:这里是能实现我前面提到的 1-3 功能,但是我发现 Select 节点回归正常后,clash 并不会再重新按照 proxies 的优先级重新选择使用 Select ,而是一直保持之前 fallback 选中的节点
有没有方式能实现恢复后重新优先使用 Select 的操作?
有没有熟悉 Clash 规则的朋友帮忙解答下,万分感谢
1
Helsing 2023-06-18 13:28:25 +08:00 via iPhone
fallback 我记得是选中第一个可用的节点来用的,当前节点可用的话,是不会自动切换到下一个的,应该满足不了你的需求
|
2
estk 2023-06-18 13:31:18 +08:00 via iPhone
最近 cf 不太行了,很多直接无法访问
|
3
hehehu OP |
4
goodbest 2023-06-18 14:52:07 +08:00
可以的,我就是这个需求,但你不需要用到 fallback
定义一个名为 myselect 的 select 类型,可选服务器 a,b,c 然后直接在 url-test 里,按以下顺序排列即可(是的,myselect 也可作为被 test 的目标) myselect,a,b,c |
5
hehehu OP @goodbest
大佬你这个我感觉有个问题,如果 url-test 的结果是是其他节点 latency 远小于 myselect latency, 会选中其他节点吗 我希望的是 myselect 如果是 available 就一直使用 myselect, 如果失败则用 url-test |
6
goodbest 2023-06-18 15:31:44 +08:00
你说的情况我还真没考虑过,因为我 myselect 首选也都是最低 latency 的结点
可能需要看看 url-test 的具体实现策略,看看是不是无脑按最低延迟切换,还是有个切换的最小差值,还是只要不超时就不再切换 |
7
goodbest 2023-06-18 15:34:25 +08:00
|
8
hehehu OP @goodbest 嗯,我知道你说的 tolerance 配置,但是这里可能是会存在「第一次」 url test 的时候如果 myselect 不是最快,并且设置了相对较大的 tolerance 可能就会一直用非自选节点
|
9
goodbest 2023-06-18 16:26:45 +08:00
所以还是要看看实现细节
如果你把 tolerance 设置的大一点,比如 2 秒之类(一般服务器的延迟差距不会这么大) 那么这样第一次启动时, - 是严格等全部 test 之后,选一个延时最低的 - 还是先按顺序建立连接(这种情况也即首先连上第一顺序的 myselect ),然后后续再 test 第二种情况最理想,因为有了比较大的 tolerance ,一旦连上之后,除非 myselect 离线,否则不会切换 |