-
Notifications
You must be signed in to change notification settings - Fork 3.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
关于balancers中leastping与leastload在(burst)observatory下不导通时的自动切换策略 #3186
Comments
Have you tried making another balancer with the same outbounds but with roundRobin strategy and then using this balancer as the fallback? Would this help achieve what you want to do? Google translate may have butchered your real intention, I'm not sure. |
roundRobin使用起来没什么问题,比如global-out策略组的第一个出口节点是死的,那么会顺序向其他出口节点发出请求 |
I mean something like this, Im still not sure if this is what you meant because of google translate if this is not the case I won't comment anymore then.
|
据我所知,random和roundRobin并不需要配置burstObservatory字段,只有leastping和leastload需要配置observatory或burstObservatory。我尝试了如下配置。 |
"balancers": [
{
"tag": "global-balancers-leastload",
"selector": ["global-out"],
"strategy": {
"type": "leastLoad"
},
"fallbackTag": "global-balancers-roundrobin"
},
{
"tag": "global-balancers-roundrobin",
"selector": ["global-out"],
"strategy": {
"type": "roundRobin"
}
},
{
"tag": "cn-balancers-leastload",
"selector": ["cn-out"],
"strategy": {
"type": "leastLoad"
},
"fallbackTag": "cn-balancers-roundrobin"
},
{
"tag": "cn-balancers-roundrobin",
"selector": ["cn-out"],
"strategy": {
"type": "roundRobin"
}
}
],
"burstObservatory": {
"subjectSelector": ["global-out", "cn-out"],
"pingConfig": {
"destination": "http://www.apple.com/library/test/success.html",
"interval": "3m",
"connectivity": "http://connectivitycheck.platform.hicloud.com/generate_204",
"timeout": "10s",
"sampling": 2
}
}
|
Added fallback for all balancers. Closing for now. |
尊敬的开发者您好。
客户端配置如下:
"balancers": [{
"tag": "global-balancers",
"selector": ["global-out"],
"strategy": {
"type": "leastLoad"
},
"fallbackTag": "global-out0"
}, {
"tag": "cn-balancers",
"selector": ["cn-out"],
"strategy": {
"type": "leastLoad"
},
"fallbackTag": "cn-out0"
}]
},
"burstObservatory": {
"subjectSelector": ["global-out", "cn-out", "global-udp-out"],
"pingConfig": {
"destination": "http://www.apple.com/library/test/success.html",
"interval": "1h",
"connectivity": "http://connectivitycheck.platform.hicloud.com/generate_204",
"timeout": "10s",
"sampling": 2
问题:leastPing与leastLoad策略在启动xray时,如果(burst)observatory观测连接未能探测成功,此时出站全部走"fallbackTag": "global-out0",但恰巧"global-out0"这个节点是死的,就会导致在下一个"interval": "1h"探测周期到来之前一直连接这个死节点,无法正常访问网络。
请问可否增加一个机制,在leastPing和leastLoad策略下,如果当前"interval"周期未能成功(burst)observatory,则此次"interval"观测连接周期执行类似roundRobin策略,在策略组中轮到可用的节点后,出站节点固定使用当前节点。
等到下一个观测连接周期到来再重新执行leastPing或leastLoad的观测连接优选。
尤其是leastPing,配置似乎没有规定fallback的地方。我发现如果observatory不通的情况下路由配置直接不管用了,默认所有流量走outbounds配置里的第一个节点。但第一个节点还是死的,就直接全部没网了😭
我遇到这个情况的场景:安卓手机使用xray模块(最新的xray core),然后WiFi端配置了类似软路由的功能。在WiFi情况下启动手机xray模块,选择放行WiFi。关掉WiFi切回数据的时候出现了以上情况。经过多次测试更改balancers配置时发现的这个问题。
The text was updated successfully, but these errors were encountered: