完全引用provider的url-test组,每次更新配置的时候,都会有几秒钟的COMPATIBLE状态, 要全部健康检查完成选出节点后该组才会可用,导致引用了这些组的上层组出现不符合预期的健康检查结果和出站行为。 #578
Replies: 1 comment
-
发现了这个问题的一个有趣现象, 把url-test类型的组,改成 select, 然后在界面上点选过一次(必须点选过), 之后再改回url-test, 之后再刷新配置的时候就不会有几秒钟的 compatible了, 会缓存更新之前的状态. |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
例如,有provider1,provider2,启用健康检测。
组配置如下(由于纯引用proveder的组,延迟测试只能依赖于provider的检查结果,自身配置无效,所以省略相关配置):
在刷新配置时,可能由于系统的初始化时所有的proxy是同时开始健康检查的,会导致在“fallback”组开始检查时,“hk” 和 “us”由于还没有筛选出节点,处于COMPATIBLE状态,此时如果该组使用的是一个直连不可达的测试URL,就会导致结果全部为timeout,或者可能最后一个proxy 需要筛选的节点更少,更快筛选出结果,而前面两个不可用而该组被跳到了不那么希望被使用的bak组。 这时候除了手工干预,就只能等interval的下一轮测试了。
但实际上前面两个并不是不可用,只是在该组开始测试时,被引用的组还没反应过来,于是出现了不符合预期的结果。
除上面说的问题之外,这种临时被置为直连的状态,在某些极端的情况下,可能还会使得某些APP被检测为异常位置而受到影响(猜测)。
我尝试在 urltest组中,加入一个rejeck的proxy,这虽然可以阻止使用该组的流量异常出站,但是影响不了第一轮的检查结果,这样会导致在第一轮检测时全部被跳过。
不知道这个初始化过程是否可以加入更合理的优先级逻辑,比如groups的检查,等待proxy provider跑完之后再开始,COMPATIBLE的行为不要定位为直连? 或者group里面可以自己设置一个“等待时间”的参数、可以设置处于COMPATIBLE状态时的默认行为。
或者group在开始检查时,如果有某个proxy指向COMPATIBLE则自动等待?
现有的功能里有没有其他的方式可以绕过这个问题呢?除了proxy全部手写之外。
Beta Was this translation helpful? Give feedback.
All reactions