Clash 规则能否做到优先 Select，若失败自动按顺序使用某几个特定节点，如果还是失败进行 url-test。如果 Select 恢复，则回到 Select 节点
nbsp; hehehu 2023-06-18 13:24:30 +08:00 5692 次点击这是一个创建于 917 天前的主题，其中的信息可能已经有所发展或是发生改变。
假设我有个一组节点，其中 n1 n2 n3 为低倍率节点，我希望通常情况都优先使用低倍率节点。
我想要配置如下优先级
- 优先 select （可选范围是全部节点，日常我从中选中低倍率的）
- 如果节点崩了使用 fallback （挨个尝试低倍率节点 n1 n2 n3 ）
- 如果还是失败，则 url-test 剩下的节点
- （重要）如果 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 规则的朋友帮忙解答下，万分感谢
 | 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 离线，否则不会切换 |
| 12 hehehu OP @echooo0 从 github 了解到了一些实现细节 fallback 是根据节点 alive 属性来判断选择的，不管是 gui 上的测速，还是 interval 的测速，会重置 alive 状态进而重新从前往后选择节点。 按照这个实现，应该是在 select 节点恢复后，能够再自动选回 select 节点的。 按照 Dreamacro 大佬说我测试结果有可能是 lazy 属性的干扰，虽然我没设置 lazy: true ，也不太清楚默认值是什么，我显示设置 lazy: false 再试一下。 |
 | 13 liyunlong5 342 天前 via Android 解答疑惑，Select -> Fallback -> UrlTest 思路是对的，clash/meta 支持套娃，针对 Select -> Fallback -> UrlTest 这三都同时设置 url-test ，并且 lazy: false 即可 |
| 14 hehehu OP @liyunlong5 迟到的感谢！我试一下 |
 | 15 hanssx 280 天前 op 搞定了没，我和你差不多的需求，另外我想问下，fallback 这个可以设置延迟容忍吗，即延迟>1000ms ，跳到下一个节点，默认 fallback 要是 timeout 才行。 |
Select Language