MetaCubeX
[Bug] 关于`health-check`的问题
Verify steps
- [X] 我已经阅读了 文档，了解所有我编写的配置文件项的含义，而不是大量堆砌看似有用的选项或默认值。
- [ ] 我未仔细看过 文档 并解决问题
- [ ] 我未在 Issue Tracker 中寻找过我要提出的问题
- [X] 我已经使用最新的 Alpha 分支版本测试过，问题依旧存在
- [X] 我提供了可以在本地重现该问题的服务器、客户端配置文件与流程，而不是一个脱敏的复杂客户端配置文件。
- [X] 我提供了可用于重现我报告的错误的最简配置，而不是依赖远程服务器、TUN、图形界面客户端或者其他闭源软件。
- [X] 我提供了完整的配置文件与日志，而不是出于对自身智力的自信而仅提供了部分认为有用的部分。
操作系统
MacOS, Windows, Linux, Android
系统版本
openwrt23 windows11 ubuntu24 android14 macos14
Mihomo 版本
版本太多了，已经用了两年了，有问题一直存在 可以保证使用的版本是新于等于Release中的v1.xx.x版本 每个正式Release保证更新，有时会更新Prerelease-Alpha 比如现在用的是 846bdfa
配置文件
0: &0 {interval: 256, lazy: true, tolerance: 128}
1: &1 {health-check: {<<: *0, enable: false}, interval: 65536, type: http}
proxy-providers:
z: {<<: *1, url: }
proxy-groups:
- {<<: *0, name: 手, type: select, include-all: true}
- {<<: *0, name: 代, type: select, proxies: [F1]}
- {<<: *0, name: F1, type: fallback, proxies: [手, F2]}
- {<<: *0, name: F2, type: fallback, proxies: [手, F3], url: 'https://www.msftconnecttest.com/connecttest.txt'}
- {<<: *0, name: F3, type: fallback, proxies: [手, U1, U2, U3, DIRECT], url: 'https://www.apple.com/library/test/success.html'}
- {<<: *0, name: U1, type: url-test, include-all: true, filter: 地区1}
- {<<: *0, name: U2, type: url-test, include-all: true, filter: 地区2}
- {<<: *0, name: U3, type: url-test, include-all: true, filter: 地区3}
rules:
- MATCH,代
描述
确定是内核问题，非拉起内核的客户端的问题
所有问题只使用proxy-providers未在运行配置内手动填写proxies，运行配置内含proxies:或影响复现
问题一
当 mihomo 的lazy: true生效后，再稳定运行超过三天，url-test就会失效
此时即使所有组中已被选中的节点失效alive: false, delay: 65535 ms，fallback划到DIRECT1小时也不会激活url-test的health-check去选择一个未失效的节点
该问题是先在openwrt中发现的，然后经windows、ubuntu和mac复核
问题二（有可能需要结合问题一）
多个自动组套用时，节点的max-failed-times切换会异常
我在interval: 99999的情况下尝试max-failed-times: 1，结果max-failed-times失效，仍需要等interval: 99999去切换节点更不要说默认的max-failed-times: 5了
问题三（这个问题是这两年一直存在的）
当proxy-providers的health-check: {enable: false}时
url-test的节点只会选择第一个，无论该节点是否可用延迟如何
只能靠health-check: {enable: true}来解决，所以会带来
1filter只筛选了四个地区不到二十个节点，但完整的proxy-provider有三个订阅超过二百个节点，所以有些浪费资源
2我直接引用其他人发的吧
由于不同网站的对节点的不同需要，我设置了 7 个 url-test 的代理组，间隔在一到两分钟，然后我发现它们会消耗大约每小时 60-80m 的流量，一个月下来约 50-60GB，是一个巨量的损耗 https://github.com/vernesong/OpenClash/issues/3878
我也有类似情况，测试问题一时发现的，确定是health-check导致的，但没如此严重
重现方式
描述
日志
No response
首先感谢开发者回复 不过还是有问题存在，见谅
1,lazy为true时,被选择才会进行检测 2,同1
我的配置文件再写明白点就等于如下内容
- {name: fallback1, proxies: [select, fallback2]}
- {name: fallback2, proxies: [select, url-test1, url-test2, url-test3, DIRECT]}
同样有lazy: true，fallback1能被激活去选择fallback2，fallback2能被激活去选择DIRECT，可中间的3个url-test却无法被激活
max-failed-time是被自动组fallback选中的，没有激活
另外，我上文写的是稳定运行超过三天，但实际一天左右也会出现该情况，不过大概率被“救回来”，即fallback选择到DIRECT后能激活max-failed-time进行hc，或是经过几轮interval激活url-test去选择一个能连通的节点，之后fallback会切回到url-test上
一天亦足够lazy: true完全生效，能被“救回来”。而三天就不行fallback划到DIRECT1小时，url-test也没有恢复正常工作
3,属于provider的节点只会被provider hc,不会被groups hc
该问题看来是属于特意设计的，那就算了。虽然有点不理解。
我这边的情况是节点hc大概130个后的延迟数据就会变的极度不稳定，浮动能达到500ms。调整节点顺序后后测的同样会波动，未达到设备瓶颈，机场也不清楚。加上我本身用到的节点也不多，所以现在把无需自动hc的节点限制了
proxy-providers:
z1: {url: xxx, health-check: {enable: true }, filter: "地区1|地区2|地区3..."}
z2: {url: xxx, health-check: {enable: false}, exclude-filter: "地区1|地区2|地区3..."}
首先感谢开发者回复 不过还是有问题存在，见谅
1,lazy为true时,被选择才会进行检测 2,同1
我的配置文件再写明白点就等于如下内容
- {name: fallback1, proxies: [select, fallback2]} - {name: fallback2, proxies: [select, url-test1, url-test2, url-test3, DIRECT]}同样有
lazy: true，fallback1能被激活去选择fallback2，fallback2能被激活去选择DIRECT，可中间的3个url-test却无法被激活
max-failed-time是被自动组fallback选中的，没有激活另外，我上文写的是稳定运行超过三天，但实际一天左右也会出现该情况，不过大概率被“救回来”，即
fallback选择到DIRECT后能激活max-failed-time进行hc，或是经过几轮interval激活url-test去选择一个能连通的节点，之后fallback会切回到url-test上 一天亦足够lazy: true完全生效，能被“救回来”。而三天就不行fallback划到DIRECT1小时，url-test也没有恢复正常工作3,属于provider的节点只会被provider hc,不会被groups hc
该问题看来是属于特意设计的，那就算了。虽然有点不理解。
我这边的情况是节点hc大概130个后的延迟数据就会变的极度不稳定，浮动能达到500ms。调整节点顺序后后测的同样会波动，未达到设备瓶颈，机场也不清楚。加上我本身用到的节点也不多，所以现在把无需自动hc的节点限制了
proxy-providers: z1: {url: xxx, health-check: {enable: true }, filter: "地区1|地区2|地区3..."} z2: {url: xxx, health-check: {enable: false}, exclude-filter: "地区1|地区2|地区3..."}
lazy: false请,没写lazy就是true,没被选择就不会hc
lazy: false请,没写lazy就是true,没被选择就不会hc
不好意思，是我的错，没让你理解
麻烦简单直接的为我说明下
简单列了以下5个，最终选择的测试节点都是由url-test决定的
在确定lazy: true已经激活后，手动让测试节点出现故障无法连通，访问google以启用对应的节点链，哪一个或几个url-test可以在测试节点出现故障时激活hc并更换为一个未故障的节点
也就是说哪一个或几个是你所说的被选择状态
DOMAIN-SUFFIX,google.com→select→url-test→测试节点
DOMAIN-SUFFIX,google.com→fallback→url-test→测试节点
DOMAIN-SUFFIX,google.com→select→fallback→select→url-test→测试节点
DOMAIN-SUFFIX,google.com→select→fallback→select→fallback→url-test→测试节点
DOMAIN-SUFFIX,google.com→select→fallback→fallback→fallback→url-test→测试节点
希望能看完上方内容并做出选择后再展开
我提供配置文件的测试结果可以说明第五个不是
第三、四个在不操作第二个select的时候也是有问题的
第二个会莫名其妙的触发max-failed-time，以致不是在hc，就是在准备hc的路上
所以这是自动组嵌套的问题还是特意设计的
另外再说声不好意思，因为个人原因，至少三个月无法登github，所以该issue可以被关闭或删除
感谢你的回复 谢谢
@LittleRey 不会
proxy-group 不会主动检测 proxy-provider 提供的节点，而是依赖 proxy-provider 的健康检查结果，但是这样设计岂不是url-test直接这个group直接成了摆设了么，url-test根本没法进行自动选择
现在我想要url-test进行自动选择，应该怎么做 @xishang0128
lazy: false请,没写lazy就是true,没被选择就不会hc
不好意思，是我的错，没让你理解 麻烦简单直接的为我说明下 简单列了以下5个，最终选择的测试节点都是由
url-test决定的 在确定lazy: true已经激活后，手动让测试节点出现故障无法连通，访问google以启用对应的节点链，哪一个或几个url-test可以在测试节点出现故障时激活hc并更换为一个未故障的节点 也就是说哪一个或几个是你所说的被选择状态DOMAIN-SUFFIX,google.com→select→url-test→测试节点DOMAIN-SUFFIX,google.com→fallback→url-test→测试节点DOMAIN-SUFFIX,google.com→select→fallback→select→url-test→测试节点DOMAIN-SUFFIX,google.com→select→fallback→select→fallback→url-test→测试节点DOMAIN-SUFFIX,google.com→select→fallback→fallback→fallback→url-test→测试节点
您好，请问这个自动测试组嵌套的代理组无法自动测速的问题解决了么，我的使用情况也类似，手动选择→fallback组→三个select组+两个loadbalance组+最终的url-test组
其中select组直接指向节点，loadbalance组是筛选节点再负载均衡使用，而url-test组下是以国家/地区代码筛选的loadbalance组
我现在是给fallback组和url-test组都设置了lazy: false，但还是会偶尔有莫名其妙fallback到了最后的url-test组
我在想loadbalance组是否也要禁用掉lazy才能正常测试fallback里每一项的延迟，lazy默认是开启的，难道选中的代理组全链路里只要有一个没有关掉lazy，那么这条链就会受影响么
