Clash 规则能否做到优先 Select，若失败自动按顺序使用某几个特定节点，如果还是失败进行 url-test。如果 Select 恢复，则回到 Select 节点

[hehehu]

假设我有个一组节点，其中 n1 n2 n3 为低倍率节点，我希望通常情况都优先使用低倍率节点。

我想要配置如下优先级

1. 优先 select （可选范围是全部节点，日常我从中选中低倍率的）
2. 如果节点崩了使用 fallback （挨个尝试低倍率节点 n1 n2 n3 ）
3. 如果还是失败，则 url-test 剩下的节点
4. （重要）如果 select 节点恢复了，则自动切回 select

我按照我对文档的理解，大概做了如下配置，通过 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 规则的朋友帮忙解答下，万分感谢

[Helsing]

fallback 我记得是选中第一个可用的节点来用的，当前节点可用的话，是不会自动切换到下一个的，应该满足不了你的需求

[estk]

最近 cf 不太行了，很多直接无法访问

[hehehu]

@Helsing 是的，有空我看下 fallback 的代码怎么写的

目前测试下来是节点异常 fallback 到一个可用节点后，前序节点恢复不会切回前序节点

[goodbest]

可以的，我就是这个需求，但你不需要用到 fallback


定义一个名为 myselect 的 select 类型，可选服务器 a,b,c

然后直接在 url-test 里，按以下顺序排列即可（是的，myselect 也可作为被 test 的目标）
myselect,a,b,c

[hehehu]

@goodbest

大佬你这个我感觉有个问题，如果 url-test 的结果是是其他节点 latency 远小于 myselect latency, 会选中其他节点吗

我希望的是 myselect 如果是 available 就一直使用 myselect, 如果失败则用 url-test

[goodbest]

你说的情况我还真没考虑过，因为我 myselect 首选也都是最低 latency 的结点


可能需要看看 url-test 的具体实现策略，看看是不是无脑按最低延迟切换，还是有个切换的最小差值，还是只要不超时就不再切换

[goodbest]

看这里，好像一个变量可以设置

https://lancellc.gitbook.io/clash/clash-config-file/proxy-groups/auto#tolerance

[hehehu]

@goodbest 嗯，我知道你说的 tolerance 配置，但是这里可能是会存在「第一次」 url test 的时候如果 myselect 不是最快，并且设置了相对较大的 tolerance 可能就会一直用非自选节点

[goodbest]

所以还是要看看实现细节

如果你把 tolerance 设置的大一点，比如 2 秒之类（一般服务器的延迟差距不会这么大）

那么这样第一次启动时，
- 是严格等全部 test 之后，选一个延时最低的
- 还是先按顺序建立连接（这种情况也即首先连上第一顺序的 myselect ），然后后续再 test

第二种情况最理想，因为有了比较大的 tolerance ，一旦连上之后，除非 myselect 离线，否则不会切换

[echooo0]

@hehehu #3 我记得好像是会回到的，fallback 的原理是按照节点的数组顺序，选择第一个可用节点

[echooo0]

@echooo0 #10 但是回到前序节点，是按照数组顺序排列的，可能不是你 select 的那个

[hehehu]

@echooo0 从 github 了解到了一些实现细节

fallback 是根据节点 alive 属性来判断选择的，不管是 gui 上的测速，还是 interval 的测速，会重置 alive 状态进而重新从前往后选择节点。

按照这个实现，应该是在 select 节点恢复后，能够再自动选回 select 节点的。

按照 Dreamacro 大佬说我测试结果有可能是 lazy 属性的干扰，虽然我没设置 lazy: true ，也不太清楚默认值是什么，我显示设置 lazy: false 再试一下。