[Bug] 代理组为select时testUrl配置不生效

[zipfile6652]

验证步骤

• 我已经阅读了 文档，了解所有我编写的配置文件项的含义，而不是大量堆砌看似有用的选项或默认值。
• 我仔细看过 文档 并未解决问题
• 我已在 Issue Tracker 中寻找过我要提出的问题，并且没有找到
• 我是中文用户，而非其他语言用户
• 我已经使用最新的 Alpha 分支版本测试过，问题依旧存在
• 我提供了可以在本地重现该问题的服务器、客户端配置文件与流程，而不是一个脱敏的复杂客户端配置文件。
• 我提供了可用于重现我报告的错误的最简配置，而不是依赖远程服务器或者堆砌大量对于复现无用的配置等。
• 我提供了完整的日志，而不是出于对自身智力的自信而仅提供了部分认为有用的部分。
• 我直接使用 Mihomo 命令行程序重现了错误，而不是使用其他工具或脚本。

操作系统

MacOS

系统版本

all

Mihomo 版本

1.18.0到1.19.5均手动测试过，均存在这个问题，可完整复现：

配置文件

yaml
proxy-groups:
  - name: 测试
    type: select
    url: 'https://baidu.com'
    interval: 300
    proxies:
      - proxy1
      - proxy2

描述

https://wiki.metacubex.one/config/proxy-groups/#url 文档中 url 为通用字段。
但是当proxy-groups的类型为select时，url, expected-status等延迟配置不生效。
其他类型均可以生效。

重现方式

如下配置(如:fallback类型)

proxy-groups:
  - name: 测试
    type: fallback
    url: 'https://baidu.com'
    interval: 300
    proxies:
      - proxy1
      - proxy2

接口返回:

        {
            "alive": true,
            "all": [
                "proxy1",
                "proxy2",
                "DIRECT"
            ],
            "expectedStatus": "*",
            "extra": {},
            "fixed": "xxx",
            "hidden": false,
            "history": [],
            "icon": "",
            "name": "测试",
            "now": "proxy1",
            "testUrl": "https://baidu.com",  // 这里接口会返回前面配置的url字段
            "tfo": false,
            "type": "Fallback",
            "udp": true,
            "xudp": false
        },

然而，如果将type fallback 改成select, 则不返回testUrl.

proxy-groups:
  - name: 测试
    type: select
    url: 'https://baidu.com'
    interval: 300
    proxies:
      - proxy1
      - proxy2

接口返回:

        {
            "alive": true,
            "all": [
                "proxy1",
                "proxy2",
                "DIRECT"
            ],
            "expectedStatus": "*",
            "extra": {},
            "fixed": "xxx",
            "hidden": false,
            "history": [],
            "icon": "",
            "name": "测试",
            "now": "proxy1",
            // 这里接口响应里不存在testUrl字段。
            "tfo": false,
            "type": "Select",
            "udp": true,
            "xudp": false
        },

影响

无法实现独立的延迟测试。

场景：

为特定的proxy-group指定特定的延迟URL来得到更准确的延迟信息。 如仅特定子网相关的proxy-group 这种情况下testUrl为特定子网的地址会更准确

[zipfile6652]

看了一下代码似乎与这个 commit有关。
请问这个commit是为了解决什么问题特意过滤select的延迟测试配置的吗

[xishang0128]

不返回testUrl不等于不在hc

[zipfile6652]

不返回testUrl不等于不在hc

metaqube UI 等web UI都是通过这个testUrl来获取延迟测试地址延迟的， 这种情况下select类型的节点组就无法正确的测试延迟

[zipfile6652]

[xishang0128]

@zipfile6652 这只是主动测试去获取testurl传入测试,延迟查看和hc不依赖

[zipfile6652]

@xishang0128 感谢回复， 这种在UI上主动触发延迟测试去获取延迟的场景 应该如何正确配置呢？

正如issue一开始提到的， 需求是 特定的代理组配置了特定的延迟测试地址， 想要在主动触发延迟测试的时候使用前面配置的延迟测试地址来测试延迟。
而如果接口不返回testUrl的话，UI无法获取到这个代理组配置的延迟测试地址， 所以无法使用这个指定的地址来测试延迟。

