节点与协议服务管理

Zboard 将基础设施节点、协议服务和商业订阅分离管理。节点描述可运维的服务器，协议服务描述对外提供的网络能力，节点组和订阅模板决定用户最终获得什么。

资源关系

text

供应商账号 / VPS 节点资产
              ↓
      Zero 安装与运行状态
              ↓
        Protocol Service
              ↓
           Node Group
              ↓
      Subscription Delivery

DNS 记录和托管证书关联到节点与协议服务，但仍是独立资产。

新节点接入

新 VPS 的受管接入按以下生命周期进行：

text

注册 VPS
  → 配置 SSH
  → 验证 SSH / 提权能力
  → 准备节点身份与上报凭据
  → 提交 Zero 安装
  → 本机/systemd/control 验证
  → 节点就绪

BBR 是 SSH 验证后的可选网络优化，不在 Zero 安装成功的关键路径中。保存 SSH 后即可以继续完成 SSH/权限验证和 Zero 初始化，不需要通过“是否启用 BBR”来触发后续流程。

Zero 安装、升级和单节点 reconcile 接受后由后端异步执行，不再绑定浏览器请求生命周期。关闭页面或请求被取消，不代表已经接受的节点操作被取消；进度和最终结果应从任务/节点状态查看。

区分三种运行状态

节点运维时不要把下面三类事实合成一个“在线/离线”：

状态	表示什么
Zero / Kernel	目标二进制已安装、systemd 服务 active、控制 socket 健康
Connector	节点事件最近仍能成功送达并由 Zboard 接收
业务流量	当前是否存在用户连接、活跃 flow 或字节事实

一个刚安装、当前没有用户流量的节点可以同时满足：Zero 健康、Connector 在线、业务流量为 0。这是正常空闲状态。

受管安装完成后的本地健康检查不再因为短时间没有 Connector 事件而回滚一个已经健康的 Zero generation。缺少新事件会记录为 Connector 警告并单独呈现，不应伪装成内核安装失败。

Connector liveness 使用 Zboard 实际接收/持久化事件的时间刷新，而不是直接把 VPS 上事件的 occurred_at 当成面板在线时间，避免节点时钟偏差或积压事件导致错误离线判断。

Zero 版本选择与发布

节点可以选择明确的 Zero 发行版本。选择时应区分正式版和预发布版，并按语义版本比较，不要按字符串排序。

VPS 列表会显示节点实际持有的 Zero 版本；较长的 dev/build 版本在列表里可以缩写显示，但详情和版本比较仍使用完整版本号。

当前统一使用 Zero Core 0.0.1，支持 Trojan/Hysteria2 托管用户和 Mieru 用户归属。创建和发布时仍需检查所选构建的实际协议能力；缺少能力时先更换兼容构建，不应通过共享占位凭据绕过限制。

批量 Zero rollout 会固定目标版本和降级策略，并使用后端受限并发执行，避免不同节点在一次任务中各自解析出不同目标版本。

协议服务

协议服务负责描述：

协议和监听端口；
TLS、REALITY 和传输方式；
客户端订阅模板；
托管证书；
流量倍率和运营名称；
所属节点及最近发布状态。

协议服务配置支持复用、审计和重新发布，但运行时仍绑定到具体节点。详细字段和版本边界见协议服务配置。

节点运行时诊断会按该节点实际分配的协议服务解释 listener，而不是把整个平台其他节点的协议端口混进当前节点检查。进入“内核与运维”后可以进行受控的运行状态诊断；主机资源和 SSH 采样仍保持显式操作，不做无界后台 SSH 轮询。

新节点的 bootstrap inbound

Zero Core main 已支持无入站的管理模式；当前 Zboard 编译器仍为没有实际协议服务的新节点注入 bootstrap inbound，不能把面板的兼容实现解释为内核仍要求 listener。该入站：

只监听 127.0.0.1；
使用临时端口 0；
不持久化为业务 ProtocolEndpoint；
不会出现在用户订阅中。

一旦节点存在真实的启用协议服务，就发布真实 listener，不应继续把 bootstrap inbound 当成节点业务能力。即使真实协议当前还没有订阅用户，也可以以空托管用户集合发布；如果已经存在有效订阅却无法生成对应凭据，则发布应明确失败，而不是静默退回 bootstrap。

