运行和检查 AeroNyx 节点：健康检查、升级与回滚

Q: 出现异常时应先运行哪条命令？

以 root 身份运行 ./deploy/node/aeronyx-node.sh status --repo-dir "$PWD"。它会显示服务状态、本地健康状况、发现以及建议的下一步，并且不会更改主机。

Q: 为什么健康检查因“config missing”或 Git 警告而失败？

你可能不是 root，或者指向了错误的仓库。/etc/aeronyx 和 /var/lib/aeronyx 仅限 root 访问；如果不传 --repo-dir，脚本会检查 /opt/aeronyx/AeroNyx，而不是服务实际运行所用的检出目录。

Q: relay-probe 和 relay-smoke 有什么区别？

relay-probe 发送一个合成的不透明信封，只能表明某条中继路径接受流量。relay-smoke 以真实客户端的身份运行：它会针对一条加密测试消息验证签名终端回执，以及完整的信箱拉取和确认。

Q: 能否在不断开用户连接的情况下升级？

在用户已连接时，你可以使用 --no-restart 构建并暂存升级。切换到新版本需要重启，因此请先通过维护模式排空节点，然后运行 upgrade --skip-pull。

Q: 如何回到上一个版本？

失败的升级会自动回滚。如果之后要回滚，请对 /var/lib/aeronyx/releases/ 中的某个备份使用 promote-binary；它要求活动会话为零，并且如果被提升的版本不健康，会恢复先前的二进制文件。

本运维手册涵盖已注册 AeroNyx 节点的日常命令：状态、健康检查、日志、中继与信箱证明、安全升级、回滚，以及重启后需要检查的内容。所有命令都位于节点仓库中（deploy/node/aeronyx-node.sh 和 aeronyx-server 二进制文件），并按代码实际接受的选项给出。

如果你尚未安装节点，请从安装并注册 AeroNyx 节点开始。

开始之前

所有命令都在 root shell（sudo -i）中运行。配置目录 /etc/aeronyx 和状态目录 /var/lib/aeronyx 的权限为 700，因此以其他用户身份运行时，状态、健康检查、校验和中继命令都无法读取它们。

切换到服务实际运行所用的仓库目录，并在每条脚本命令中通过 --repo-dir 传入它。如果不传 --repo-dir，脚本会假定为 /opt/aeronyx/AeroNyx。

bash

cd "$(systemctl show aeronyx-server -p WorkingDirectory --value)"
pwd

对于使用 Nodeboard 命令安装的节点，这会打印 /root/open/AeroNyx。

命令一览

命令	是否更改主机？	用途
`./deploy/node/aeronyx-node.sh status --repo-dir "$PWD"`	否	初步查看：服务状态、本地健康状况、发现、升级状态以及建议的下一步
`./deploy/node/aeronyx-node.sh health --repo-dir "$PWD" --json`	否	完整诊断；最后一行为 JSON
`./deploy/node/aeronyx-node.sh logs --repo-dir "$PWD" --lines 200`	否	最近的服务日志（使用 `--follow` 持续跟踪）
`./deploy/node/aeronyx-node.sh relay-probe --repo-dir "$PWD" --two-hop --json`	不更改主机；向对等节点发送一个合成的加密信封	中继路径是否可用？
`./target/release/aeronyx-server relay-smoke --confirm-live-relay-smoke --json`	创建两个短期测试会话	端到端证明经过认证的中继投递
`./target/release/aeronyx-server mailbox-probe … --confirm-live-mailbox-probe --json`	在目标节点上创建一个短期信箱	端到端证明经洋葱路由访问的匿名信箱
`./deploy/node/aeronyx-node.sh upgrade --repo-dir "$PWD" …`	是	构建、校验并切换到新版本，支持回滚

状态

bash

./deploy/node/aeronyx-node.sh status --repo-dir "$PWD"

status 按以下顺序打印：

systemctl status aeronyx-server（最后 20 行）
本地健康检查 API（http://127.0.0.1:8421/api/vpn/health）和运营者状态 API（http://127.0.0.1:8421/api/operator/status）的摘要
来自 http://127.0.0.1:8422/api/discovery/status 的本地发现就绪状态：ChatRelay 通告和对等节点法定数量
来自 /var/lib/aeronyx/upgrade-status.json 的上一次升级流程状态
运营者建议：operator_status、operator_title、operator_detail 和 operator_next_step

该建议来自健康检查。其状态为以下之一：

`operator_status`	优先级	含义
`critical`	`fix_failed_healthcheck` 或 `fix_failed_upgrade`	某项检查失败，或上一次升级失败
`warning`	`service_not_active`、`privacy_protocol_degraded` 或 `review_warnings`	服务未运行、本地健康状况不是 `ok`，或存在警告
`info`	`upgrade_staged`	已暂存一个构建，等待重启
`ok`	`monitor`	没有失败的检查

健康检查

bash

./deploy/node/aeronyx-node.sh health --repo-dir "$PWD" --json

健康检查会读取文件、systemd 和本地端点；它从不更改主机。每项检查会打印 [PASS]、[WARN] 或 [FAIL]，接着打印一行 [SUMMARY] pass=… warn=… fail=…，然后是一行 JSON。使用 --json-only 可只打印 JSON。只要有任何检查失败，该命令就以非零状态退出。

检查内容包括：仓库、受跟踪的 Cargo.lock 和发布二进制文件；使用 aeronyx-server validate 校验配置；注册文件和密钥文件；systemd 单元、重启策略和加固设置；内存、磁盘以及端口 51820 和 8421；IP 转发和 NAT；本地健康检查端点；发现；以及版本备份。

主要 JSON 字段：

字段	含义
`success`	没有检查失败时为 `true`
`summary`	`pass`、`warn` 和 `fail` 的计数
`operator_action`	`status` 显示的建议（`status`、`priority`、`title`、`detail`、`next_step`）
`local_vpn_health`	`status`（健康时为 `ok`）、`active_sessions`、`placement_readiness`、`encrypted_message_forwarding`
`capacity`	节点报告的容量计数和风险
`discovery_readiness`	ChatRelay 能力（是否已配置、端点是否就绪、运行时是否就绪、是否已通告、阻碍因素）、`peer_quorum`（`quorum_ready`、`valid_peers`、`healthy_peers`、`routeable_chat_relays`、`routeable_onion_middle_hops`、`next_action`）、`network_story`（单跳和两跳就绪状态）以及 `recovery_anchor`
`runtime`	检出目录的 Git 提交和分支、受跟踪文件是否被修改、二进制文件和配置的时间、`service_active`、`service_enabled`、systemd 重启策略、单元是否指向此二进制文件和配置、VPN 子网、版本备份
`upgrade_status`	上一次升级的步骤、状态和消息
`checks`	每项检查及其状态和消息

你也可以直接读取原始的本地端点：

bash

curl -s http://127.0.0.1:8421/api/vpn/health
curl -s http://127.0.0.1:8422/api/discovery/status

日志

bash

./deploy/node/aeronyx-node.sh logs --repo-dir "$PWD" --lines 200
./deploy/node/aeronyx-node.sh logs --repo-dir "$PWD" --follow

它们分别封装了 journalctl -u aeronyx-server -n <lines> --no-pager（默认 160 行）和 journalctl -u aeronyx-server -f。如需按时间范围查看，请直接使用 journalctl，例如 journalctl -u aeronyx-server --since "1 hour ago"。

中继与信箱证明

这些命令回答的是不同的问题。不要把合成探测通过当作真实投递的证明。

relay-probe（合成）

bash

./deploy/node/aeronyx-node.sh relay-probe --repo-dir "$PWD" --json
./deploy/node/aeronyx-node.sh relay-probe --repo-dir "$PWD" --two-hop --json

从本节点向一个已发现的 ChatRelay 对等节点发送一个合成的、随机的不透明 BlindRelay 信封，并且只报告计数器的变化。--two-hop 会经由一个中间跳将其发送到终端节点。结果中的 status 为 ok、attention、blocked 或 error；当无法建立两跳路径时，two_hop_readiness 会说明缺少什么。它会读取对等节点缓存和节点密钥，因此需要 root。它不是用户流量，也不能证明信箱投递。fleet-smoke 会在你通过 --endpoints 列出的多个公共节点上运行类似的合成检查。

relay-smoke（经过认证，端到端）

bash

./target/release/aeronyx-server relay-smoke --confirm-live-relay-smoke --json

relay-smoke 以真实客户端的身份访问本主机上的节点。它使用一次性身份打开两个短期会话，并完成固定到本节点密钥的生产握手。它通过经过认证的多跳中继路径发送一条 48 字节的端到端加密随机消息。然后，它会验证该请求对应的签名终端回执，从本节点的信箱中拉取消息、解密并确认，最后检查信箱已清空、会话已关闭。

除非所有闸门都通过，否则它会拒绝启动：

闸门	失败时的输出
本地健康状况为 `ok`，且没有健康检查失败	`node health is not ready` / `node health has failed checks`
节点的活动会话数为零	`relay smoke requires zero active sessions for evidence attribution`
对等节点法定数量、路由池和两跳洋葱路由均已就绪	`peer quorum is not ready` / `route pool is not ready` / `two-hop onion route is not ready`
存在一条经过认证的投递路径，且至少有两个支持投递回执的对等节点	`authenticated delivery path is not ready: <reason>`，其中原因为 `no_receipt_capable_terminal`、`no_receipt_capable_middle` 或 `no_network_diverse_receipt_path`
配置中已启用 ChatRelay，且其运行时已就绪	`chat relay is disabled in node configuration` / `chat relay runtime is not ready`
中继托管存储已验证具备完整提交持久性（SQLite `FULL` 或更强）	`encrypted custody durability is unavailable; restart the node with the current binary` / `… is not FULL-or-stronger`
正在运行的二进制文件报告了经过认证的洋葱中继健康状况	`authenticated onion relay health is unavailable; restart the node with the current binary`

说明：

它必须以 root 身份在节点本机上运行。它会读取 /etc/aeronyx/server.toml 和节点密钥，并且只接受环回地址（--server，默认 127.0.0.1:51820；--health-url，默认 http://127.0.0.1:8421/api/vpn/health）。
--timeout-seconds 设置证明时间窗口：5 到 120 秒，默认 30 秒。
活动会话数为零意味着为 VPN 用户提供服务的节点必须先排空。在 Nodeboard 中开启维护模式，并等待会话数降为零。
这两个测试会话是真实的协议会话，因此可能会短暂出现在 Nodeboard 的会话中。
通过时，"status": "passed"，terminal_receipt_observed、entry_mailbox_round_trip_verified、entry_mailbox_ack_verified 和 e2e_ciphertext_verified 均为 true，且 session_cleanup 为 explicit_authenticated_close。terminal_replica_cleanup 为 node_ttl_managed：在入口节点上确认并不会删除终端节点持有的副本，该副本会自行过期。
任何闸门失败、错误或缺失字段都属于证明失败，而不是部分成功。

mailbox-probe（客户端发起）

bash

./target/release/aeronyx-server mailbox-probe \
  --seed http://SEED_PUBLIC_IP:8422 \
  --target <64-hex node ID of the mailbox node> \
  --entry <64-hex node ID of a different entry node> \
  --confirm-live-mailbox-probe --json

mailbox-probe 的行为与应用相同：它使用一次性密钥，根据从 --seed 节点收集的签名描述符自行构建洋葱路由，并向入口节点的公共对等节点 API 发送明文 HTTP 请求，不使用 VPN 会话。它在目标节点上运行完整的匿名信箱生命周期：ticket_issue、lease_create、put、pull_one、ack，以及最后一次 pull_one。它会检查拉取到的字节是否一致，以及信箱随后是否为空。通过时报告 "status": "verified" 及跳数。

--seed 可以重复指定。如果不指定 --entry，路由只有一跳。
节点 ID 是节点的 64 字符十六进制公钥。在你运营的节点上，./target/release/aeronyx-server pubkey -c /etc/aeronyx/server.toml 会打印它。
目标节点必须启用匿名信箱（[memchain.chat_relay.anonymous_mailbox] enabled = true）；该功能默认关闭。
--work-bits（默认 12）必须不低于目标节点的票据工作量设置。--timeout-seconds 按单个请求计算（默认 20）。
它不读取本地节点文件，因此可以在任何装有该二进制文件的机器上运行。它证明的是对一个不透明条目的托管，而不是证明接收者能够解密它。

安全升级

请使用升级流程，而不是先 git pull 再 systemctl restart：

bash

./deploy/node/aeronyx-node.sh upgrade --repo-dir "$PWD" --build-priority live --build-jobs auto

它会执行以下操作：

获取部署锁；如果检出目录中受跟踪的文件被修改，则拒绝运行（可用 --allow-dirty 覆盖）。
拉取 main（或使用 --commit <40-hex SHA> 在隔离的检出目录中构建确切的提交）。
使用仓库固定版本的 Rust 工具链进行构建。live 优先级（默认）和 --build-jobs auto 大约使用一半的 CPU，以便正在运行的节点继续提供服务。
使用新的二进制文件校验 /etc/aeronyx/server.toml。配置文件永远不会被覆盖。
将实际正在运行的二进制文件备份到 /var/lib/aeronyx/releases/。
在构建完成后检查活动会话，并在重启前再检查一次。如果存在任何活动会话，或者服务运行时无法读取会话数量，它会停止且不切换版本。
更新 systemd 单元，换入新的二进制文件，并重启服务。
最多等待 180 秒（90 次检查，间隔 2 秒），直到本地健康检查从刚构建的提交报告 ok。如果重启、服务状态或健康检查失败，它会自动恢复先前的二进制文件和单元。
每种类型保留最近的 10 份备份，并将结果记录到 /var/lib/aeronyx/upgrade-status.json。

如果节点有活动会话，构建仍会运行，随后升级会以 Active sessions appeared during compilation. Enter maintenance mode, drain sessions, and run the upgrade again. 停止。请在 Nodeboard 的设置中开启维护模式，等待活动会话降为零，然后再次运行同一命令。重新构建会复用缓存。

现在暂存，稍后重启

bash

./deploy/node/aeronyx-node.sh upgrade --repo-dir "$PWD" --no-restart

--no-restart 会构建、校验并备份，然后将新的二进制文件安装到磁盘上，但不重启。随后 status 会报告 upgrade_staged。正在运行的进程仍保持旧版本。之后的任何重启，包括系统重启或崩溃后的自动重启，都会启动新的二进制文件。

要在维护窗口内切换，请排空节点并在不拉取的情况下再次运行升级，这样它会切换到你暂存的确切版本，并执行会话检查、健康等待和回滚：

bash

./deploy/node/aeronyx-node.sh upgrade --repo-dir "$PWD" --skip-pull

不要使用 --force。即使存在活动会话或会话数量未知，它也会重启，并断开用户连接。

手动回滚

当新版本无法启动或无法报告健康时，升级会自动回滚。如果之后想回到更早的版本，请提升其中一个已保存的二进制文件：

bash

ls -lt /var/lib/aeronyx/releases/
./deploy/node/aeronyx-node.sh promote-binary --repo-dir "$PWD" \
  --binary /var/lib/aeronyx/releases/<aeronyx-server.binary.YYYYMMDD_HHMMSS.xxxxxx>

promote-binary 会使用所选的二进制文件校验配置，并且除非活动会话恰好为零，否则拒绝运行。它会要求你输入 PROMOTE BINARY，将当前二进制文件备份在其旁边，换入新二进制文件并重启。如果服务在 180 秒内未恢复健康，它会恢复先前的二进制文件。它只替换二进制文件，不替换 systemd 单元。

任何重启之后

按顺序检查以下内容：

systemctl is-active aeronyx-server 返回 active。该单元为 Type=notify，因此 active 表示进程已报告就绪；在 systemd 放弃之前，启动最多可能需要 300 秒。
./deploy/node/aeronyx-node.sh status --repo-dir "$PWD" 显示 operator_status=ok，或显示一条你理解的警告。
./deploy/node/aeronyx-node.sh health --repo-dir "$PWD" --json 以 "success":true 结尾，且 local_vpn_health.status 为 ok。
正在运行的提交是你预期的那个：curl -s http://127.0.0.1:8421/api/vpn/health 会将其报告为 runtime.git_commit。（health --json 中的 runtime.git_commit 是检出目录的提交。）
在最初几轮 gossip 之后，discovery_readiness.peer_quorum.quorum_ready 为 true。
对于中继节点：relay-probe --two-hop --json 报告 ok。
在 Nodeboard 中，心跳是最新的，Rust 运行时显示新版本，重启记录出现在告警 / 事件下。完成后关闭维护模式。
journalctl -u aeronyx-server --since "15 min ago" 中没有反复出现的错误。

在 Nodeboard 中如何显示

Nodeboard 接收节点的签名心跳和会话报告。它本身不会在主机上运行命令；你在其中选择的操作会进入队列，由节点在下一次心跳时执行。

节点上	Nodeboard 中
服务状态和本地健康状况	节点列表和节点详情：AeroNyx 健康状况、Rust 运行时、AeroNyx 服务就绪状态
容量计数	节点详情：节点容量和容量决策（`ready`、`watch`、`blocked`、`waiting`）
发现和中继就绪状态	节点详情：节点发现、加密聊天中继；整个节点群见服务
`upgrade-status.json`	节点详情：Rust 升级流程；服务 → 节点群重启就绪状态
服务日志中的警告	节点详情：近期运维事件（已脱敏，最近 24 小时）
重启和恢复	告警 / 事件 → 事件关闭（`open`、`watch`、`recovered`）
维护模式、最大会话数、带宽、等级	设置，当策略同步显示 `synced` 时即已确认

节点详情中还有一张运营者运维手册卡片，提供针对检测到的仓库路径、可复制的 health、status、logs 和暂存升级命令。

输出包含什么

status、health、relay-probe、relay-smoke 和 mailbox-probe 只打印汇总值：计数、状态、耗时和原因代码。它们不会打印私钥、注册码、客户端公网 IP、访问目标、DNS 内容、载荷或消息明文。包含客户端密钥的会话记录可在 Nodeboard 中查看，而不在这些输出中；请参阅 Nodeboard 运营者控制台指南。在为获取支持而分享输出时，请分享 JSON 及其时间戳，而不要分享主机地址或凭据。

常见问题

出现异常时应先运行哪条命令？

以 root 身份运行 ./deploy/node/aeronyx-node.sh status --repo-dir "$PWD"。它会显示服务状态、本地健康状况、发现以及建议的下一步，并且不会更改主机。

为什么健康检查因“config missing”或 Git 警告而失败？

你可能不是 root，或者指向了错误的仓库。/etc/aeronyx 和 /var/lib/aeronyx 仅限 root 访问；如果不传 --repo-dir，脚本会检查 /opt/aeronyx/AeroNyx，而不是服务实际运行所用的检出目录。

relay-probe 和 relay-smoke 有什么区别？

relay-probe 发送一个合成的不透明信封，只能表明某条中继路径接受流量。relay-smoke 以真实客户端的身份运行：它会针对一条加密测试消息验证签名终端回执，以及完整的信箱拉取和确认。

为什么 relay-smoke 提示需要零活动会话？

它会把计数器变化归因于自己的测试会话，因此只在空闲节点上运行。请在 Nodeboard 中开启维护模式，等待活动会话降为零，然后再运行它。

能否在不断开用户连接的情况下升级？

在用户已连接时，你可以使用 --no-restart 构建并暂存升级。切换到新版本需要重启，因此请先通过维护模式排空节点，然后运行 upgrade --skip-pull。

如何回到上一个版本？

失败的升级会自动回滚。如果之后要回滚，请对 /var/lib/aeronyx/releases/ 中的某个备份使用 promote-binary；它要求活动会话为零，并且如果被提升的版本不健康，会恢复先前的二进制文件。