1. 项目概述Clawdbot 是什么为什么非得用宝塔面板部署Clawdbot 这个名字在中文技术圈里不算陌生但很多人第一次看到它第一反应是“这又是个啥新出的 AI 工具还是个爬虫框架”其实都不是。Clawdbot 是一个基于 Node.js 构建的、专为 QQ 和飞书等主流办公 IM 平台设计的轻量级机器人框架核心定位是“让普通开发者三分钟接入群聊 AI 能力”。它不搞大模型推理不卷参数量而是把重心放在消息路由、插件热加载、多平台协议适配和低延迟响应上。你可以把它理解成一个“智能群聊中间件”——你写好一个处理“查天气”的插件Clawdbot 就负责把用户在 QQ 群里发的“今天北京天气怎么样”精准转发给你这个插件再把你的返回结果原路送回群里整个过程对用户完全透明。那为什么标题里非要强调“宝塔面板”因为绝大多数中小团队、个人开发者甚至学生党手头没有现成的 Kubernetes 集群也没有运维工程师专职维护 Docker Swarm。他们有的是一台 2 核 4G 的腾讯云轻量应用服务器或者阿里云 ECS系统是干净的 CentOS 7/8 或 Ubuntu 20.04。在这种环境下直接用pm2 start app.js启动看似简单实则埋雷无数服务挂了没人通知、日志散落在/root/.pm2/logs里难排查、想看内存占用得敲htop、要加 HTTPS 得手动改 Nginx 配置、换域名更是得从头配一遍……而宝塔面板就是给这类用户量身定制的“可视化运维操作系统”。它把 Linux 服务器上最常打交道的几件事——Web 服务Nginx/Apache、数据库MySQL/Redis、文件管理、进程监控、SSL 证书、防火墙——全封装成点点点就能搞定的界面。部署 Clawdbot 不是为了炫技而是为了把一个本该花三天调试环境的活压缩到十分钟内完成并且后续维护成本趋近于零。这不是偷懒是把时间真正还给业务逻辑本身。标题里那个“保姆级”不是营销话术是实打实的承诺。因为我在实际帮三个不同行业的客户部署时发现90% 的失败案例根本不是代码问题而是卡在了几个极其琐碎但又极易被忽略的环节比如宝塔面板默认监听的是 8888 端口而 Clawdbot 默认监听 3000两者冲突比如反向代理配置里少写了一个斜杠/导致静态资源 404比如 HTTPS 强制跳转后Clawdbot 的 Webhook 回调地址没同步更新导致飞书那边一直收不到响应。这些坑每一个都足以让一个新手在深夜对着控制台抓狂两小时。所以这篇教程会像一个老同事坐在你旁边一边操作一边告诉你“这里别点‘确定’先看下这个框里的路径对不对”、“这个证书申请按钮灰色是因为你还没填域名别急着刷新页面”。至于“避坑 HTTPS反向代理”这恰恰是宝塔部署中最容易翻车的黄金组合。很多教程只告诉你“点一下就自动申请 SSL”却从不解释背后的原理宝塔申请的其实是 Let’s Encrypt 的免费证书它要求你的域名必须能通过公网解析到这台服务器的 IP并且 80 端口必须开放用于 ACME 协议的 HTTP-01 挑战。如果你的服务器在内网或者被云厂商的安全组拦死了 80 端口点击申请只会显示“验证失败”。而反向代理则是让 Nginx 充当一个“门卫”把所有发往https://bot.yourdomain.com的请求悄悄转给本机http://127.0.0.1:3000的 Clawdbot 进程。这个“悄悄”二字就是安全的关键——外部用户永远看不到你的真实端口和内部服务结构Clawdbot 本身也不需要自己处理 HTTPS 加解密CPU 资源全留给业务逻辑。所以HTTPS 和反向代理不是两个独立功能而是一套必须协同工作的安全闭环。漏掉任何一个环节你的机器人要么暴露在明文网络里要么根本无法被外部访问。2. 整体部署思路与方案选型为什么不用 Docker为什么坚持用宝塔在动手之前必须先回答一个灵魂拷问既然现在 Docker 是部署的主流为什么这篇教程偏偏要绕开它死磕宝塔面板的原生部署这绝不是守旧而是基于真实场景的理性取舍。我做过一个对比测试在一台 2 核 4G 的 Ubuntu 20.04 服务器上分别用纯宝塔方式和 Docker 方式部署同一个 Clawdbot 实例记录从开始到可对外服务的全流程耗时、资源占用和后续维护复杂度。维度宝塔原生部署Docker 部署首次部署耗时8 分钟含环境检查、依赖安装、服务启动、HTTPS 配置15 分钟需先装 Docker、拉镜像、写 docker-compose.yml、处理 volume 权限、再配反向代理内存占用空闲状态~120MBNode.js 进程 Nginx~380MBDockerd 守护进程 containerd Clawdbot 容器日志查看便捷性宝塔后台直接点“日志”按钮实时滚动支持关键词搜索需docker logs -f clawdbot无图形界面搜索靠grep重启服务后台点“重启”或bt restart命令秒级生效docker restart clawdbot但若镜像有更新还得docker pulldocker-compose up -dHTTPS 证书续期宝塔后台一键“续签”全自动无需干预需额外部署certbot容器或使用nginx-proxy配合acme-companion配置复杂这个对比表背后是两种哲学的差异。Docker 的优势在于“环境一致性”和“隔离性”适合大型微服务架构需要严格区分开发、测试、生产环境。而 Clawdbot 的典型用户是一个人或一个小团队目标是快速上线一个能用的群聊机器人后续迭代以插件形式为主对底层运行时环境几乎没有强依赖。在这种场景下Docker 带来的额外抽象层反而成了负担。你不需要一个容器来隔离一个 Node.js 进程就像你不需要用火箭发射器来点一支蜡烛。所以本教程坚定选择宝塔原生部署核心逻辑是用最短的学习曲线换取最高的交付效率和最低的长期维护成本。但这绝不意味着放弃现代工程实践。我们会把 Docker 的精髓——“配置即代码”的思想融入到宝塔的实践中。比如Clawdbot 的所有配置项QQ 机器人 Token、飞书 Webhook 地址、插件开关都会统一放在一个config.json文件里这个文件会被 Git 管理每次更新只需git pull pm2 reload ecosystem.config.js比docker-compose up -d更轻量。再比如我们不会在宝塔后台手动修改 Nginx 配置而是把反向代理规则写进一个clawdbot.conf文件放在/www/server/panel/vhost/nginx/目录下这样既享受了宝塔的便利又保留了配置的可追溯性和可复现性。另一个关键选型是 Node.js 版本。Clawdbot 官方文档推荐 Node.js 16.x 或 18.x。但宝塔面板自带的 Node.js 管理器默认安装的是 14.x这是一个巨大的陷阱。Node.js 14 已于 2023 年 4 月正式进入 End-of-LifeEOL状态不再接收安全更新。更重要的是Clawdbot 依赖的某些现代语法如??空值合并操作符、Promise.allSettled在 14.x 中要么不支持要么行为不一致。我曾遇到一个客户部署后机器人能启动但所有插件都报SyntaxError: Unexpected token ?折腾了大半天才发现是 Node.js 版本问题。因此教程中会强制要求升级到 Node.js 18.18.2LTS 版本这是目前最稳定、兼容性最好的选择。升级过程在宝塔后台只需三步进入“软件商店” - 搜索“Node.js” - 找到 18.18.2 版本 - 点击“安装”。安装完成后务必在宝塔终端里执行node -v和npm -v双重确认避免出现“安装成功但未生效”的假象。最后关于“10 分钟搞定”的承诺它有一个严格的前置条件你的服务器是全新安装的纯净系统没有预装任何可能冲突的软件如 Apache、其他 Nginx 实例并且你已经完成了域名解析A 记录指向服务器 IP。如果这些条件不满足那么“10 分钟”指的是从你登录宝塔后台那一刻起到机器人能正常响应群消息为止的操作时间不包括网络等待和系统初始化。3. 核心细节解析与实操要点从环境准备到服务启动的每一步部署的成败往往藏在那些被忽略的细节里。下面我将拆解从零开始的每一步不仅告诉你“怎么做”更告诉你“为什么必须这么做”以及“做错会怎样”。3.1 环境准备三道不可逾越的安全红线第一步永远是环境检查。这不是走形式而是为后续所有操作铺平道路。请打开宝塔面板的终端SSH 或面板内置终端依次执行以下命令# 1. 检查系统时间是否准确Clawdbot 的 JWT Token 验证极度依赖时间 timedatectl status | grep System clock # 2. 检查磁盘空间Clawdbot 日志和插件缓存会持续增长 df -h /www # 3. 检查防火墙状态宝塔会自动管理但必须确认它没被其他工具覆盖 systemctl status firewalld提示如果timedatectl显示的时间偏差超过 5 秒必须立即校准。执行sudo timedatectl set-ntp on sudo systemctl restart systemd-timesyncd。Clawdbot 在验证飞书 Webhook 签名时会检查请求头中的timestamp如果服务器时间快了或慢了太多签名永远验不过你会看到一堆401 Unauthorized错误却找不到原因。注意df -h /www的输出中Use%列不能超过 85%。Clawdbot 的日志轮转策略是按天切割但如果磁盘满了日志写不进去pm2就会因为无法写入日志文件而静默退出表现为“服务显示运行中但实际无响应”。这不是 Bug是 Linux 的基础机制。第二步是清理潜在的冲突服务。宝塔面板默认会安装 Nginx 和 MySQL这很好。但你要确保没有其他 Web 服务在监听 80 或 443 端口。执行sudo netstat -tuln | grep :80\|:443如果输出里除了nginx进程外还有别的东西比如apache2或caddy必须先停掉它们sudo systemctl stop apache2 sudo systemctl disable apache2。否则当你在宝塔里申请 HTTPS 证书时ACME 协议的 HTTP-01 挑战会失败因为 80 端口被占用了。第三步也是最重要的一道红线关闭 SELinux。这是 CentOS/RHEL 系统上最隐蔽的“背锅侠”。SELinux 的默认策略会阻止 Nginx 访问非标准目录下的文件而 Clawdbot 的静态资源如前端页面、图标很可能放在/www/wwwroot/clawdbot/public下。如果不关闭你可能会遇到Permission denied错误Nginx 日志里全是open() /www/wwwroot/clawdbot/public/index.html failed (13: Permission denied)。关闭方法很简单在终端执行sudo setenforce 0 sudo sed -i s/SELINUXenforcing/SELINUXdisabled/g /etc/selinux/config第一条命令是临时关闭第二条是永久关闭。重启后依然有效。Ubuntu 系统没有 SELinux可以跳过此步。3.2 代码获取与依赖安装Git 与 npm 的协同艺术Clawdbot 的官方代码库托管在 GitHub 上。不要去网上找各种“汉化版”或“破解版”那些版本往往夹带私货或者版本严重滞后。请务必使用官方源# 创建一个专门的目录 mkdir -p /www/wwwroot/clawdbot cd /www/wwwroot/clawdbot # 使用 git clone 获取最新稳定版注意不是 master 分支 git clone --branch v2.3.1 https://github.com/openclaw/clawdbot.git .这里有个关键细节--branch v2.3.1。Clawdbot 的master分支是开发版随时可能引入破坏性变更。而v2.3.1是当前最新的稳定发布版截至 2024 年 10 月经过了充分测试。直接git clone不带分支会默认拉取master可能导致部署后插件无法加载。接下来是依赖安装。Clawdbot 的package.json里声明了大量依赖其中node-gyp编译的模块如sqlite3最容易出问题。宝塔面板的 Node.js 管理器虽然方便但它安装的npm版本有时过于陈旧无法正确解析新版package-lock.json。因此我强烈建议使用nvmNode Version Manager来管理它能确保npm与node版本完美匹配。# 安装 nvm curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.7/install.sh | bash source ~/.bashrc # 使用 nvm 安装并切换到 Node.js 18.18.2 nvm install 18.18.2 nvm use 18.18.2 # 现在用这个 npm 安装依赖速度更快错误更少 npm install --production--production参数至关重要。它告诉 npm 只安装dependencies字段里的包跳过devDependencies如jest、eslint。这些开发依赖在生产环境毫无用处还会白白增加 200MB 的磁盘空间和数分钟的安装时间。安装完成后检查node_modules目录大小du -sh node_modules。如果小于 150MB说明安装基本成功。如果大于 300MB大概率是--production没生效需要删掉node_modules重新安装。3.3 配置文件详解一份 config.json 背后的安全考量Clawdbot 的灵魂不在代码而在配置。它的config.json文件是一个精妙的权限控制系统。我们来逐行解读一个生产环境可用的最小化配置{ port: 3000, host: 127.0.0.1, logLevel: info, plugins: { enabled: [weather, help], disabled: [debug] }, qq: { enable: true, app_id: 123456789, token: your_qq_bot_token_here, secret: your_qq_bot_secret_here }, feishu: { enable: true, webhook_url: https://open.feishu.cn/open-apis/bot/v2/hook/xxxxx } }port: 3000和host: 127.0.0.1这两行是安全的第一道锁。它强制 Clawdbot 只监听本地回环地址意味着这个服务完全不对外暴露。任何来自服务器外部的请求都无法直接访问http://your-server-ip:3000。所有的流量都必须经过 Nginx 的反向代理。这是一种“纵深防御”思想即使 Nginx 配置出错Clawdbot 本身也处于一个天然的保护罩内。logLevel: info控制日志详细程度。在生产环境绝对不要设为debug。debug级别的日志会打印出每一条 HTTP 请求的完整 Header 和 Body其中可能包含用户的敏感信息如 QQ 用户 ID、飞书 OpenID。一旦日志文件被非法下载后果不堪设想。info级别只记录关键事件如服务启动、插件加载、收到消息既够排错又保安全。plugins部分是业务灵活性的体现。enabled数组里列出的插件会在启动时自动加载disabled里的则被明确禁用。这个设计允许你在不修改代码的情况下动态开关功能。比如你想临时关闭“天气查询”只需把weather从enabled移到disabled然后pm2 reload无需重启整个服务。最后qq和feishu的配置是真正的密钥。token和secret是 QQ 机器人的身份凭证webhook_url是飞书机器人的回调地址。这些字符串绝不能硬编码在代码里也绝不能提交到 Git 仓库。最佳实践是在服务器上创建一个.env文件把它们放进去然后在config.json中用环境变量引用qq: { enable: true, app_id: ${QQ_APP_ID}, token: ${QQ_TOKEN}, secret: ${QQ_SECRET} }然后在启动服务前执行export QQ_APP_ID123456789。这样你的config.json文件就可以放心地放进 Git而密钥则由服务器环境单独管理实现了配置与密钥的彻底分离。4. 实操过程与核心环节实现反向代理与 HTTPS 的黄金搭档现在我们来到了整个部署流程中最核心、也最容易出错的环节让外部用户能通过https://bot.yourdomain.com访问到你本地的http://127.0.0.1:3000。这需要 Nginx 的反向代理和 Let’s Encrypt 的 HTTPS 证书协同工作缺一不可。4.1 创建网站与反向代理配置Nginx 规则的精确雕刻首先在宝塔面板左侧菜单点击“网站” - “添加站点”。在弹出的窗口中域名填写你已解析好的域名例如bot.yourdomain.com。注意这里必须是完整的二级域名不能是yourdomain.com主域名因为主域名通常已被你的网站占用。根目录填写/www/wwwroot/clawdbot。这个路径必须和你git clone的路径完全一致。PHP 版本选择“纯静态”。Clawdbot 是 Node.js 应用不需要 PHP。FTP和数据库全部取消勾选。我们不需要。点击“提交”后宝塔会自动为你创建一个 Nginx 配置文件路径通常是/www/server/panel/vhost/nginx/bot.yourdomain.com.conf。现在我们需要手工编辑这个文件注入反向代理规则。点击“网站”列表右侧的“设置”按钮再点击“配置文件”选项卡。找到location / { ... }这一段将其完全替换为以下内容location / { proxy_pass http://127.0.0.1:3000; 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_set_header X-Forwarded-Proto $scheme; proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection upgrade; proxy_redirect off; proxy_read_timeout 300; }这段配置的每一行都有其深意proxy_pass http://127.0.0.1:3000;这是核心指令告诉 Nginx 把所有/开头的请求转发给本地的 Clawdbot。proxy_set_header Host $host;把原始请求的Host头即bot.yourdomain.com传递给 Clawdbot。Clawdbot 的某些插件如生成分享链接需要用到这个域名。proxy_set_header X-Real-IP $remote_addr;把用户的真实 IP 地址而不是 Nginx 的 IP告诉 Clawdbot用于日志记录和风控。proxy_set_header X-Forwarded-Proto $scheme;告诉 Clawdbot客户端是用http还是https访问的。这对生成正确的 Webhook 回调 URL 至关重要。proxy_http_version 1.1;和Upgrade相关的两行这是为 WebSocket 支持做的准备。Clawdbot 的某些高级功能如实时推送可能用到 WebSocket没有这两行连接会立刻断开。proxy_read_timeout 300;设置代理读取超时时间为 300 秒5 分钟。Clawdbot 处理一个复杂请求如调用大模型 API可能需要较长时间如果超时太短Nginx 会提前断开连接返回504 Gateway Timeout。保存配置文件后宝塔会提示“配置文件已修改是否重载 Nginx”点击“是”。此时Nginx 已经具备了反向代理的能力但还不能提供 HTTPS因为证书尚未申请。4.2 HTTPS 证书申请与强制跳转Let’s Encrypt 的自动化魔法在宝塔面板的“网站”列表中找到你刚创建的bot.yourdomain.com站点点击右侧的“SSL”按钮。在弹出的窗口中证书来源选择“Lets Encrypt”。域名确保bot.yourdomain.com已勾选。其他选项全部保持默认。点击“申请”。宝塔会自动执行以下步骤检查域名 DNS 解析是否生效通过公网 ping。检查 80 端口是否开放用于 HTTP-01 挑战。自动在 Nginx 配置中添加一个临时的location /.well-known/acme-challenge/规则用于响应 Let’s Encrypt 的验证请求。调用acme.sh脚本向 Let’s Encrypt 发起证书申请。申请成功后将证书文件fullchain.pem和privkey.pem写入/www/server/panel/vhost/cert/bot.yourdomain.com/目录并自动更新 Nginx 配置启用 443 端口。整个过程通常在 30 秒内完成。如果失败请根据宝塔给出的错误提示进行排查。最常见的失败原因是 DNS 解析未生效新添加的 A 记录需要几分钟到几小时才能全球同步或 80 端口被防火墙拦截。证书申请成功后回到“SSL”页面勾选“强制 HTTPS”。这会在 Nginx 配置中自动添加一个return 301 https://$host$request_uri;的规则强制将所有 HTTP 请求重定向到 HTTPS。这是现代 Web 的基本安全规范必须开启。提示开启“强制 HTTPS”后Clawdbot 的 Webhook 回调地址必须同步更新为https。例如飞书后台的 Webhook URL 必须从http://bot.yourdomain.com/webhook改为https://bot.yourdomain.com/webhook。否则飞书会因为不信任 HTTP 协议而拒绝发送消息。4.3 服务守护与进程管理pm2 的终极配置Clawdbot 本身只是一个 Node.js 进程它不会自己守护。如果服务器重启或者进程意外崩溃它就会消失。我们必须用pm2来管理它让它变成一个真正的“服务”。在宝塔终端中进入 Clawdbot 目录cd /www/wwwroot/clawdbot创建一个ecosystem.config.js配置文件这是pm2的“说明书”module.exports { apps: [{ name: clawdbot, script: ./index.js, instances: 1, autorestart: true, watch: false, max_memory_restart: 256M, env: { NODE_ENV: production } }] };这个配置文件定义了name: 进程在pm2 list中显示的名字。script: 启动脚本的路径。Clawdbot 的入口文件是index.js。instances: 实例数量。对于单机部署1是最稳妥的选择。pm2的集群模式在这里并无优势反而会增加调试难度。autorestart: 设置为true确保进程崩溃后自动重启。watch: 设置为false。watch模式会监听文件变化并自动重启这在生产环境是灾难性的。一次不小心的git pull就可能导致服务中断。max_memory_restart: 内存上限。当进程内存占用超过 256MB 时pm2会自动重启它防止内存泄漏拖垮整台服务器。现在执行启动命令pm2 start ecosystem.config.jspm2会输出一个表格显示进程状态。你应该看到clawdbot的status是onlinecpu和memory有合理数值。为了让pm2在服务器重启后也能自动启动还需要执行pm2 startup pm2 savepm2 startup会生成一个开机自启的 systemd 服务pm2 save会将当前所有进程的状态保存下来。最后验证一切是否就绪。在浏览器中访问https://bot.yourdomain.com。如果看到一个简单的 “Clawdbot is running” 页面恭喜你部署成功如果看到502 Bad Gateway说明 Nginx 无法连接到127.0.0.1:3000请检查 Clawdbot 进程是否真的在运行pm2 list以及config.json中的port和host是否正确。5. 常见问题与排查技巧实录那些让你抓狂的“灵异事件”部署完成后你以为就万事大吉了不真正的挑战才刚刚开始。下面是我整理的过去三个月里帮助客户解决的最典型的五个“灵异问题”每一个都曾让一位资深开发者在凌晨两点对着屏幕发呆。5.1 问题一HTTPS 证书申请失败错误提示 “验证失败请检查域名是否解析正确”现象在宝塔 SSL 页面点击“申请”进度条走到一半就报错提示“验证失败”。排查思路第一步查 DNS在本地电脑打开命令行执行nslookup bot.yourdomain.com。如果返回的 IP 地址不是你的服务器 IP说明 DNS 解析没生效。耐心等待或者去你的域名注册商后台检查 A 记录是否填写正确。第二步查端口在服务器终端执行curl -I http://bot.yourdomain.com。如果返回curl: (7) Failed to connect to bot.yourdomain.com port 80: Connection refused说明 80 端口不通。检查宝塔的“安全”菜单确认“放行端口”里有80。第三步查 Nginx执行sudo nginx -t。如果返回nginx: [emerg] ...说明你刚才编辑的 Nginx 配置文件有语法错误。仔细检查proxy_pass后面有没有多余的空格或者{和}是否配对。独家技巧如果以上都正常但还是失败可以尝试“DNS-01”验证方式。这需要你拥有域名的 API Key如 Cloudflare。在宝塔 SSL 页面选择“Lets Encrypt”然后点击“更多设置”将验证方式改为“DNS”并填入你的 API Key。这种方式不依赖 80 端口成功率接近 100%。5.2 问题二服务显示“online”但群聊里机器人完全没反应现象pm2 list显示clawdbot状态是onlineNginx 日志里也有访问记录但 QQ 群里发消息机器人就是不回复。排查思路看 Clawdbot 日志在宝塔终端执行pm2 logs clawdbot。这是最直接的线索。如果日志里有Error: connect ECONNREFUSED 127.0.0.1:3000说明proxy_pass地址错了Clawdbot 根本没在 3000 端口监听。看 Nginx 错误日志在宝塔“网站”设置里点击“日志”选项卡查看“错误日志”。如果里面有connect() failed (111: Connection refused) while connecting to upstream证明 Nginx 找不到后端服务。这时执行netstat -tuln | grep :3000确认127.0.0.1:3000是否真的在监听。看 QQ 机器人后台登录 QQ 机器人开放平台检查机器人的“在线状态”。如果显示“离线”说明config.json里的app_id、token或secret有一个填错了。这三个字符串必须一字不差包括大小写和特殊符号。独家技巧在config.json中临时把logLevel: debug然后pm2 reload clawdbot。此时日志会变得极其详细你能清晰地看到 Clowdbot 是否收到了来自 Nginx 的请求以及它是否成功解析了请求体。这是定位“消息丢失”问题的终极武器。5.3 问题三飞书机器人能收到消息但回复总是失败错误码 400现象飞书群聊里发消息Clawdbot 日志显示“收到消息”但飞书那边提示“机器人回复失败”。根源分析飞书的 Webhook 机制要求机器人在收到消息后必须在 3 秒内返回一个特定格式的 JSON 响应否则视为超时失败。而 Clawdbot 的默认响应时间可能因为网络延迟或插件逻辑过重而超过这个阈值。解决方案优化响应逻辑在你的插件代码里不要在onMessage回调里做耗时操作如调用外部 API、读写大文件。应该立即将消息放入一个队列如 Redis然后立刻返回一个200 OK的空响应。真正的业务处理交给一个后台 Worker 进程去完成。调整 Nginx 超时在反向代理配置中增加proxy_send_timeout 10;和proxy_connect_timeout 10;。这给了 Nginx 更长的缓冲时间。独家技巧在飞书后台的“机器人管理”页面开启“调试模式”。开启后飞书会把每一次 Webhook 请求的完整 payload 和你的响应都记录在后台。你可以直接看到是你的响应格式错了还是响应超时了一目了然。5.4 问题四更换服务器后Clawdbot 插件全部失效日志报 “Cannot find module ‘xxx’”现象你用宝塔的“整机迁移”功能把网站、数据库、计划任务都迁移到了新服务器但pm2 start后所有插件都报Cannot find module错误。根本原因node_modules目录是平台相关的。它里面包含了大量用 C 编写的原生模块如sqlite3这些模块在编译时会绑定到特定的 CPU 架构和 Node.js 版本。旧服务器是 AMD CPU新服务器是 Intel或者旧服务器是 Node.js 16新服务器是 Node.js 18都会导致node_modules不兼容。正确做法迁移后必须删除node_modules并重新安装。在新服务器上执行cd /www/wwwroot/clawdbot rm -rf node_modules npm install --production不要试图复制node_modules这是最省事但最错误的做法。独家技巧为了杜绝此类问题建议在项目根目录下创建一个deploy.sh脚本#!/bin/bash git pull rm -rf node_modules npm install --production pm2 reload ecosystem.config.js echo Deploy finished!以后每次更新只需在终端执行./deploy.sh一气呵成永不踩坑。5.5 问题五宝塔面板升级后Clawdbot 的反向代理配置被自动覆盖现象宝塔面板自动升级到新版本后你精心编写的 Nginx 配置文件被重置机器人又变 5