发布流程

一次完整发布应完成：

根据协议服务和订阅用户能力编译 Zero 配置；
在目标节点运行配置校验；
原子替换或激活配置；
检查进程、服务监听和控制接口；
独立观察 Connector 是否恢复事件投递；
更新协议服务的实际发布状态。

任何一步失败都不应把未验证能力提前暴露给订阅。修复首个错误后重新发布，并保留失败任务和审计记录。

新生成的协议归属 identity 使用不暴露内部数据库 ID 的 opaque principal。它用于 Core flow 归属，不等于协议认证秘密；既有 principal 不会因为升级被强制改写，以保留历史归属连续性。

自动发布与重试

订单确认、订阅到期、流量耗尽、协议端点变更等操作会在业务事务内写入 node_config_publishes。请求落库失败时业务事务回滚；后台按节点合并最新配置，不在业务事务中等待 SSH。

服务启动会扫描待办，最多四个工作线程执行，空闲时每 5 秒检查。失败按 5、10、20 秒等间隔退避，最长 5 分钟；重启和租约过期后可以接续，不因次数达到上限而丢弃任务。

这是至少一次发布：节点已应用配置而数据库尚未确认时可能重复执行。请结合协议发布历史、待办错误与节点运行状态判断；队列为空不等于 Connector 在线。手工发布仍走同步流程。

BBR 与主机操作

BBR 是节点级可选操作，不是节点健康前提。SSH 已验证后，进入“内核与运维”会读取一次 VPS 当前的拥塞控制/qdisc 状态，让页面显示真实主机状态；仍可以手动重新检测，但不会周期性轮询。

启用或调整 BBR 前应确认目标内核和系统支持。Zboard 只通过已验证的受管 SSH 路径执行操作，并应把任务结果与实际主机状态分开展示。

删除节点与远端清理

删除面板记录与停止远端 Zero 是两个独立操作。当前删除节点只在数据库事务内清理节点、协议、凭据、前置入口、代理池及关联运行记录；不连接 SSH，也不请求供应商 API。历史订单、订阅、流量与审计事实保留。其他存活入口节点需要撤除转发时，任务进入发布队列。

因此删除成功不表示远端服务停止或旧凭据即时失效。仍在运行的安装、发布等任务需要先串行完成；数据库清理失败会回滚。

若要退役节点，先从“节点资产 → 内核与运维”下载独立清理脚本，在目标 Linux/systemd 节点查看状态并停机，再删除面板记录：

sh cleanup-zero-node.sh status
sudo sh cleanup-zero-node.sh stop --yes

通过新版面板安装或更新过 Zero 的节点，也可使用 /usr/local/sbin/zboard-zero-cleanup；既有节点不会自动获得脚本。stop 关闭连接并禁用服务，保留配置、二进制和事件数据。确认需要删除托管文件时另行使用 uninstall --yes，范围见节点清理说明。面板已经不可用时仍可离线执行该脚本。

节点组与运营配置

节点加入并发布协议服务后，可以进一步关联：

节点组；
套餐和 SKU；
订阅模板；
流量倍率和统计规则；
DNS 记录与证书。

节点组引用协议服务，而不是直接引用一台裸服务器。这样可以在迁移服务或调整传输时保持上层商业配置稳定。

日常检查

节点实际 Zero 版本与期望版本一致；
Kernel 状态健康，不要用 Connector 状态替代内核健康；
Connector 最近持续上报事件；
当前没有业务流量时，不把 active_flows=0 误判为节点离线；
最近协议发布状态成功，运行 listener 与该节点分配的协议服务一致；
SSH 验证和需要的主机操作状态正常；
DNS 记录指向正确节点；
证书在有效期内且绑定关系正确；
订阅预览包含预期节点和本地 Mixed 入口；
流量记录能够归属到订阅用户。

Zero 的底层协议能力、配置模型和控制接口请参考 Zero Core 项目仓库。

节点与协议服务管理 ​

资源关系 ​

新节点接入 ​

区分三种运行状态 ​

Zero 版本选择与发布 ​

协议服务 ​

新节点的 bootstrap inbound ​

发布流程 ​

自动发布与重试 ​

BBR 与主机操作 ​

删除节点与远端清理 ​

节点组与运营配置 ​

日常检查 ​