MetaCubeX
[Feature] 关于 proxy-group 中引入 proxy-provider 的测速问题
验证步骤
- [x] 我已经阅读了 文档，确认了该功能没有实现
- [x] 我已在 Issue Tracker 中寻找过我要提出的功能请求，并且没有找到
- [x] 我是中文用户，而非其他语言用户
描述
官方文档中对于proxy-group的url的介绍：
只会检查代理组的 proxies 字段的代理，不会检查代理集合（proxy-providers）的代理（通过 use 引入的）。
这是不是意味着，如果有一个proxy-group使用了某个proxy-provider，如：
proxy-groups:
- name: "AUTO"
type: url-test
use:
- a-provider
- b-provider
url: https://cp.cloudflare.com
interval: 300
tolerance: 20
lazy: false
hidden: false
那么当 AUTO 组节点失效时，无法触发主动测速，因为这里配置的url实际不生效，只能等待 proxy-provider 中配置的health-check触发才会切换节点。
另外一种可能的使用场景是，对于同一个 proxy-provider，可能希望根据不同 proxy-group 设置不同的测速地址。比如有一个香港的代理组和一个日本的代理组，引入了同一个代理集合，想要分别使用香港和日本的落地测速链接。
可能的优化方式：proxy-group 中的 url 也对使用 use 引入的节点生效，可以在代理组节点失效时触发主动测速，对引入的代理集合也进行测速。这样可以移除 proxy-provider 的 health-check配置。
暂时的办法是把机场下发的proxies:字段复制一套粘贴进config最下面 然后把use改成include-all-proxies: true ，再自行写filter过滤之类的。 如果机场订阅需要经常更新的当我没说😳
我的订阅比较多, 合并拆分规则比较复杂. 没法用include-all-proxies: true , 希望团队能优化让use的引入也能高可用,自动测试
我的订阅比较多, 合并拆分规则比较复杂. 没法用include-all-proxies: true , 希望团队能优化让use的引入也能高可用,自动测试
include-all后，可以同时使用 filter 和 exclude-filter，比如先粗略筛选，再精细排除，都支持正则，可操作空间还是挺大的，我是这么用的，主要从多个订阅里筛选同地区的代理，然后按分流的需求，再从属于同地区的里面，排除某些质量不是那么好的订阅里内容。 另外，它还支持筛选从 proxy-provider 里面添加进去的前缀、后缀。比如你可以给每个订阅的proxy都添加一个唯一的标识，然后在筛选的时候用。 不过这东西，看需求场景吧。
我的订阅比较多, 合并拆分规则比较复杂. 没法用include-all-proxies: true , 希望团队能优化让use的引入也能高可用,自动测试
include-all后，可以同时使用 filter 和 exclude-filter，比如先粗略筛选，再精细排除，都支持正则，可操作空间还是挺大的，我是这么用的，主要从多个订阅里筛选同地区的代理，然后按分流的需求，再从属于同地区的里面，排除某些质量不是那么好的订阅里内容。 另外，它还支持筛选从 proxy-provider 里面添加进去的前缀、后缀。比如你可以给每个订阅的proxy都添加一个唯一的标识，然后在筛选的时候用。 不过这东西，看需求场景吧。
你能解决自己的需求,很厉害. 对于普通人还是太复杂, 交叉引用后面加减都麻烦. 很多人不需要这么多分类,只是想直观和高可用.
如果优化让use引入的组也能测速,就少了这些麻烦. 如果担心多次use后, 测速太多,这里面应该也可以在代码里优化(如果可行)
我的订阅比较多, 合并拆分规则比较复杂. 没法用include-all-proxies: true , 希望团队能优化让use的引入也能高可用,自动测试
include-all后，可以同时使用 filter 和 exclude-filter，比如先粗略筛选，再精细排除，都支持正则，可操作空间还是挺大的，我是这么用的，主要从多个订阅里筛选同地区的代理，然后按分流的需求，再从属于同地区的里面，排除某些质量不是那么好的订阅里内容。 另外，它还支持筛选从 proxy-provider 里面添加进去的前缀、后缀。比如你可以给每个订阅的proxy都添加一个唯一的标识，然后在筛选的时候用。 不过这东西，看需求场景吧。
你能解决自己的需求,很厉害. 对于普通人还是太复杂, 交叉引用后面加减都麻烦. 很多人不需要这么多分类,只是想直观和高可用.
如果优化让use引入的组也能测速,就少了这些麻烦. 如果担心多次use后, 测速太多,这里面应该也可以在代码里优化(如果可行)
那倒是，从组里面根据用途和类型去设置检查的参数确实更直接。现在应该是从provider引入的都不支持，use和include都不行，只能依赖provider的健康检查和手动点界面上的按钮。
文档可能没有及时更新吧，源码显示 proxy-group 的 url 和 use 里的 provider url 不一样的话会对 provider里的节点 追加一次检查。
文档可能没有及时更新吧，源码显示 proxy-group 的 url 和 use 里的 provider url 不一样的话会对 provider里的节点 追加一次检查。
我测试把rule provider的health check关闭的话，在proxy-groups/url-test类型的分组中通过use引入的节点并不会被测延迟
文档可能没有及时更新吧，源码显示 proxy-group 的 url 和 use 里的 provider url 不一样的话会对 provider里的节点 追加一次检查。
如果 url和interval 在rule provider和proxy-groups/url-test都一样呢？最终实现什么效果？
这两个功能看似重复，推荐的用法是怎样的呢？
我测试把rule provider的health check关闭的话，在proxy-groups/url-test类型的分组中通过use引入的节点并不会被测延迟
是 proxy provider的health check关闭吧？即使关闭了 在proxy-groups/url-test类型 时会强行测。
如果 url和interval 在rule provider和proxy-groups/url-test都一样呢？最终实现什么效果？
在测延迟方面 可能前者是后者的缺省配置。
测速地址一样的话 第二次的会忽略，不一样会测2次 2次结果都保留 作用未知 没有特定场景应该没必要配置成不一样的。
如果 url和interval 在rule provider和proxy-groups/url-test都一样呢？最终实现什么效果？
在测延迟方面 可能前者是后者的缺省配置。
测速地址一样的话 第二次的会忽略，不一样会测2次 2次结果都保留 作用未知 没有特定场景应该没必要配置成不一样的。
一个是url不一样， 还有就是interval不一样时会如何生效，是不是推荐的做法就是两边的url和interval都保持一致？
url 不一样 会造成多次测速 测试结果是以url为key的json保存的；interval等其他参数各管各的；url-test 重新测试触发条件是 max-failed-times: 默认 5，这时不管 proxy provider的health check关闭与否，包含的所有节点都会测；proxy provider的health check 开启的话 会定时循环测试自身节点。
如果节点多 尽量少测试，当然就是只用同一个url测。节点少，随便测。
url 不一样 会造成多次测速 测试结果是以url为key的json保存的；interval等其他参数各管各的；url-test 重新测试触发条件是 max-failed-times: 默认 5，这时不管 proxy provider的health check关闭与否，包含的所有节点都会测；proxy provider的health check 开启的话 会定时循环测试自身节点。
如果节点多 尽量少测试，当然就是只用同一个url测。节点少，随便测。
#1298 ，意思是说，groups 也会对组内的所有节点检查，不管是不是provider引入的。那出现 #1758 应该不会出现了呀，我和他情况一样，手动点击整个 group 的 health-check 也不会切换。interval时间到了也不切换。只能重载。是问题没被修复（或者不需要修复），是我没用对，有好的解决方案没
那出现 #1758 应该不会出现了呀，我和他情况一样，手动点击整个 group 的 health-check 也不会切换。interval时间到了也不切换。
所以你的结论并不正确。那个issues里我就回复了一个情形：节点过多，测速要很久（比如你当前用的上次测速最快的节点最后才测速到，程序还是在很长时间内以为他是当前延迟最低的可用节点）。另外是否切换不要以面板代理界面为准，它可能不及时刷新。
最近也出现了类似的问题, 3个provider, 组分2级, 1级从provider按地区筛选,采用url-test. 二级引用1级组. 每次刷新配置的时候, 1级组都有5~10秒的compatible状态, 导致二级组初始化的时候就会出现误判或者直接超时. 可能原因是, 刷新配置的时候,要重新下载provider, 然后把所有节点都测试完一遍, 1级组内才显示出来可用节点.
然后把那些组改成select, 手动选择一次,再改回去. 它就不用等了 , 但是就出现了即使检查也不会再切换的问题. 可能跟缓存选择的配置有关, 组类型改变之后,还在缓存着. 但重启内核后可能会恢复.
如果直接下载回来,筛选一下,应该是不用那么久的.
感觉这个健康检查的问题, 可能优化成就组内的检测支持引用的节点才是比较好的办法. 统一且符合直觉, 减少干扰因素.
另外,想问下那个lazy:true,说的被选中才测指的是被哪里选中.