-
-
Notifications
You must be signed in to change notification settings - Fork 2.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Feature] 关于 url-test 的巨额流量消耗 #3878
Comments
url-test的原理是http请求,设置30分钟足够了,你设置间隔一到两分钟太短了 |
主要是如果有个节点不行了,间隔时间=最大复活时间 能不能具体说说单次 url-test https://cp.cloudflare.com/generate_204 消耗的流量是多少?我把它右键另存下来,显示大小是零字节. |
generate_204就是返回http 204状态码,不会有任何实际的内容,消耗流量通常可以忽略不计,所以你消耗的流量应该不是url-test造成的 |
但是用排除法显示是由 url-test 造成,关闭各种设备和软件,流量始终都在消耗,直到将 url-test 的间隔增大一百倍,问题消失 |
试试改用http? |
部署了一个 clash-exporter,正在试图排查,感觉挺古怪的 |
经过一些测试,发现跟 meta 内核 与 url-test 都有关系,可能也与机场的计量方式有关
综合推测原因,可能是机场对小流量小连接有神奇的四舍五入反向抹零,大量的小连接会导致流量大幅多估,而 meta 内核对 url-test 的处理会造成更多的这样的小连接 我觉得这个问题还是挺严重的,每个月可能产生好几十 GB 的不存在的流量消耗,有兴趣的朋友可以测试研究一下 更新,premium 内核的 url-test 没有生效,完全不会自动检测,无论 lazy:true 还是 false |
使用Meta + Redir,proxy_groups和providers 2分钟检测一次http://www.google.com/generate_204,没有使用lazy。并没有出现类似的情况,几个机场的流量都正常。 |
Verify Steps
Describe the Feature
由于不同网站的对节点的不同需要,我设置了 7 个 url-test 的代理组,间隔在一到两分钟,目标是 https://cp.cloudflare.com/generate_204
然后我发现它们会消耗大约每小时 60-80m 的流量,一个月下来约 50-60GB,是一个巨量的损耗.
能不能科普下 url-test 的原理, 看上去不是 ping.
Describe Alternatives
可不可以让多个代理组共用同一个 url-test,节省资源
The text was updated successfully, but these errors were encountered: