Balancer with leastPing strategy routes to direct for the 1st interval duration.

[pulsarice]

I have 3 reverse (portal) tunnels to my server and I use a balancer to choose the reverse tunnel with the least ping. when xray starts, the first observatory probe fails immediately and all routing rules with a balancertag go to the first outbound (direct). I've set the interval to 5s. 5 seconds after xray has started, the second probe succeeds and now my balancertag actually routes traffic based on selector object and will not use direct. to mitigate this problem I've added this before the direct outbound:

  {
    "tag": "proxy",
    "protocol": "freedom",
    "proxySettings": {
      "tag": "portal-1"
    }
  },
  {
    "tag": "direct",
    "protocol": "freedom"
  }, ...

Now for the first 5 seconds, my packets won't go to direct, but will use portal-1

Do you have a better workaround?

[us254]

"routing": {
    "balancers": [
      {
        "tag": "balancer",
        "selector": [
          "proxy1",
          "proxy2",
          "proxy3"
        ],
        "strategy": {
          "type": "leastPing"
        },
        "fallbackTag": "proxy1" // Set the fallbackTag to one of your outbound tags
      }
    ],
    "rules": [
      {
        "type": "field",
        "balancerTag": "balancer",
        "network": "tcp,udp"
      }
    ]
  }

By setting the fallbackTag to proxy1, when the initial Observatory probe fails, the balancer will fallback to using the proxy1 outbound instead of the direct outbound. This way, your traffic will still go through one of your reverse tunnels during the initial startup period.

The fallbackTag option is designed to handle situations where the balancer cannot select an outbound based on the configured strategy (e.g., when there are no valid outbounds or when the initial probe fails). Instead of falling back to the direct outbound, which might not be desirable, you can specify a fallback outbound tag that aligns with your requirements.

This approach should provide a cleaner solution than adding an extra proxy outbound solely for the initial startup period.

[pulsarice]

Thank you. I didn't know about fallbackTag as there is no configuration documentation about it. Now I searched for fallbackTag in xray code. It seems that there are two places that I can use it.

type Balancer struct {
	selectors   []string
	strategy    BalancingStrategy
	ohm         outbound.Manager
	fallbackTag string

	override override
}


type BalancingRule struct {
	Tag         string         `json:"tag"`
	Selectors   StringList     `json:"selector"`
	Strategy    StrategyConfig `json:"strategy"`
	FallbackTag string         `json:"fallbackTag"`
}

One is in the balancer object and the other is in the routing rules. Is it correct?

[pulsarice]

I tried it, but it seems that it's not working my balancer config:

    "balancers": [
      {
        "tag": "balancer",
        "selector": [
          "portal"
        ],
        "strategy": {
          "type": "leastPing"
        },
        "fallbackTag": "portal-1nl"
      },

My routing rule

      {
        "type": "field",
        "inboundTag": [
          "inbound-443",....
        ],
        "balancerTag": "balancer",
        "fallbackTag": "portal-1nl"
      },

my access log right after xray start:

accepted tcp:g.whatsapp.net:5222 [inbound-443 >> proxy] email:
accepted udp:154.57.32.156:4057 [inbound-443 >> proxy] email:
accepted tcp:defra2.icloud-content.com:443 [inbound-443 >> proxy] email:
accepted udp:154.57.32.156:4057 [inbound-443 >> proxy] email:
accepted udp:154.57.32.156:4057 [inbound-443 >> proxy] email:
accepted tcp:52.149.21.60:443 [inbound-443 >> proxy] email:

when observatory pings are successful, it will switch from 1st freedom (proxy) to the specified portals in balancer object.

[yuhan6665]

Fixed in main. Still recommend you to have a fallbacktag setting

[pulsarice]

I still have this problem on v1.8.9. Any thoughts?

[pulsarice]

Ok. It seems to be fixed on v1.8.10. thanks