[Feature Request] Outbound status observability and manually choosing

[jwfang]

problem when use xray-core as client side proxy:

• usually remote outbounds are not stable
• user often have multiple outbounds

user needs some way to know about outbounds status as well as choose outbound manually, especially during outbounds outage.

currently we have balancer with automatically chosen outbound, but lack outbound status display and manually choosing outbound.

[RPRX]

不会支持 Clash API，因为其它支持的软件也并没有取代了 Mihomo 成为 Clash UI 的默认内核

但是你提的功能可以有，还有每个连接的状态啥的，早就想做了，只是目前重点不在这块

[jwfang]

不会支持 Clash API，因为其它支持的软件也并没有取代了 Mihomo 成为 Clash UI 的默认内核

没太懂这个取代mihomo成为默认内核，可能我前面没有说清楚。
我建议支持Clash API的原因是，Clash API刚好满足了状态监控和手工选择的需求，而且dashboard有很多现成的可以使用。

不过如果能支持状态查看和手工选择，也不是一定是要通过Clash API来实现。

PS：这两个功能也是我至今仍然使用clash族作为客户端代理的原因。

[Fangliding]

写一个selector出站很简单 观测连接也很简单 但是有几个问题
一是核心已经有一个连接观测了 尽管它很难用 再做一个功能重复删了又好像不是很对
二是selector需要一个api 核心里API都是grpc api 这玩意看到就头疼

[Meo597]

目前的破烂完全能满足故障转移需求
探测频率搞快点无缝丝滑迁移

[Meo597]

现在的连接观测，如果想要灵敏就必须频繁探测
而太频繁的探测，即便用了 burstObs 都掩盖不了特征

最终的结果就是故障恢复和转移“反应迟钝”
体感就是，节点故障，一堆网站打不开，还在慢吞吞等探测

如果能跟出站联动一下就好了
这样能快速标记故障、恢复

比如 dial 超时就触发一次探测 or 单位时间内 dial 超时 n 次直接标记为故障

[eliotcougar]

如果能跟出站联动一下就好了
这样能快速标记故障、恢复

Exactly. As long as there are no connection resets/timeouts happening, and the data is flowing through the current outbound, there is no need to probe all the outbounds. Don't act unless there is a connection problem.
It may also be beneficial to probe the local gateway first to see if there is a connection at all.