[Feature] 关于 url-test 的巨额流量消耗 about openclash HOT 9 CLOSED

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

from openclash.

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

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

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

from openclash.

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

from openclash.

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

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

from openclash.

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

from openclash.

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

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

from openclash.

经过一些测试，发现跟 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

from openclash.

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

from openclash.

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

from openclash.