[Feature] 关于 url-test 的巨额流量消耗

[LakeishaKowalczyk]

Verify Steps

• [X] Tracker 我已经在 Issue Tracker 中找过我要提出的问题
• [X] Latest 我已经使用最新 Dev 版本查看过，并不包含该功能特性或者还不完善
• [X] Relevant 我知道 OpenClash 与 内核(Core)、控制面板(Dashboard)、在线订阅转换(Subconverter)等项目之间无直接关系，仅相互调用
• [X] Definite 这确实是 OpenClash 应包含的特性
• [X] Contributors 我有能力协助 OpenClash 开发或完善此功能特性
• [X] Meaningless 我提交的是无意义的催促更新或修复请求

Describe the Feature

由于不同网站的对节点的不同需要，我设置了 7 个 url-test 的代理组，间隔在一到两分钟，目标是 https://cp.cloudflare.com/generate_204 然后我发现它们会消耗大约每小时 60-80m 的流量，一个月下来约 50-60GB，是一个巨量的损耗．

能不能科普下 url-test 的原理， 看上去不是 ping．

Describe Alternatives

可不可以让多个代理组共用同一个 url-test，节省资源

[PKC278]

url-test的原理是http请求，设置30分钟足够了，你设置间隔一到两分钟太短了

[LakeishaKowalczyk]

url-test的原理是http请求，设置30分钟足够了，你设置间隔一到两分钟太短了

主要是如果有个节点不行了，间隔时间=最大复活时间

能不能具体说说单次 url-test https://cp.cloudflare.com/generate_204 消耗的流量是多少？我把它右键另存下来，显示大小是零字节．

[PKC278]

generate_204就是返回http 204状态码，不会有任何实际的内容，消耗流量通常可以忽略不计，所以你消耗的流量应该不是url-test造成的

[LakeishaKowalczyk]

generate_204就是返回http 204状态码，不会有任何实际的内容，消耗流量通常可以忽略不计，所以你消耗的流量应该不是url-test造成的

但是用排除法显示是由 url-test 造成，关闭各种设备和软件，流量始终都在消耗，直到将 url-test 的间隔增大一百倍，问题消失

[xrh0905]

试试改用http? https协议栈还是占流量的

[LakeishaKowalczyk]

试试改用http? https协议栈还是占流量的

部署了一个 clash-exporter，正在试图排查，感觉挺古怪的

[LakeishaKowalczyk]

经过一些测试，发现跟 meta 内核 与 url-test 都有关系，可能也与机场的计量方式有关

1. 只有较多地使用 url-test 并且使用 meta 内核才会出现这个流量损耗，premium 内核没有这个问题 （模式切换分别是 meta + fakeip + 增强模式，premium + fakeip + tun模式）
2. OpenClash 自带的 clash 面板统计不到这个流量，只会出现在机场的计费当中
3. 测试机场计费，发现机场对单个大文件下载的计量比较准确，误差 1%．但对长时间的刷网页等计费误差可能高达 10% 或更高

综合推测原因，可能是机场对小流量小连接有神奇的四舍五入反向抹零，大量的小连接会导致流量大幅多估，而 meta 内核对 url-test 的处理会造成更多的这样的小连接

我觉得这个问题还是挺严重的，每个月可能产生好几十 GB 的不存在的流量消耗，有兴趣的朋友可以测试研究一下

更新，premium 内核的 url-test 没有生效，完全不会自动检测，无论 lazy:true 还是 false

[CrazyShipOne]

使用Meta + Redir，proxy_groups和providers 2分钟检测一次http://www.google.com/generate_204，没有使用lazy。并没有出现类似的情况，几个机场的流量都正常。

[github-actions[bot]]

This issue is stale because it has been open 60 days with no activity. Remove stale label or comment or this will be closed in 5 days