1. Clawdbot 是什么为什么有人想买 Mac Mini1.1 Clawdbot 到底帮我们解决了什么问题先说结论Clawdbot 是一个常驻运行的对话机器人服务。它的底层思路很简单把大模型平台的 API 能力封装成一个可以随时交互的入口你可以在网页里跟它聊也可以通过聊天工具的机器人接口把它拉进群让它帮你总结资料、写文案、跑定时任务。很多人第一次接触它是因为想给自己搭一个“私人大模型助手”但又不想每次都打开网页版对话窗口于是希望有一个 7x24 小时在线的服务随时响应。这个需求听起来不大但落地时有个很现实的问题你需要一台永远不关机的机器。于是社区里流传最广的方案就是买一台 Mac Mini 放在家里。Mac Mini 确实体积小、功耗低、噪音小放在桌面上很合适但价格不便宜而且它本质上只是一台普通电脑跑 Clawdbot 需要的资源远没有你想象中那么多。我见过不少朋友为了一个轻量机器人先花了小几千元买硬件结果机器买回来配置跑满了不到 10%大部分时间都在闲置。这篇文章想做的事就是把 Clawdbot 从“本地小主机”里解放出来直接放到云主机上跑。你不需要买任何新硬件也不需要维护家庭网络只要租一台按月的云服务器就能获得更好的公网访问体验。适合的人群很明确想玩 Clawdbot 但不想提前投入硬件成本的人已经买了服务器但不知道怎么部署的人以及希望机器人能被朋友正常访问、而不是只在局域网里自嗨的人。1.2 本地小主机 vs 云端小主机差别在哪为了把问题说清楚我列了一张对比表你可以根据自己的情况对号入座。对比维度本地 Mac Mini云端云主机前期投入硬件整机一次性成本高按月付费最低配即可起步运行环境依赖家里供电和网络断电断网即下线机房托管供电和网络由服务商保障公网访问需要额外配置内网转发、域名解析自带公网 IP天然可访问带宽质量受家庭宽带上下行限制固定带宽访问质量相对一致数据安全硬盘坏了损失靠自己可通过快照、异地备份降低风险维护自由度硬件自管坏了要自己修系统级重启、重装都很方便看完这张表你应该能理解为什么我说 Mac Mini 不是必需品。Clawdbot 这类项目对 CPU 的要求很低对内存要求也不算高真正影响体验的是三件事能不能一直运行、能不能被外部访问、出了问题容不容易恢复。这三点恰好都是云主机的优势区。你不需要追求高配置一台低配云主机就足够把 Clawdbot 跑得稳稳当当。1.3 云端部署的整体思路整篇教程可以压缩成一条主线在云主机上安装运行环境把 Clawdbot 项目拉下来填好配置让系统在进程崩溃时自动拉起最后打开一个公网入口让外部能访问。这条主线分四步走准备服务器、部署服务、配置守护、暴露入口。后面的章节完全是按照这个顺序展开的。我建议你按顺序操作不要跳步。尤其是“守护进程”这一步很多人图省事跳过结果服务一跑起来就遇到“关掉 SSH 窗口后服务也消失”的问题反而浪费更多时间。2. 动手之前先把准备工作做扎实2.1 云主机怎么选不想多花冤枉钱云主机选型这件事我见过太多人犯同一个错误一上来就买高配。其实 Clawdbot 用不到 8 核 16G那个配置是留给大型网站或数据处理任务的。我的建议非常直接2 核 CPU、4G 内存、40G 以上硬盘带宽按 3M 到 5M 起步已经足够。这个配置可以同时跑着 Clawdbot、Nginx 和几个辅助脚本日常剩余资源还很宽裕。系统镜像优先选 Ubuntu 22.04 LTS 或者 Debian 12。原因不是它们比别的系统高到哪里去而是社区资料多、软件源完整你遇到问题时搜到的解决方案大概率就是基于这两个系统写的。地域选择要看你的使用场景如果你和你的朋友访问主要在国内就选国内机房如果你的使用群体分散在海外就选海外机房。这一条直接决定了你打开 Clawdbot 管理页面的等待时间也影响它调用外部大模型接口的响应速度。还有一个很多人忽略的细节云主机的公网端口通常默认不全部开放。不同厂商的安全组规则不一样有的只开 22 端口有的默认全开。别等到服务跑起来才发现外部访问不了第一步就把安全问题处理掉。2.2 密钥、域名和消息平台入口动手部署之前先把下面这些信息准备好免得中途到处找大模型平台的访问凭证通常是一串类似sk-xxxx的密钥。它代表你有权限调用模型接口也直接和账单挂钩。聊天工具的机器人凭证。如果你计划把 Clawdbot 接入群聊需要预先在对应平台创建一个机器人拿到 Token 或 Webhook 地址。一个域名。这一步可选但推荐尤其是以后想上 HTTPS、想给朋友分享的时候域名几乎是必需品。记得提前把域名解析到云主机的公网 IP。关于密钥我必须多说一句永远不要把这类凭证硬编码进代码也不要随手截图发到聊天群。我看过太多“账单爆炸”的案例原因都是密钥泄露后被别人拿去疯狂调用。正确做法是全部放到环境变量文件里并且把这个文件加入忽略规则不让它进入版本管理。2.3 本地终端与 SSH 准备Clawdbot 的部署全程基本在命令行里完成所以你不需要安装任何花哨的图形管理工具。Windows 用户可以用系统自带的 OpenSSH或者装一个轻量 SSH 客户端只要支持保存主机、复制粘贴命令就已经够了。macOS 和 Linux 用户直接用终端即可。这里唯一需要提醒的是复制粘贴命令的时候要留意命令里可能隐藏的换行符或者多余空格尤其是密钥和环境变量一旦沾上不可见字符服务起来后会出现各种奇怪的鉴权报错。后面排查章节我会再提一次。3. 保姆级部署实操两种方式任选3.1 登录服务器后的基础初始化拿到云主机之后第一步是用 SSH 登录。如果你买的是按量付费的主机厂商一般会给你初始 root 密码或密钥对按流程登录进去即可。ssh root你的服务器IP登录成功后先把系统软件包更新到最新。很多新人跳过这一步结果后面装依赖时碰到版本冲突浪费大量时间。apt update apt upgrade -y接下来装一组常用工具apt install -y curl git wget unzip vim到这里我建议你顺手创建一个普通用户日常操作不要一直用 root。这既是为了安全也是为了让后面的项目文件归属更清晰。我用deploy这个用户名做示例adduser deploy usermod -aG sudo deploy项目代码建议放在/home/deploy/apps/clawdbot目录下目录归属给deploy用户。后续 systemd 服务也会用这个用户来运行权限范围能收多小就收多小。3.2 方式一Docker Compose 一键部署如果问我自己用哪种方式我会毫不犹豫选 Docker。原因很简单依赖隔离足够干净升级和回滚都方便不需要担心系统环境被项目依赖搞乱。先确认机器上有没有 Dockerdocker --version如果没有用官方脚本安装curl -fsSL https://get.docker.com | sh systemctl enable docker systemctl start docker然后在项目目录里新建一个docker-compose.yml内容大概是这样的version: 3.8 services: clawdbot: image: your-registry/clawdbot:latest container_name: clawdbot restart: unless-stopped env_file: - .env volumes: - ./data:/app/data ports: - 127.0.0.1:3000:3000这个配置里有几个地方要重点说明。端口我故意写成127.0.0.1:3000:3000而不是0.0.0.0:3000:3000。这样容器的 3000 端口只在服务器本机可见外部流量必须经过后面的 Nginx 统一入口等于多了一层访问控制避免 Clawdbot 裸奔在公网上。卷挂载把宿主机的./data对应到容器的/app/data机器人的聊天记录、用户数据都往这个目录写。以后升级容器数据不会丢。restart: unless-stopped的意思是只要容器不是被人手动停掉服务器重启或者进程崩溃它都会自动恢复。这个策略对常驻服务非常友好。配置写好后一行命令启动docker compose up -d查看运行状态和日志docker compose ps docker compose logs -f --tail100 clawdbotDocker 方式还有一个额外好处以后升级版本只需要两步。docker compose pull docker compose up -d不需要重新装依赖不需要手动清理旧文件风险非常低。3.3 方式二源码裸跑不用 Docker如果你对 Docker 比较抵触或者服务器内存紧张想省掉一层容器开销那可以直接用进程管理方式跑源码。先确认机器上有 Node.js 环境Clawdbot 这类项目通常依赖 JavaScript 技术栈node -v npm -v如果是 Python 项目则检查 Python 版本python3 --version然后把项目代码拉到服务器cd /home/deploy/apps git clone 项目仓库地址 clawdbot cd clawdbot cp .env.example .env vim .env接下来Node 项目执行npm install npm run build # 如果项目是 TypeScript 写的需要这一步 npm run startPython 项目通常这样python3 -m venv .venv source .venv/bin/activate pip install -r requirements.txt先用前台方式跑一次确认日志正常、接口能访问然后再按下 CtrlC 停掉进入下一节配置守护。这里要特别强调裸跑模式下如果你不用 systemd 之类的方式托管进程一旦挂掉没有任何机制帮你恢复。所以源码方式必须配合后面的守护配置。3.4 环境变量配置逐项拆解不管用哪种部署方式最终都要填一份环境变量配置。我拿最常见的.env文件举例API_KEYsk-xxxx API_BASEhttps://api.example.com/v1 MODEL_LISTmodel-a,model-b BOT_NAMEClawdbot PORT3000 DATA_DIR./data TZAsia/Shanghai逐项解释API_KEY调用大模型平台接口的密钥。这是整个配置里最关键的一项不要填错也不要泄露。API_BASE接口地址。大部分情况用默认地址即可如果你要接兼容接口可以改成自己的服务地址前提是确认对方服务可信且合规。MODEL_LIST允许使用的模型清单多个模型用英文逗号分隔。建议不要一次列太多模型越多后续排查越容易迷糊。BOT_NAME机器人的名字会出现在对话和日志里。PORT服务监听端口。必须和 docker-compose 里暴露的端口保持一致也要和后面 Nginx 配置里的转发地址保持一致。DATA_DIR数据保存目录。TZ时区。这段配置特别提醒如果设了定时任务时区不对会导致任务提前或延后一小时。国内用户统一用Asia/Shanghai即可。提示无论用哪种方式都不要把.env提交进代码仓库。在.gitignore里把.env和data/目录都忽略掉这是最基本的自我保护。4. 进程守护与开机自启让服务摔不死4.1 新手最常见的“一关终端就没了”很多第一次玩服务器的人会遇到这个怪现象在终端里启动服务一切正常浏览器里也能访问但只要一关掉 SSH 窗口过一会儿再访问服务就没了。原因在于直接在当前终端启动的进程会被挂在当前会话下面会话退出时进程收到系统信号默认就会被终止。解决这个问题的初级做法是用后台运行命令让进程脱离终端会话。但这样还不够如果某个依赖崩了进程异常退出没有人把它重新拉起。真正适合常驻服务的方案是用 systemd 把进程变成系统托管的服务统一管理启动、重启、日志和资源限制。4.2 用 systemd 接管服务以源码裸跑为例在/etc/systemd/system/clawdbot.service里写一个服务单元文件[Unit] DescriptionClawdbot Service Afternetwork.target [Service] Userdeploy WorkingDirectory/home/deploy/apps/clawdbot EnvironmentFile/home/deploy/apps/clawdbot/.env ExecStart/usr/bin/node /home/deploy/apps/clawdbot/dist/index.js Restartalways RestartSec5 LimitNOFILE65535 [Install] WantedBymulti-user.target这里有几个参数值得展开说。Restartalways是核心。它告诉 systemd不管服务以什么方式退出都尝试重新拉起。这里要注意它不是解决“服务本身因为配置错误反复崩溃”的而是保证任何一次偶发退出都有自动恢复的机会。RestartSec5表示重启前等 5 秒。这个参数很有用如果服务启动后立刻失败没有等待间隔就会陷入高频率重启日志刷得飞快系统负载也会被拉高。EnvironmentFile指定环境变量文件路径。服务启动前 systemd 会自动加载这个文件你就不用担心进程里读不到配置。LimitNOFILE提高文件句柄数上限。机器人跑久了连接数一多默认限制可能不够表现就是日志里出现 “EMFILE” 之类的报错。写完文件后执行下面的命令让它生效并开机自启sudo systemctl daemon-reload sudo systemctl enable --now clawdbot sudo systemctl status clawdbot查看实时日志用sudo journalctl -u clawdbot -f到这一步就算服务器整机重启Clawdbot 也会自动跟着起来不再需要任何人手动登录去敲启动命令。4.3 容器模式下的守护方案如果你用的是 Docker 部署其实restart: unless-stopped已经解决了一部分自启问题。但为了让服务的管理方式更统一、日志更好查我建议再写一个简单的 systemd 服务把 Docker Compose 包一层。单元文件如下[Unit] DescriptionClawdbot Container Requiresdocker.service Afterdocker.service [Service] WorkingDirectory/home/deploy/apps/clawdbot ExecStart/usr/local/bin/docker compose up ExecStop/usr/local/bin/docker compose down Restartalways RestartSec10 [Install] WantedBymulti-user.target这样做的价值在于你不需要为了重启服务去记一长串 docker 命令直接用systemctl restart clawdbot就行整体操作习惯保持一致。而且 systemd 会把重启状态反馈得清清楚楚方便监控。4.4 定时备份和数据安全服务跑起来只是开始数据安全才是常驻项目里最容易忽略的部分。Clawdbot 的data目录里会积累聊天记录、用户配置如果服务器被重置或者硬盘损坏这些数据就没了。我的习惯是写一个很简单的备份脚本每天执行一次。#!/bin/bash BACKUP_DIR/home/deploy/backups mkdir -p $BACKUP_DIR tar czf $BACKUP_DIR/clawdbot_$(date %Y%m%d_%H%M%S).tar.gz -C /home/deploy/apps/clawdbot data .env find $BACKUP_DIR -type f -mtime 14 -delete脚本做的事情很简单把data目录和.env配置打包文件名带时间戳同时清理 14 天前的老备份。然后加入 crontabcrontab -e 0 3 * * * /home/deploy/scripts/backup_clawdbot.sh每天凌晨 3 点跑一次。备份这件事听起来很朴素但在关键时刻它可能是唯一的后悔药。5. 公网访问与安全加固从自己玩到可分享5.1 先想清楚要不要暴露公网如果你只是自己本地测试不需要做这一步。但大多数人的目标是让 Clawdbot 能接进消息平台或者发给朋友一个链接直接使用。这时候公网可达就成了硬需求。好消息是云主机天然有公网 IP这比本地部署简单太多。你不需要依赖家里路由器的各种端口设置也不用为动态 IP 发愁。需要做的只是在云主机上配置好入口然后通过安全措施把它保护起来。5.2 Nginx 统一入口配置我前面故意把 Clawdbot 的 3000 端口限制在服务器本机访问就是为了在这里用一个统一入口转发流量。Nginx 适合干这个活先安装它apt install -y nginx然后新建一个站点配置路径为/etc/nginx/sites-available/clawdbot.confserver { listen 80; server_name bot.example.com; location / { proxy_pass http://127.0.0.1:3000; proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection upgrade; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_read_timeout 300s; } }注意看我特意加的Upgrade和Connection两个头。这两行是给 WebSocket 长连接用的。Clawdbot 的部分交互模式依赖这种长连接如果不加前端会出现连接一会儿就断、页面莫名其妙掉线的情况。只处理普通 HTTP 请求时可以不加但加上也无害所以建议保留。启用配置ln -s /etc/nginx/sites-available/clawdbot.conf /etc/nginx/sites-enabled/ nginx -t systemctl reload nginx到这一步访问http://bot.example.com如果能看到页面链路就通了。5.3 用免费证书把 HTTPS 补上没有 HTTPS 之前浏览器地址栏会提示不安全更关键的是很多浏览器已经限制一部分接口能力在非 HTTPS 环境下使用。所以证书不是锦上添花而是功能完整性的基础。我习惯用 acme.sh 来自动申请和续期证书。安装很简单curl https://get.acme.sh | sh如果你的域名 DNS 已经解析到服务器可以通过 HTTP 方式验证域名归属~/.acme.sh/acme.sh --issue -d bot.example.com --nginx签发成功后把证书安装到 Nginx 使用的目录~/.acme.sh/acme.sh --install-cert -d bot.example.com \ --key-file /etc/nginx/ssl/bot.example.com.key \ --fullchain-file /etc/nginx/ssl/bot.example.com.pem \ --reloadcmd systemctl reload nginx接着在 Nginx 配置里补上 443 端口监听并添加一个 80 端口跳转让所有 HTTP 流量自动跳到 HTTPS。acme.sh 自带续期任务默认会自动续之后基本不需要人工干预。5.4 安全组、防火墙和最小暴露原则很多服务器买回来默认只开了 22 端口。如果你发现 80 和 443 访问不了第一反应应该是去云厂商控制台看安全组规则而不是反复重启 Nginx。服务器内部也要用防火墙主管。Ubuntu 自带 UFW配置起来非常直接apt install -y ufw ufw allow 22/tcp ufw allow 80/tcp ufw allow 443/tcp ufw enable这里我没有放行 3000 端口因为 Clawdbot 只应该通过 Nginx 对外提供服务。如果你需要远程调试可以用 SSH 隧道把本地端口映射到服务器而不是直接把业务端口暴露出来。最小暴露原则永远是安全的第一条底线。5.5 接入消息平台的可选玩法Clawdbot 最有意思的部分是接进聊天工具。你可以创建一个机器人账号把它拉进工作群然后让群里的人直接 它提问。这样它就不再是一个“网页玩具”而是一个真正能提高效率的协作工具。接入方式通常很标准在平台后台创建一个机器人拿到 Token 或 Webhook 地址填进.env对应字段然后重启服务。这里有两个常见坑一是平台要求的回调地址必须和实际部署的路径完全一致二是部分平台要求服务器 IP 白名单。建议先在平台后台把回调地址配置好再启动 Clawdbot启动后故意发一条测试消息观察日志里有没有收到回调记录。6. 常见问题排查与实操避坑6.1 服务进程活着却访问不了这种问题最让人头疼因为表面上服务状态是正常的。排查时我建议从本机开始一层一层往外查curl -I http://127.0.0.1:3000如果这一步不通说明服务进程本身没有监听正确去看日志。如果通了再查 Nginx 的转发目标curl -I http://127.0.0.1这一步不通说明 Nginx 配置有问题。本地链路都通了再访问公网域名。公网不通时依次检查域名解析、安全组规则、服务器防火墙。记得从最近一层往回查而不是乱猜。6.2 大模型接口频繁超时Clawdbot 运行得好好的但对话回复特别慢甚至经常超时问题大概率出在服务器到外部大模型接口之间的网络路径质量。你可以手动敲一条 curl 测试一下接口延迟curl -w 耗时: %{time_total}s\n -o /dev/null -s https://api.example.com/v1如果延迟明显偏高或者丢包严重不要纠结于调程序参数。更有效的做法是调整云主机的机房地域让服务器和目标接口之间的路径更短。在错误的方向上反复调配置只会浪费更多时间。6.3 鉴权报错、余额没扣日志里频繁出现 401 或 403大概率是密钥问题。首先检查.env文件里有没有复制到多余空格有些编辑器还会在行尾添加不可见字符。然后确认账号有没有余额、有没有开通对应模型权限。最简单的方式是用 curl 直接调一次接口用同样的密钥手动发一个请求。如果 curl 都失败说明问题根本不在 Clawdbot而是凭证本身失效或者权限不足。6.4 内存和性能问题Clawdbot 本身不重但如果你同时开了定时自动抓取、多会话长期记忆这些功能内存会慢慢涨。建议在 systemd 单元文件里加资源限制MemoryHigh3000M MemoryMax3500M如果已经出现进程被杀的问题可以考虑给服务器加一块交换分区作为应急手段fallocate -l 4G /swapfile chmod 600 /swapfile mkswap /swapfile swapon /swapfile echo /swapfile none swap sw 0 0 /etc/fstab交换分区不能当作主力但它能让进程在突发负载下多撑一会儿。6.5 升级后功能失效我遇到过几次用 Docker 拉新镜像升级结果原来能用的功能突然失效。排查下来发现是项目版本更新后新增了必填的环境变量旧的.env里没有补齐。所以升级前一定要先看版本发布说明把旧配置和新默认配置做一个对比缺什么补什么。升级完用日志看第一屏输出错误原因通常就写在第一屏。6.6 排查速查表症状可能原因先查什么服务启动即退出依赖缺失、端口被占用服务日志最后 50 行端口监听状态能访问但回复很慢外部接口响应时间长手动 curl 计时观察 DNS 解析耗时公网访问不了安全组、防火墙、Nginx 配置本机 curl 先通再看公网链路定时任务没执行时区不对、任务格式错误手动执行脚本检查系统时间HTTPS 证书过期自动续期失败查看证书申请日志手动续期一次这张表不能覆盖所有问题但能帮你把排查范围快速缩小。7. 跑了一段之后的个人建议我在正式用云主机跑 Clawdbot 之前也一度觉得本地硬件方案更省心。后来真正折腾完才发现这类项目的瓶颈从来不是电脑配置而是有没有一台 7x24 小时有人照看的机器。云主机的灵活性是本地小主机很难替代的出问题可以重置系统硬盘不够可以扩容数据可以做快照不需要自己跟硬件故障搏斗。如果你还没跑通我建议不要一上来就追求复杂部署。先用最低配云主机、用 Docker 把它跑起来用自己的秘钥账号先做一个最小可用对话再把消息平台、HTTPS、定时任务一个一个往上加。做成了之后再考虑迁移到更好的服务器迁移成本非常低。还有一个小技巧尽量把每个入口独立配置。网页入口一个路径消息平台机器人一个回调地址定时任务单独一个开关。这样出了问题不用关停整个服务只要顺着对应入口去查日志就行。我自己就是从“全功能一锅烩”改成“入口隔离”之后维护体验才明显改善的。把这句话送给准备入坑的朋友先跑起来再谈优化。不要在选型上纠结太久Clawdbot 不会在意它住在哪台机器上只要它能稳定运行、能被你随手调整、数据不丢就是一个好家。