能连上，也要能管理。
网络环境搭建完成后，日常管理才刚开始：成员需要开通与停用，流量与有效期需要调整，多个节点需要保持配置对应关系，故障时还要判断是管理接口、订阅还是实际转发链路出了问题。
项目通过独立用户门户承接账号和业务规则，由服务端适配现有节点管理接口，再交给成熟的网络运行时执行转发。工作重点是把这些环节接起来，并提供状态核查、失败处理与运维交接。
账号状态、节点配置与实际连接，需要分别确认。
底层转发使用现有开源组件。案例着重说明用户平台与节点之间的协调、统计口径以及运行检查，服务在授权设备和服务器环境内实施。
把日常运维变成明确的流程。
账号开通有依据
记录用户状态、额度与有效期，将业务参数映射到节点客户端，开通失败时撤销未完成的数据。
多节点修改可追踪
更新相关入站并按顺序重载，保留同步失败与降级记录，避免管理后台显示成功但节点未完成更新。
流量口径说得清
区分累计用量、瞬时速度与在线名单，处理镜像入站重复累计和计数器重置。
故障与交接有路径
分层检查管理接口、订阅解析与代理请求，配合数据库备份、发布回滚和归档校验。
- 设置业务参数
- 同步节点
- 重载与核查
- 交付接入
- 监控与维护
一个账号，三种独立状态。
试着载入额度耗尽、已到期或已停用场景，再单独切换健康检查与在线名单。观察为什么“后台能打开”“账号有额度”和“当前在线”不能互相替代。
固定样例演示 · 不连接真实节点，不生成账号或订阅。
样例检查通过
- 账号策略
- 启用、有效期与流量条件均满足
- 运行探测
- 控制面与代理探测均正常
- 在线状态
- 样例在线名单中存在该账号
账号满足条件、链路检查通过、当前在线是三个不同状态。可分别切换，观察它们的差异。
此处解释策略关系；实际系统的额度与到期由节点配置执行，订阅入口直接检查账号存在与停用状态。
管理与转发各司其职。
独立业务平台负责用户、额度、期限与审计；节点管理组件负责入站和客户端配置；网络运行时执行连接转发。管理接口通过服务端调用，浏览器不接触节点管理凭据。
业务规则通过服务端适配转换为节点配置
用户与管理门户
Next.js / React
账号、额度、期限与监控
服务端适配层
归属与权限检查
节点映射、配置同步与回滚
节点管理与转发
3x-ui 管理接口
Xray 执行网络连接
- Next.js 16 / React 19 / TypeScript
- 组织用户页面、管理工作台和服务端 API，支持独立构建产物部署。
- Prisma 7 / PostgreSQL 17
- 保存业务记录，通过事务维护账号、积分、续费与审计的一致性。
- 节点 API 适配
- 将业务参数映射到现有组件；节点管理和底层转发不作为自研成果。
- 运行与归档脚本
- 定时采集快照、执行分层探测，对归档文件进行摘要与落盘校验。
把状态差异处理清楚。
以下机制来自当前业务源码；公开描述省略真实地址、配置、账号与订阅标识。
账号开通与修改：业务参数要落实到节点
用户模型保留额度、到期时间、停用状态与客户端关联身份。服务端把启用、额度和有效期映射到节点字段。新建账号后的上游配置失败时删除未完成账号；修改失败时恢复原业务参数。
订阅入口直接拒绝不存在或已停用的账号；额度和到期限制通过节点配置执行。这两层各有职责，不能把订阅返回成功理解为连接必定可用。
对应模块：schema.prisma、api/admin/users/route.ts、xui.ts
跨节点同步：记录失败，控制降级范围
配置同时写入中心入站与对应的远程入站，再按远程、中心的顺序重载。严格同步模式保存失败时，会尝试回滚已经修改的配置。
部分续费流程允许远程节点异常时降级并记录审计；管理员修改仍使用严格同步。数据库和远程 API 没有统一事务，回滚属于尽力补偿，尚无持久化补同步队列。
对应模块：xui.ts、api/packages/[code]/purchase/route.ts
用量监控：避免重复累计与虚假速率
在当前镜像统计口径下，同一客户端出现在多个入站时，对累计值取最大值去重，避免简单相加导致重复计费。没有关联平台账号的客户端会保留为独立状态，便于核查。
速度使用两次累计字节差与实际采样间隔计算；首次采样或计数器回退显示未知。在线状态取上游在线名单，与账号是否启用分别展示。按日期归并的流量快照以事务和 UPSERT 写入。
对应模块：traffic-monitor.mjs、traffic-monitor-table.tsx、snapshot-traffic.mjs
续费与结转：明确周期和剩余额度
有效的有限额度套餐支持未用流量结转。新周期需要同时调整业务额度并清零节点累计值，避免把历史消耗再次扣入新额度。
不同套餐状态分别处理，积分变化、套餐更新和审计放在数据库事务中。远程节点同步仍需独立检查，不能由本地事务成功推断全部节点完成。
对应模块：package-purchase.mjs、api/packages/[code]/purchase/route.ts
分层探测：检查真实转发路径
健康脚本依次检查控制面、订阅解析、基础连通与临时客户端代理请求，并利用连续失败记录区分正常、降级和失败。单纯端口开放不能证明转发工作正常。
当前脚本检查订阅中的首个节点，尚未形成逐节点健康矩阵。订阅顺序也不等于自动故障切换。
对应模块：check-subscription-health.mjs、subscription-health.mjs
运维数据：限制入口，验证归档
公网反向代理阻断内部观测入口，采集凭据与节点绑定。敏感观测字段采用 AES-GCM 加密，检索键采用 HMAC，避免将明文观测内容直接用于索引。
归档使用压缩、SHA-256、临时文件和多次落盘校验，确认归档后才删除对应历史数据。另有数据库备份与发布回滚脚本，但完整跨环境恢复仍需要独立演练。
对应模块：observability-security.mjs、archive-observability-to-nas.ps1、生产运维脚本
复杂处，往往在两个系统之间。
远程 API 不在数据库事务内
将本地业务更新、节点配置与重载分段处理，保存足够的旧状态，失败时尝试回滚并记录未完成项。更强的一致性需要持久补偿与恢复机制。
统计规则依赖实际拓扑
最大累计值适合当前镜像入站的去重需求。若节点真正承担独立流量，就需要重新定义统计口径，不能沿用同一个求和或取最大值公式。
可用性需要逐层证明
管理页面、订阅内容、连接转发分别检查，保留失败发生在哪一层。这样排障可以沿具体链路推进，而不是反复重启全部服务。
备份要考虑恢复条件
除了文件摘要，还要记录版本、环境与依赖，并在独立环境进行恢复检查。当前脚本有机器路径与调度依赖，需要在迁移时显式核对。
服务端界面，展示管理过程。
截图来自隔离演示环境中的实际管理页面，使用虚构账户与模拟流量，不包含真实服务器、订阅或客户信息。图中的状态与数值仅用于展示界面。
可维护的流程，明确的边界。
当前已实现
- 独立用户门户与服务端节点适配。
- 账号开通、配额与有效期管理，以及停用状态校验。
- 跨节点同步、失败回滚与有限降级审计。
- 流量去重、在线状态、采样速度与历史快照。
- 分层代理探测、备份、归档校验及版本回滚流程。
仍需进一步完善
- 未实现持久化跨节点补偿队列，降级后需补同步。
- 健康脚本未覆盖逐节点矩阵与自动切换闭环。
- 当前统计口径需随拓扑变化重新校验。
- 跨环境灾备恢复尚需独立演练与记录。
- 底层协议和转发内核来自开源组件；可用性与性能需要实际环境验证。
依据当前源码与运维脚本整理，核对日期：2026 年 9 月 11 日。交互演示为浏览器固定样例，不连接真实节点，也不提供订阅或在线开通服务。