Ray Control 上线目标达成评估

评估时间：2026-06-04T15:56:25Z；对象：https://www.loveason.com/ray/ 与本机 /root/xray-node-manager。

总体结论

MVP 基本达成

项目已上线，具备 inventory 导入、节点角色管理、线路机→落地机链路建模、站点规则入口、Clash 草案生成、diff/revision 与 allowlist 保护。

目标达成度

约 70%。控制面框架已成立，但“实际线路链路生效”“Shadowrocket/V2Ray 编辑”“健康检查/回滚 UI”“生产订阅发布”尚未闭环。

最大风险

当前 Clash 草案包含若干缺失 client material 的节点，生成了空 public-key / short-id 或 0000 UUID。配置能生成，不代表客户端可用。

一、上线与访问验证

检查项结果证据
服务状态通过xray-node-manager.service active running；uvicorn 监听 127.0.0.1:8787。
Nginx 映射通过/ray/ 反代到 127.0.0.1:8787/，带 X-Forwarded-Prefix /ray。
访问控制通过Nginx 使用 cliproxy-managed-vps-allowlist.conf，并设置 no-store、nosniff、DENY。
公网 URL通过https://www.loveason.com/ray/ 返回 HTTP 200，HTML 49134 bytes。
订阅草案 URL通过/ray/exports/clash/clash-draft.yaml 返回 HTTP 200，8184 bytes，YAML 可解析。

二、原始目标对照

目标达成说明
便捷设置“线路机”和“落地机”基本达成Node 表有 role=edge|landing|subscription_host|management；页面可修改角色、协议、tags、启用状态。当前统计：14 节点、8 线路机、6 落地机。
配置网站通过哪些线路机连接到哪些落地机部分达成LinkProfile 已实现 ingress_node_id / egress_node_id；SiteRule 可绑定 link_profile 或 policy_group；renderer 会生成 Clash relay 组并将自定义域名规则插入 MATCH 前。但当前数据库 SiteRule 为 0，尚未验证实际站点路由生效。
便捷编辑 Clash 订阅链接部分达成可生成 clash-draft.yaml，包含 14 proxies、6 proxy-groups、34 rules；有 diff 与 revision。但还不是完整“编辑订阅链接/多订阅管理”，更多是一个固定 Clash draft renderer。
不直接改远端 Xray、不覆盖生产订阅达成页面文案和 publisher 都写入项目 exports/；未见自动改远端 Xray 或覆盖 DE 生产订阅目录。
可回滚后端雏形有 PublishRevision 和 backup_path，publisher.py 内存在 rollback_revision 函数片段，但 UI/API 未暴露回滚操作；backups 目录当前为空。

三、数据与功能实测

四、主要缺口与风险

1. 订阅里存在不可用节点风险

USB、AR、KRB、UK、AU 等节点在 DB/导出中出现 uuid: 00000000-0000-0000-0000-000000000000、空 public-key、空 short-id。这会导致 Clash 配置可解析但节点不可用。

2. 链路只是 Clash relay 组，不等于真实“线路机 → 落地机”网络编排

当前 LinkProfile 会渲染为 Clash relay。这在客户端侧可能工作，但不是远端 Xray/WireGuard 链路编排；也没有健康检查证明该 relay 可用。

3. SiteRule 未实际使用

UI 和后端存在，但当前规则数为 0。目标中的“某些网站通过哪些线路机到哪些落地机”还停留在能力入口，未形成实际策略样本。

4. Shadowrocket/V2Ray 目录存在但未实现

exports/shadowrocket、exports/v2ray 目录存在；当前实现只看到 Clash renderer。

5. 健康检查偏浅

/health 只返回 ok、time、nodes、exports_dir。没有 SSH、Xray service、443、订阅 URL、Clash 节点连通性、relay 链路验证。

五、建议下一步

  1. 先修 client material 校验：渲染 Clash 前跳过 uuid/public-key/short-id 缺失节点，或标红禁止启用。
  2. 做 3 条真实 SiteRule 样本：例如 OpenAI → SG→US、BBC → SG→UK、默认 MATCH → 代理服务；发布后用 Clash 解析器验证规则顺序。
  3. 补健康检查：节点级 SSH/443/TLS/SNI；订阅级 YAML parse；链路级 relay 可用性。
  4. 补回滚 UI/API：Revision 页面加“回滚到此版本”，回滚后重新验证 YAML。
  5. 补 Shadowrocket 导出：至少先生成 URI list 或 .conf 草案，不急着替换生产。
  6. 避免策略组回路：renderer 需要检查 proxy-groups 中 group 引用是否形成循环，特别是 select/fallback/relay 混用时。

六、最终判断

Ray 已经实现“可上线的 MVP 控制面”，但还没达到“可放心管理真实出站策略”的成熟状态。

当前最适合定位为：节点 inventory 可视化 + Clash 草案生成器 + 路由策略实验台。下一阶段应先补可用性校验、站点路由样本和回滚闭环，再接生产订阅。

本报告只记录结构和公开 client-side 配置状态，不包含私钥。