X-UI负载均衡器与观测器配置问题解析

在X-UI面板1.8.4版本中，用户发现当创建使用leastLoad或leastPing策略的负载均衡器时，系统自动生成的观测器配置存在一个关键问题。这个问题会导致负载均衡功能无法按预期工作，所有流量都会被路由到默认的第一个出站代理（通常是direct）。

问题本质

问题的核心在于观测器（Observatory/BurstObservatory）的subjectSelector配置错误。在正确实现中，这个选择器应该包含负载均衡器所管理的所有出站代理标签列表。然而当前实现却错误地使用了负载均衡器自身的标签作为选择器。

举例来说，当用户创建一个名为"test"的负载均衡器，并为其分配了两个出站代理"proxy-fl"和"proxy-us"时，系统生成的配置如下：

"balancers": [
  {
    "tag": "test",
    "selector": [
      "proxy-fl",
      "proxy-us"
    ],
    "strategy": {
      "type": "leastLoad"
    }
  }
]

但对应的BurstObservatory配置却是：

"burstObservatory": {
  "subjectSelector": [
    "test"
  ],
  ...
}

这显然是不正确的，subjectSelector应该包含的是["proxy-fl", "proxy-us"]而非["test"]。

技术影响

这种配置错误会导致观测器无法正确监测和管理负载均衡器中的实际出站代理。观测器的工作机制是通过定期检测各个出站代理的性能指标（如延迟、负载等），为负载均衡策略提供决策依据。当选择器配置错误时，观测器无法获取正确的代理列表，自然也就无法为负载均衡器提供有效的路由建议。

解决方案

项目维护者已经确认将在下一个版本中修复此问题。修复方案的核心逻辑是：

1. 自动扫描所有使用leastLoad或leastPing策略的负载均衡器
2. 收集这些负载均衡器配置中的所有出站代理标签
3. 去除重复项后生成唯一的出站代理列表
4. 将这个列表正确设置到对应的观测器配置中

这种自动化的处理方式既解决了当前问题，又能适应更复杂的场景，比如当系统中有多个负载均衡器时，可以确保观测器能够正确管理所有相关的出站代理。

用户建议

对于当前遇到此问题的用户，可以采取以下临时解决方案：

1. 手动编辑配置文件，将观测器的subjectSelector修改为负载均衡器中配置的实际出站代理列表
2. 等待下一个版本发布后升级，获取官方修复

这个问题虽然看似简单，但它深刻展示了配置自动化系统中"元信息"正确传递的重要性。在类似的网络代理管理系统中，确保各个组件之间的配置一致性是保证功能正常工作的关键。X-UI团队对此问题的快速响应也体现了他们对产品质量的重视。