[xishang0128]

@zipfile6652 建议直接url test,又不是不能fixed

[zipfile6652]

是的， url-test 甚至fallback都能用。
不过， select 的group不返回testUrl 这个与其他type不一致的行为是预期中的吗？

这个似乎没有在文档中或是代码中提示。
这样所有web UI都无法使用 select 组的独立延迟测试功能。

[zipfile6652]

select 是完全用户控制节点的选择， url-test会主动去探测选择节点，这两者的语义和场景还是有些不同的。

[xishang0128]

@zipfile6652 说了,可以fixed

[zipfile6652]

刚尝试了一下 fixed的行为与预期的“手动选择优先还是有些区别，reload后还是需要手动再次fixed选择自己想要的proxy。 而且已经fixed的节点如果遇到临时延迟高的情况下会被自动切换。 总而言之, select

提交了一个PR link 在select类型的proxy-group API返回中也返回testUrl， 测试了下面三个面版下都能达到预期的效果:

Yacd

Metacubexd

zashboard

理论上下述issue也可以得到解决：
#568
#889 (comment)

[xishang0128]

@zipfile6652 但是这会破坏原有逻辑,因为testurl默认附加,导致dashboard无法自定义测试地址

[zipfile6652]

@zipfile6652 但是这会破坏原有逻辑,因为testurl默认附加,导致dashboard无法自定义测试地址

感谢提醒， 修改了一下，仅指定了url时才返回testUrl, 否则为空时保持原有逻辑。

经过测试，三个dashboard下的自定义测试地址逻辑保持了原样。

[Jishi0]

刚尝试了一下 fixed的行为与预期的“手动选择优先还是有些区别，reload后还是需要手动再次fixed选择自己想要的proxy。 而且已经fixed的节点如果遇到临时延迟高的情况下会被自动切换。 总而言之, select

提交了一个PR link 在select类型的proxy-group API返回中也返回testUrl， 测试了下面三个面版下都能达到预期的效果:

Yacd

Metacubexd

zashboard

理论上下述issue也可以得到解决： #568 #889 (comment)

cmfa的逻辑是正常的吗？我之前测试就是type为select的代理组只有加上url字段才能正常测延迟。所以cmfa反而纠正了内核的逻辑？

[zipfile6652]

刚尝试了一下 fixed的行为与预期的“手动选择优先还是有些区别，reload后还是需要手动再次fixed选择自己想要的proxy。 而且已经fixed的节点如果遇到临时延迟高的情况下会被自动切换。 总而言之, select
提交了一个PR link 在select类型的proxy-group API返回中也返回testUrl， 测试了下面三个面版下都能达到预期的效果:
Yacd
Metacubexd
zashboard
理论上下述issue也可以得到解决： #568 #889 (comment)

cmfa的逻辑是正常的吗？我之前测试就是type为select的代理组只有加上url字段才能正常测延迟。所以cmfa反而纠正了内核的逻辑？

目前没有去关注cmfa， 不过理论上PR中的变更不会破坏CMFA的纠正。。 因为根据你的描述，CMFA可能是没有用到这个http api来获取group proxies.

web dashboard均通过这个API来获取，因此我只测试了上述几个web dashboard

[Jishi0]

刚尝试了一下 fixed的行为与预期的“手动选择优先还是有些区别，reload后还是需要手动再次fixed选择自己想要的proxy。 而且已经fixed的节点如果遇到临时延迟高的情况下会被自动切换。 总而言之, select
提交了一个PR link 在select类型的proxy-group API返回中也返回testUrl， 测试了下面三个面版下都能达到预期的效果:
Yacd
Metacubexd
zashboard
理论上下述issue也可以得到解决： #568 #889 (comment)

cmfa的逻辑是正常的吗？我之前测试就是type为select的代理组只有加上url字段才能正常测延迟。所以cmfa反而纠正了内核的逻辑？

目前没有去关注cmfa， 不过理论上PR中的变更不会破坏CMFA的纠正。。 因为根据你的描述，CMFA可能是没有用到这个http api来获取group proxies.

web dashboard均通过这个API来获取，因此我只测试了上述几个web dashboard

好的，感谢回答。