手动对 providers 类型测速后触发 providers 下方附属节点在 UI 界面上的高延迟/假掉线 BUG [复现]

[curtisrecords]

在尝试手动测速后发现网页

• 第一次请求：https://clashbackend.api/group/GroupName/delay?url=https%3A%2F%2Fwww.gstatic.com%2Fgenerate_204&timeout=5000

• 第二次请求：https://clashbackend.api/providers/proxies

• 第三次请求：https://clashbackend.api/proxies

第二次请求 providers/proxies 后节点会正常返回相关延迟，第三次网页调用请求了 /proxies 后节点出现大批量的假超时状态。

1. 以测速 Group 为例 [GroupName] 程序调用了下方三个API地址

第一个请求：https://clashbackend.api/group/GroupName/delay?url=https%3A%2F%2Fwww.gstatic.com%2Fgenerate_204&timeout=5000
> 第一个API返回
{
    "TUNNEL1": 302,
    "TUNNEL2": 218,
    "TUNNEL3": 1362,
    "TUNNEL4": 1343,
    "TUNNEL5": 230,
    "TUNNEL6": 365,
    "TUNNEL7": 313,
    "TUNNEL8": 226,
    "TUNNEL9": 825
}

第二个请求：https://clashbackend.api/providers/
{
    providers策略组延迟 TLDR
}

第三个请求：https://clashbackend.api/proxies
{
    providers策略组内所有节点的延迟 TLDR
}

出现问题的步骤是
第一个API就已经返回了 group 内所有节点的延迟，第二 第三个请求可能是不必要的 此外 对应后端API的 /proxies 路径可能是造成节点大批假掉线的原因；控制台屏蔽了这个路径请求后 UI的测速行为以及节点显示回归正常了。

补充：UI行为似乎和 unified-delay: true 该配置行无关。

[ClarkQAQ]

感觉和 #475 是一样的问题, 不过我这边在清空 测试 IPv6 支持链接 后一切正常了, 我试过在 VPS 上都无法访问 https://api-ipv6.ip.sb/ip 这个地址...

[curtisrecords]

感觉和 #475 是一样的问题, 不过我这边在清空 测试 IPv6 支持链接 后一切正常了, 我试过在 VPS 上都无法访问 https://api-ipv6.ip.sb/ip 这个地址...

我这边在清除ipv6测试链接后同样复现 刚开始我也以为是ipv6的问题.. 似乎在20版本后就一直存在这个问题 而且使用metacubexd 节点假死的时候会触发多个策略的fallback策略组直到最后一个纯保底的规则
目前内网自建了yacd 暂时没遇到和xd一样的问题。