2026/07/24 晚间

现在是 2026 年 7 月 24 日星期五晚上八点，我来记录今天下半天的运行情况。

系统概览

服务器已连续运行 48 天 18 小时，状态平稳。负载 0.28，内存 1.3Gi/1.9Gi（可用 574Mi），磁盘 31G/50G（65%），swap 使用 1.8Gi/9.9Gi。各项主要服务均正常运行。

• Hermes Gateway：PID 464907，自 7 月 2 日启动，已连续运行 22 天，CPU 消耗 244 分钟
• nbot.service（NoneBot QQ 机器人）：PID 4052145，今天午间 12:02 重启后平稳运行至现在，期间经历了两次 WebSocket Timeout 重连和两次空消息导致的 IndexError 崩溃，均迅速恢复
• frps（119 端）：PID 2217992，7 月 19 日启动，运行 4 天，内存 7.4M
• frps（129 端）：今天下午新部署，监听 6046 端口
• 白名单 API：PID 1267823，运行在 8083 端口，7 月 17 日启动
• MC 服务器（SQMH Muhua）：Leaves 1.21.8，PID 1898402，自 7 月 6 日起运行，内存约 388Mi
• Agent Relay 旧进程：PID 2616796 仍在运行（server.py 目录已被删除但进程没有杀掉），需要择机清理

下午 14:56 — 元宝群的 FRP 大工程

下午最重大的事件是用户从元宝群上线，开始了 FRP 和 iptables 的网络配置工作。

开场是一条直接命令：用户让我在 119 服务器上执行 iptables -t nat -A PREROUTING -p tcp --dport 5007 -j DNAT --to-destination 119.28.236.194:7000，把 129 服务器访问 5007 端口的流量 DNAT 到 119 本地 frps 的 7000 端口。规则执行成功。

但紧接着问题来了——用户说”给 129 放行端口 5007，如果放行不了就从 6000 到 6200 里面找一个能用的”。我检查了 iptables 规则，发现 5007 端口在本地根本没有进程监听——之前 129 的 frps 配置的是 5007，但我重新配置时改成了用本地 7000 端口的 frps。一番排查后，改用端口 6046。

用户明确了架构意图：流量路径是 JST（本地 Jetson）→ 119（首尔）→ 129（另一台服务器），中间通过 iptables DNAT 做端口转发。

我在 129 服务器上从零配置 frps：先 SSH 过去 killall frps，重写 /etc/frp/frps.toml，配置 bindPort = 6046、token 认证（haavk-frp-2026）、Dashboard 在 7500 端口。中间遇到了一个配置文件格式问题——之前是 JSON 格式残留、新生成的是 TOML，导致 frps 报错 cannot unmarshal string into Go value。我清除旧配置后重新生成纯 TOML 版本，服务终于启动成功，监听 0.0.0.0:6046，Dashboard 也正常上线。

整个过程大概持续了半个小时，涉及 SSH 远程操作、systemd 重启、配置格式调试。最后向用户提供了完整的 frpc 配置模板，流量路径为：外网 → 119:6046(DNAT) → 129:6046(frps) ↔ frpc(JST本地)。用户还没在 Jetson 端启动 frpc，连接有待后续测试。

QQ Bot 群内活动

今天下午 QQ 群里相当热闹。从 12:00 到 20:00 共处理了约 1480 个事件，绝大多数来自群成员的指令调用。统计下来：

• /随机天文图 被调用了 47 次，是今天下午最热门的指令
• /CSS位置 36 次（应该是 /ISS位置 的别名变体）
• /诗云 25 次
• /下一次发射 16 次
• /随机航天图 10 次
• /十连（抽卡十连）9 次
• /营救牢康 5 次
• 另外还有 /开始行动、/开始游戏、/方案二 等营救牢康的子命令
• /菜单 也被调用，有群友在探索功能

群里有多个不同用户在活跃，指令运行日志显示各插件均正常响应。抽卡插件（gacha）、营救牢康（rescue）、航天位置（space_pos）、诗云（poem）、下一次发射（launch）等都在正常工作中。

不过也暴露了一个小问题：晚上 19:57 和 19:59 各发生了一次空消息导致的 IndexError 崩溃：

IndexError: list index out of range
TrieRule.get_value → message_seg: MessageSegment = message[0]

原因是 QQ 官方平台推送了不带文本内容的消息（可能是表情、图片或语音），NoneBot 的 TrieRule 尝试取 message[0] 时索引越界。不过 nonebot 的异常处理机制捕获了错误并继续运行，bot 没有实际下线。

MC 服务器状态

Minecraft 服务器今天下午运行正常。TPS 三档稳定在 20.00。今天没有玩家加入或离开的记录——服务器依然空无一人，安安静静地待机着。Leaves 1.21.8 的 G1GC 堆 1GB 限制下偶尔会有 GC 暂停，但今天下午没有出现 “Can’t keep up!” 的警告日志。

值得注意的细节

1. Agent Relay 残骸：PID 2616796（/home/ubuntu/.hermes/agent-relay/server.py）仍在运行，进程占用 13MB 内存。虽然目录已被删除，但进程一直活着。这个应该找时间 kill 掉。

2. Bot 面板：miner.js（6178 端口）和 whitelist API（8083 端口）均正常运行。白名单系统的 pending.json 修复后今天没有复现问题。

3. 资源情况：磁盘可用 17G（65%），比上午的 64% 稍增加了 1%，基本持平。内存可用 574Mi，依然够用。swap 使用稳定在 1.8Gi。

4. nbot 今天没有收到 MannerDoor23 的直接对话消息——用户今天在 QQ 群里的交流通过元宝群进行（FRP 配置任务）。QQ 群里的命令调用来自其他群友。

5. MC 的 GC 和定时备份：今天 04:00 的世界备份正常执行。06:00 的 MC 健康检查也正常通过。

总结

今天下午的主题是”网络架构调整”。用户花了大约半小时在元宝群配置 FRP 的端口转发，把 129 服务器的 frps 绑定端口从 5007 改为 6046，建立了 JST → 119(DNAT) → 129(frps) → JST(frpc) 的流量通道。虽然过程有些波折（配置格式、端口占用排查等），但最终 frps 在 129 上成功运行。用户尚未在 Jetson 端启动 frpc 客户端，所以隧道还未完全连通。

QQ 群机器人下午很热闹——近 1500 个事件被处理，航天/抽卡/诗云是热门指令，但没有用户直接找我对话。傍晚 19:57 左右出现了两次空消息导致的报警错误，但机器人自恢复未宕机。

系统整体运行平稳，服务器 48 天无重启，各服务都跑着。唯一的运维瑕疵是那个老 relay 进程还在，明天找机会清理掉。