机器人能跑起来不算本事，能连续跑几个月不挂才是。这篇是半年多的运维总结，7 条经验，每条都是踩过坑之后加上的。

1. 给容器加内存上限

不加限制的话，NapCat 会随着运行时间慢慢吃内存。1核2G 的服务器，一次 OOM 就能把 MySQL、Nginx 一起带走。

docker run -d --name napcat 
  --restart=always 
  -m 400m --memory-swap 600m 
  ...

400MB 是实测够用的值（实际占用 200MB 左右，留一倍余量）。如果同一台机器还跑着数据库和网站，可以再压到 300MB。

2. 日志轮转必须做

这是最容易被忽略、后果最严重的一条。Nginx 的 access.log 在流量大或者被扫描的时候，一天就能长到几百 MB。我的服务器上曾经有一个日志文件涨到 883MB。

cat > /etc/logrotate.d/nginx-custom << 'EOF'
/path/to/your/site.log {
    daily
    rotate 3
    missingok
    notifempty
    compress
    delaycompress
    size 10M
    copytruncate
}
EOF

copytruncate 很关键 —— 不重启 Nginx 就能截断日志，避免 reload 打断连接。

3. 不要频繁扫码

这条是血泪教训。QQ 对「频繁异地登录」「频繁扫码」非常敏感，触发风控后可能直接要求验证，甚至短期封号。

正确做法：

• 能「快速登录」就不要扫码
• 登录态一定要持久化，减少重登次数
• 不要为了测试反复重启容器
• 必要时固定服务器 IP，不要频繁更换

4. 数据卷必须挂载

两个目录，缺一不可：

-v /root/napcat/config:/app/napcat/config      # 配置文件
-v /root/napcat/qq-data:/app/.config/QQ        # QQ 登录态

第二个经常被漏掉。漏了它，每次重建容器都要重新扫码 —— 然后你就触发了第 3 条的风控。

5. 重启策略和开机自启

--restart=always

就这一行，能省掉半夜被动维护。服务器重启、Docker 重启、容器崩溃，都会自动拉起。

另外确认 Docker 本身开机自启：

systemctl is-enabled docker

6. 怎么知道它挂了

机器人掉线是静默的 —— 它不会通知你，只有别人发消息没回应你才知道。

三个层次的监控：

1. 端口探测：定时 curl 本机 3001，返回非 000 就算活着
2. 消息心跳：客户端定期发一条测试消息，超时就告警
3. WebUI 状态：有条件的读取 WebUI 的登录状态接口

最简单的做法是写个 cron：

*/5 * * * * curl -m 3 -s -o /dev/null http://127.0.0.1:3001 || echo "napcat down" | mail -s "告警" you@example.com

7. 升级要谨慎

NapCat 更新频率不低，但不是每次更新都值得跟。

• 升级前先记录当前镜像 tag，必要时 docker commit
• 大版本更新前，看 release notes 有没有破坏性改动
• QQ 客户端版本和 NapCat 版本有对应关系，不要单独升其中一个

回滚方案：

docker stop napcat && docker rm napcat
docker run -d --name napcat ... 旧版本镜像:tag

一张清单

相关文章

• 还没搭起来 →《QQ AI 机器人搭建教程：NapCat + OneBot 完整部署指南》
• 连不上怎么查 →《QQ 机器人掉线排查：OneBot WS 连不上的 6 个真实原因》

最后

这套东西的稳定性，80% 取决于最开始部署有没有做对 —— 挂载、内存限制、重启策略。剩下 20% 是遇到问题时知道怎么查。