Ray 项目现状与真实可用差距评估

更新时间：2026-06-05 10:35 CST ｜ 评估对象：/root/xray-node-manager、https://www.loveason.com/ray/

一句话结论：Ray 已完成“控制面上线 + 节点展示 + Clash 草稿导出”的第一阶段，但还不是可放心日常使用的真实管理系统；最大缺口是运行中的进程与源码/API 不一致、核心链路/订阅 API 未完全生效、缺少认证/审计/回滚与端到端客户端验收。

1. 当前可确认状态

2. 验证结果

检查项	结果	证据	判断
服务进程	通过	xray-node-manager.service active running；MainPID 为 uvicorn。	服务层已上线。
本地入口	通过	http://127.0.0.1:8787/ 返回 200，HTML 约 30 KB。	应用能渲染首页。
公网入口	通过	https://www.loveason.com/ray/ curl 返回 200。	HTTP 层公网已上线；浏览器栈访问超时，仍需做真实浏览器验收。
健康接口	通过	/ray/health 返回 {ok:true,nodes:14}。	基础健康检查可用。
节点 API	通过	/ray/api/nodes 返回 14 个节点。	节点读路径可用。
核心前端 API	失败	/ray/api/stats 与 /ray/api/links 当前返回 404，但源码中已有对应路由。	运行实例疑似不是最新源码，或 reload/restart 未落地。
链路状态	空	DB 中 linkprofile=0。	还没有真实链路编排成果。
路由规则	空	DB 中 siterule=0。	还没有策略/分流治理成果。
订阅发布	部分	subscription=1、publishrevision=2，导出文件存在。	能产出草稿，但未确认客户端真实执行。
代码仓库状态	未固化	Git 显示大量未跟踪文件；README 为空。	不可复现、不可协作、不可回滚。

3. 与“真实可用”的差距

优先级	缺口	为什么阻塞真实可用	完成标准
P0	运行中服务与源码/API 不一致	前端依赖 api/stats、api/links，但当前服务返回 404；用户看到的控制台会半残，链路区和统计区不可信。	写 restart context 后重启服务，验证 /ray/api/stats、/ray/api/links 均返回 200，并用浏览器确认无前端错误。
P0	没有端到端链路验收	DB 里链路数为 0，说明“边缘 → 落地”链路编排还没有真实产物；目前最多是节点目录和导出草稿。	至少创建 1 条低风险测试链路，完成部署、暂停、恢复、删除全流程；远端 Xray 配置 diff 可回滚。
P0	没有客户端真实执行验收	Clash YAML 可下载不等于客户端可用，更不等于分流/锁定策略生效。	用 Clash/Shadowrocket 导入测试订阅，验证 DNS、策略组、节点连通、出口 IP、AI-SG 等关键规则实际命中。
P1	管理面认证/授权不完整	目前主要依赖 Nginx allowlist；管理面有创建链路、部署、暂停、删除能力，一旦 allowlist 漏洞或代理源 IP 误判，风险高。	至少增加二次认证或强 token；写操作只允许特定来源；所有写操作有审计日志。
P1	节点资料存在准确性问题	例如 JPB 记录 region 为 India、SNI 为 icicibank，但记忆中 JPB 是日本 AWS 节点；这会影响分组、策略与展示。	从 inventory 重新导入并人工核对 label、host、region、role、SNI、port、凭据完整性。
P1	发布模型还是草稿	当前只有 clash-draft.yaml，缺少主订阅/补充订阅映射、版本回滚、发布前校验。	建立 draft→staging→publish 流程；每次发布生成 revision、diff、回滚点，并可映射到真实订阅 URL。
P1	缺少测试与部署固化	README 为空、Git 未跟踪，服务重建/迁移/回滚成本高。	补 README、requirements/uv 固化、systemd/nginx runbook、最小 pytest/API smoke test。
P2	可观测性不足	目前主要靠 journalctl 和手工 curl；链路状态、远端 Xray 状态、发布历史未形成 dashboard 可信闭环。	增加 status/last_check/latency/error 字段，定时检查并展示最近一次结果。

4. 推荐收敛路线

第 1 步：先修“控制台半残”

• 写 Hermes restart context，因为需要重启 xray-node-manager.service。
• 重启后验证 /ray/api/stats、/ray/api/links 从 404 变 200。
• 用浏览器打开 /ray/，检查统计卡片、节点卡片、链路区无 JS 错误。

第 2 步：只做一条测试链路，不批量动 VPS

• 选择一台边缘和一台落地节点，先 dry-run 输出远端改动。
• 备份远端 Xray 配置，部署后检查服务状态和监听端口。
• 验证暂停、恢复、删除能还原现场。

第 3 步：订阅从“能下载”升级为“客户端生效”

• 把当前 draft 与主订阅/补充订阅关系写清楚。
• 导入 Clash/Shadowrocket，验证节点、策略组、规则命中和出口 IP。
• 把“配置存在≠执行成功”作为发布前检查。

第 4 步：固化项目，避免一次性脚本变成长期债务

• 提交 Git 基线；补 README、运维 runbook、API smoke test。
• 为 DB、exports、systemd、nginx 配置增加备份/恢复说明。
• 明确哪些功能是安全读、哪些是高风险写。

5. 阶段判定

阶段	当前状态	说明
外网上线	已达成	公网路径、服务、健康接口和导出文件可访问。
可演示	接近	页面可展示节点，但 API 半残会影响统计和链路区域。
可日常使用	未达成	缺少链路编排验收、客户端验收、认证审计与回滚流程。
可作为生产控制面	距离较远	需要权限、审计、测试、发布流水线、远端变更保护全部闭环。