clash 中将使用 url-test 的节点进行 relay 放到 fallback-auto 中的奇怪问题

2023-09-16 21:50:01 +08:00
 FaiChou

有一个自建的日本服务器,但是直接访问这个日本服务器会比较慢。 于是想到了用一个机场的 url-test 进行 relay ,将机场中的所有日本节点使用正则将其放到一个 group 中,这个 group 用 url-test ,每 6 分钟进行一次测试,它会自动选择延迟最低的节点,这样用这个节点 relay 日本服务器,生成一个新的 group 。这样的一个节点大概率是可用的,最终落地 ip 也是稳定的。

但有些情况,比如日本服务器维护了,或者机场的节点都挂了,这样上面这个节点就会不可用。

所以将其放到 fallback-auto 中,它会自动选取第一个可以连接的节点,也是每 6 分钟检测一次。

但经过最近一段时间的测试(openwrt 每天晚上自动重启+openclash meta 内核),fallbackauto 组经常不会选择第一个 relay 节点,需要手动先对日本节点测试,再在 fallbackauto 组测试后,才会选择上第一个节点。

所以不知道是软件问题还是我配置问题。 能想到的问题应该可能跟 url-test 的测试频率有关系。如果 url-test 没有进行测试,此时选择的第一个节点如果不可达,这时 fallback 测试,会用第一个日本节点进行 relay ,使用正则进行选取的日本节点无法手动排序。

讲了这么多不知道讲清楚没有,下面是配置:

- { name: fallback-auto, type: fallback, use: [], proxies: [Relay, 自建服务器, 日本, 香港, 新加坡, 美国, 其他], url: 'http://www.gstatic.com/generate_204', interval: 300 }
- { name: Relay, type: relay, proxies: [日本, 自建服务器] }
- { name: 日本, type: url-test, filter: "(?i)日|🇯🇵|JP|jp|(?i)japan", use: [机场 1, 机场 2, 机场 3], url: http://cp.cloudflare.com/generate_204, interval: 600 }
3034 次点击
所在节点    程序员
12 条回复
FaiChou
2023-09-16 21:54:58 +08:00
fallback-auto 进行 test 时候 会触发 url-test 吗?
ncepuzs
2023-09-16 22:26:51 +08:00
配置文件看上去没啥问题,不过 url-test 这类规则在内核重启或更新订阅时确实会先默认使用组内第一个节点

只是,我有个疑问,为什么要执着使用机场的日本节点来 relay 呢,其他地区效果也一样啊;以及,用作 relay 的话,负载均衡 consistent-hashing 甚至是 round-robin 应该要比单一 url-test 要好啊。这样的话,可能也就不需要 fallback 分组了
FaiChou
2023-09-16 22:42:22 +08:00
@ncepuzs 我的服务器在日本,日常直连测试延迟 500+ms ,使用机场的日本节点 relay 是 400 左右。使用 relay 不怕自建的服务器被墙,并且最终请求都是从自建服务器发出的,ip 也不会随便乱动。

load balance 的话不论是轮询还是散列 eTLD+1 ,都是更换一堆节点访问。
比如我打开 PayPal 网站,可能用的节点 A ,关掉页面( tcp 连接断开)下次再访问,节点就换了。这样不稳定不符合我的要求。
FaiChou
2023-09-16 22:49:38 +08:00
@ncepuzs 有没有跟正则有关系?正则后的列表 url-test 问题。我开了一会 clashxpro ,记得之前 url-test 会保留一堆测速结果,当我去看时候并没有测速。
totoro625
2023-09-16 22:57:23 +08:00
1 、设置 lazy: false
Meta issue 较少,但是因为是 Another Clash Kernel ,可以参考 clash: https://github.com/Dreamacro/clash/issues/2809
2 、interval 不要设置倍数关系
可能测速结果丢了,或者测速时间太长,被 fallback 跳过了
3 、日本组内设置节点少于 10 个试试
totoro625
2023-09-16 23:05:31 +08:00
@FaiChou #3 指的是让你 relay 里面的“日本, type: url-test”换成“load-balance round-robin”,这样一堆日本的节点连接 relay ,最终请求都是从自建服务器发出的,ip 不会随便乱动。
FaiChou
2023-09-16 23:11:27 +08:00
@totoro625 那如果从某个延迟很高的节点发出 relay ,比直连更慢了。所以主题中的方案应该是最佳了。
ncepuzs
2023-09-16 23:19:09 +08:00
@FaiChou 不是,我是说你“日本”这个分组使用 type: load-balance 或 url-test 所有节点,既然是 relay 为什么不用最快的或者是尽可能榨干线路呢
FaiChou
2023-09-17 10:03:26 +08:00
@totoro625 #5
查看 ClashX Pro 的日志,使用正则匹配的 group 进行 url-test 都会失败: HeathCheck for 日本 failed:404 。虽然日志显示失败,但最终是没问题的。

不知道其有没有影响。
totoro625
2023-09-17 10:59:04 +08:00
@FaiChou #9 自建落地,有条件的话,在自己的 vps 上放 generate_204 或者一个小文件用于 urltest
这样速度才是到你的 relay 节点最快的,而不是到测速节点最快的
鉴于你没提你的机场是哪一家,部分无良机场会劫持 generate_204 到入口,可以考虑放点别的到 urltest ,如一个 ok.html
FaiChou
2023-09-17 11:02:05 +08:00
@totoro625 #10 绿云。。黑 5 买的三年 现在线路贼拉胯
FaiChou
2023-09-17 13:40:50 +08:00
@totoro625 #5

经过测试:

- { name: 机场测试, type: url-test, use: [机场], proxies: [], url: http://www.gstatic.com/generate_204, interval: 120, lazy: false }


这样针对机场的 url-test 不生效。

只能在 proxy-providers 中对机场打开 health-check 才行。

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://www.v2ex.com/t/974465

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX