这两天 Clawdbot 在技术圈突然火了起来，很多人已经开始往服务器上部署测试。真正动手之后会发现，其实安装并不复杂，真正影响体验的是后续的使用方式和运行结构。
如果只是把程序跑起来，很快就能完成，但要做到长期稳定使用、访问顺畅、结构清晰、安全可控，就需要把部署过程和访问方式一起规划好，而不是单纯装完就结束。
这篇文章就是按真实部署和长期使用的思路，把 Clawdbot 从安装到初始化，再到服务化运行和宝塔访问配置完整跑通一遍，让它不仅能跑起来，也能稳定用得久、用得安心。
从服务器开始：安装 Clawdbot 本体
进入服务器终端即可（宝塔 SSH 终端 / 本地 SSH 客户端都行），常见系统 Debian / Ubuntu / CentOS 都可以直接用官方脚本：
curl -fsSL https://clawd.bot/install.sh | bash
这是最省事的一种方式，会自动处理依赖环境。
国产系统的特殊情况
如果你用的是 OpenCloudOS / Alibaba Cloud Linux 这类国产发行版，需要先处理 Node 版本问题：
路径：
宝塔面板 → 网站 → Node项目 → Node版本管理器 →
更新版本列表 → 安装稳定版 v24.13.0 → 设置为当前命令行版本
然后再执行：
npm install -g clawdbot@latest
这一步主要是为了避免 Node 环境不兼容导致后续初始化失败。
初始化 Clawdbot
如果你是脚本安装，一般会自动进入初始化流程；
如果没有进入，可以手动执行：
clawdbot onboard --install-daemon
整个过程是交互式引导配置，不复杂，但每一步其实都在定义系统结构。
风险确认
系统会先提示这是一个高权限系统，有潜在风险，确认继续即可。
引导模式选择
直接选“快速开始”，先跑通系统结构，后面再精细化配置。
模型 / 鉴权提供方
这里是核心选择之一。
要注意一点：
列表中的 Moonshot、Qwen 默认是国际站 API 端点，很多国内账号是连不通的，这一步如果选错，后面会出现“系统正常但模型不可用”的假成功状态。
建议选你真实能稳定使用的平台。
通道（Channel）配置
这里是选择接入方式：
- 网页对话（Web UI）
- Telegram
- Discord
- 其他渠道
如果只是先跑系统结构，可以先选网页对话或直接跳过，后续再加。
技能系统（Skills）
这是 Clawdbot 的能力扩展模块：
- 可选安装
- 可后期补装
- 不影响基础运行结构
按默认流程选即可。
API 配置项
后面的 API 项可以先跳过，不影响系统启动，后期按需补充即可。
⚠ 非常重要的一步：保存 Token
初始化完成后，终端会输出一个访问链接，例如：
http://localhost:18789/?token=xxxxxxxxxxxx
这个 token 是后续 Web 控制台授权绑定的唯一凭证。
必须保存下来，后面配置反向代理和访问授权都会用到。
把 Clawdbot 变成系统级服务
这一步决定稳定性。
执行：
clawdbot daemon install
安装完成后启动服务：
clawdbot daemon start
这时 Clawdbot 已经不是“终端程序”，而是：
- 系统级 daemon 服务
- 开机自启
- 崩溃可重启
- 后台常驻运行
从“工具脚本”升级成“系统服务”。
解决访问问题：宝塔反向代理 + HTTPS
默认情况下，Clawdbot 只监听本地端口（18789），不支持公网直接访问。
如果你想用 Web 控制台，就必须加一层访问结构。
添加站点
宝塔 → 网站 → 添加站点
域名可以先用 IP 测试，后面再换域名。
配置 SSL
站点设置 → SSL → 申请证书 → 开启 HTTPS
反向代理配置
站点设置 → 反向代理 → 添加配置：
目标地址：
http://127.0.0.1:18789
这一步的本质是：
公网访问 → Nginx → 本地 Clawdbot 服务
Token 授权绑定访问
找到你之前保存的 Token 链接：
http://localhost:18789/?token=xxxxx
替换为公网地址：
https://你的域名或IP/?token=同一串token
访问后页面会显示“待授权”。
终端绑定授权设备
查看待授权请求：
clawdbot devices list
批准授权：
clawdbot devices approve request-id
授权成功后：
- 页面状态变为 OK
- Web 控制台可正常访问
- Token 与当前设备绑定完成
此时就可以正常对话、管理系统了。
给控制台再加一层安全边界（Basic Auth）
因为反向代理站点直接暴露公网，如果只靠 token，本质还是单层防护。
可以加一层 Nginx Basic Auth 做二次认证。
生成认证文件
printf "用户名:$(openssl passwd -apr1 密码)\n" > /www/server/nginx/conf/clawd.pass
示例：
printf "clawd:$(openssl passwd -apr1 clawd123)\n" > /www/server/nginx/conf/clawd.pass
权限设置：
chown root:www /www/server/nginx/conf/clawd.pass
chmod 640 /www/server/nginx/conf/clawd.pass
修改反向代理配置文件
宝塔 → 网站 → 设置 → 反向代理 → 配置文件
加入：
auth_basic "Authorization";
auth_basic_user_file /www/server/nginx/conf/clawd.pass;
保存后自动重载服务。
最终结构是什么样的？
现在你的整体结构是：
- Clawdbot 后台 daemon 服务
- 本地端口监听
- 宝塔反向代理转发
- HTTPS 加密访问
- Token 授权绑定
- Basic Auth 二次认证
- 服务端口不暴露公网
- 控制台不裸奔
- 访问链路清晰可控
这已经不是“玩具部署”，而是一个标准可长期运行的自托管系统结构。
Clawdbot 本身的部署难度并不高，真正容易踩坑的从来不是怎么装，而是：
- 访问路径设计
- 权限边界控制
- 服务暴露方式
- 安全结构搭建
- 长期稳定运行能力
如果你只是纯终端使用、纯 Bot 接入（Telegram / Discord），其实完全可以不做反向代理，系统会更安全；
但如果你需要 Web 控制台 + 可视化管理 + 多设备访问，那这一套结构就是非常合理的长期方案。
不是为了炫技术，而是为了省事和安心。
