Xray-core v26.9.9 于 2026 年 9 月 8 日发布，其中一项与服务器稳定性直接相关的变化，是修复 Observatory 在没有任何出站匹配 subjectSelector 时可能持续占用 100% CPU 的问题。启用了后台出站探测、负载均衡或自动择优，并且近期观察到 Xray 进程异常吃满单核的管理员，是这次更新最需要关注的人群。版本日期可在 XTLS 官方 v26.9.9 发布页核验，故障条件则由 项目官方修复提交直接确认。
合理行动不是看到版本号就立即覆盖生产环境，而是先确认配置是否存在空匹配条件：检查 observatory.subjectSelector、实际出站 tag 与负载均衡选择器是否一致。若条件吻合或 CPU 异常已出现，应优先备份配置并在维护窗口升级到 v26.9.9；若未启用 Observatory，也没有相关异常，可按常规变更节奏评估。本文的主要意图是帮助你判断 Xray-core v26.9.9 Observatory 高 CPU 修复是否与你有关，并给出可复核的升级路径。
关键结论
- 修复针对的是 Observatory 没有匹配到任何出站的特定状态，不等于所有 Xray 高 CPU 都由同一原因造成。
subjectSelector对出站标签执行前缀匹配；拼写、大小写、重命名或生成配置时遗漏标签，都可能使结果为空。- v26.9.9 在 GitHub 上标记为预发布版本。生产环境仍应先在同类配置上验证，并保留回退所需的旧二进制与配置。
- 升级后应同时验证进程 CPU、Observatory 探测结果、业务流量和负载均衡选择，而不能只看服务是否启动。
这次修复解决的具体问题
Observatory 是 Xray 的后台连接观测组件，会用 HTTP 探测匹配到的出站代理，并把结果提供给负载均衡等组件。Project X 的 Observatory 官方文档说明，subjectSelector 是字符串数组，每个字符串按前缀匹配出站标签。例如选择器为 proxy- 时，会覆盖以该前缀开头的多个出站，而不是按节点地址或协议名匹配。
本次问题的关键条件是“匹配结果为空”。官方变更记录将修复描述为：当没有 outbound 匹配 subjectSelector 时，Observatory 会消耗 100% CPU。由此可以确定修复范围，但不能据此断言任何高 CPU 现场都必然命中该缺陷。日志写入、异常重连、TUN 路由循环、外部管理面板或宿主机其他进程同样可能造成类似现象。
如果你刚从较早版本升级，建议先阅读站内的 Xray-core v26.7.28 XHTTP 与 TUN 升级核验指南，区分连续版本间的变化。若高 CPU 出现在 v2rayN 的 TUN 场景，而不是独立运行的 Xray Observatory，则应对照 v2rayN TUN 高 CPU 与重启失败排查，不要把两个不同组件的问题混为一谈。
谁应该优先升级
优先级较高：启用了 Observatory 且选择器可能为空
先在最终生效配置中搜索 observatory 或 burstObservatory，再逐项比对 subjectSelector 与 outbounds[].tag。这里应检查程序实际加载的配置，而不是只看模板；多文件合并、面板生成和容器挂载都可能让磁盘上的某个片段与最终配置不同。
若 CPU 异常与配置重载、出站改名、订阅清空或节点删除发生在相近时间，空匹配是值得优先验证的解释。这是基于故障条件的编辑判断，并非官方对你具体环境的诊断。
按常规节奏：没有 Observatory 配置
若生效配置中完全没有 Observatory，且负载均衡策略也不依赖观测结果，本修复本身不构成立即升级理由。你仍可评估 v26.9.9 的其他变化，但不应借本文推导出性能收益。对于透明代理的工作方式，可先参考 TUN、系统代理与透明代理的区别，再确定监控对象究竟是内核进程、客户端外壳还是系统网络栈。
为什么标签检查比盲目调低探测频率更重要
官方文档明确说明，probeInterval 控制探测间隔，enableConcurrency 控制并发或逐个探测；但本次缺陷的触发描述是没有匹配出站，而非探测频率过高。因此，单纯把 probeInterval 调大可能改变正常探测负载，却不能替代版本修复，也不能纠正错误标签。
还要注意前缀匹配可能“匹配太多”。例如 a 会同时匹配 a 与 ab。这通常不会形成空集合，却可能让观测范围偏离预期。管理多个出站时，建议采用清晰、稳定的标签前缀，并在修改出站名称时同步检查 Observatory 与路由负载均衡配置。代理规则的匹配层次容易混淆，可结合 域名、IP 与规则优先级排查指南梳理，但出站标签仍须以 Xray 生效配置为准。
升级与核验清单
- 确认版本与来源：记录当前 Xray 版本，只从 XTLS 官方发布页或项目明确列出的官方分发渠道获取文件。不要用来源不明的替换包。
- 保存可回退材料：备份当前二进制、完整生效配置、服务单元或容器镜像标签；同时记录升级前的 CPU 基线和故障发生时间。
- 核对标签：列出所有出站
tag，逐个验证subjectSelector至少匹配一个预期出站。若使用面板，确认导出的最终 JSON。 - 先做配置校验：使用当前部署方式支持的 Xray 配置测试命令验证语法。不同封装客户端的命令与路径可能不同，应以该客户端文档为准。
- 在维护窗口替换：停止或滚动替换实例，启动 v26.9.9 后立即确认实际运行版本，避免文件已更新但旧进程仍驻留。
- 观察 CPU：在与故障现场相近的持续时间内观察进程 CPU，而不是只截取启动后几秒。若仍然升高，保留日志和时间线，继续排查其他原因。
- 验证探测与转发：检查被选中的出站是否符合预期、探测状态是否更新，并做一次合法的业务连通性测试。官方 Routing 文档指出，
leastPing与leastLoad策略依赖 Observatory，未被观测覆盖的节点会被排除。 - 准备回退：如出现新兼容问题，恢复已验证的旧版本与配置；不要在生产故障中同时修改版本、标签和路由规则，否则很难定位变量。
如何判断修复是否生效
最有说服力的验证是复现原条件后，CPU 不再持续异常占用，同时 Xray 能正常响应停止、重载和业务请求。若为了验证而故意制造空选择器，只应在隔离的测试实例中进行，避免让生产负载均衡失去可用出站。
如果升级后 CPU 恢复正常，只能说明现象与修复一致，不能证明系统的全部性能问题已经解决。反之，如果 CPU 仍高，先确认运行的确实是 v26.9.9，再查看线程、日志频率、重连行为和宿主机指标。本文不提供未经官方证据支持的性能幅度，也不承诺某个平台必然获得相同结果。
常见问题
没有配置 Observatory，也需要为这个问题紧急升级吗？
仅就这项高 CPU 修复而言，通常不需要。触发条件包含 Observatory 与空出站匹配。你可以按自己的维护周期评估版本中的其他改动，但应先确认客户端是否内置或自动生成了相关配置。
把 subjectSelector 留空会怎样？
官方文档说明它负责按前缀选择要观测的出站。本次修复明确覆盖“没有出站匹配”的情形，因此空数组、错误前缀或所有相关出站被删除都值得检查。具体封装客户端是否会改写空值，需以其生成后的配置为准。
升级 v26.9.9 后可以删除 Observatory 吗？
不应仅因为这个修复就删除。若负载均衡使用 leastPing 或 leastLoad，官方路由文档说明它们需要观测结果。应修正标签并升级；只有确认业务不再需要健康探测或择优时，才考虑调整架构。
v26.9.9 是稳定版吗？
截至 2026 年 9 月 12 日，GitHub 发布页将 v26.9.9 标为 Pre-release。它是官方发布，但“官方发布”不等同于适合不经验证直接覆盖所有生产环境。高风险系统应先灰度并保留回退路径。
CPU 仍然很高，是否说明官方修复无效？
不能这样判断。先核对实际进程版本和触发条件；若没有空匹配，或高 CPU 来自 TUN、日志、重连、管理面板或其他进程，本修复就不是对应答案。保留最小化配置和可重复时间线，再向项目提交可验证的问题信息。
官方来源与核验入口
- XTLS / Xray-core，Xray-core v26.9.9，2026-09-08：查看官方版本、预发布标记与发布资产。
- XTLS / Xray-core，Observatory: Fix consuming 100% CPU when no outbound matches subjectSelector，2026-08-25：查看修复条件与合入代码。
- Project X，Observatory，访问于 2026-09-12：核对 subjectSelector、探测间隔与并发行为。
- Project X，Routing，访问于 2026-09-12：核对负载均衡策略与 Observatory 的依赖关系。
关于作者
