OpenClaw 这类能够调用文件、命令行、浏览器和外部模型的 Agent，放在个人电脑上试用很方便，但一旦需要持续运行、远程访问或多人协作，云服务器通常更合适。云端部署的难点不在于把程序启动起来，而在于把服务器规格、模型接口、密钥、网络入口和持久化数据组织成一套可维护的运行环境。
下面按“先跑通、再收紧权限、最后做持久化”的顺序整理一套部署思路。文中的控制台名称、镜像名称、模型名和接口地址应以当前产品页面实际显示为准，不建议把活动文章里的价格、地域或接口参数直接照搬到生产环境。
先确定部署方式和资源边界
轻量应用服务器还是 ECS
只想验证功能、个人使用或运行一个低并发 Agent，可以从带有 OpenClaw 镜像的轻量应用服务器开始。它的优势是初始化步骤少，适合快速验证；缺点是可选规格、网络和扩展方式相对受限。
如果需要自定义操作系统、接入现有 VPC、配置独立安全组，或后续还要运行数据库、队列和其他服务，ECS 更容易纳入现有架构。选择时可以先按负载反推资源：
- 仅文本对话和少量脚本：从较小内存规格开始，观察常驻进程和峰值内存；
- 需要浏览器自动化：为浏览器进程预留额外内存，避免 Agent 与浏览器争抢资源；
- 需要并行任务或长时间运行：优先选择稳定的独享或企业级规格，并配置监控；
- 需要保存会话、技能和脚本：准备独立数据盘或对象存储备份，不要只依赖系统盘。
“至少 2 GiB”可以作为某些镜像的起步参考，但不能视为所有版本和所有工具组合的硬性要求。创建实例前，应同时查看镜像说明、运行时依赖和浏览器组件的资源需求。
裸机安装还是容器
裸机安装适合第一次体验，排错路径短，直接使用项目提供的安装脚本或发行包即可。容器适合需要隔离依赖、可重复部署和快速回滚的场景，但必须提前规划配置目录、会话数据、日志和重启策略。
无论采用哪种方式，都建议先记录以下信息：实例地域、操作系统、OpenClaw 版本、运行端口、数据目录、模型服务提供方，以及密钥存放位置。后续遇到鉴权或升级问题时，这些信息能显著缩短排查时间。
一套更稳妥的部署流程
1. 初始化服务器
使用 SSH 登录实例，登录账号和命令按镜像说明调整：
ssh root@YOUR_SERVER_IP登录后先更新系统依赖，确认 Node.js、Docker 或其他运行时版本满足当前 OpenClaw 文档要求。不要把“能安装”当成“适合长期运行”，还应检查时区、磁盘空间、内存和系统防火墙状态。
如果使用一键镜像，先在应用详情中确认实际服务名、数据目录和监听端口。部分镜像会把端口放通、密钥写入和服务启动封装成控制台操作，优先使用这些明确的入口，避免同时手工修改配置导致状态不一致。
2. 只开放必要的网络入口
SSH 通常只对管理来源开放，WebUI 端口也不应无条件暴露给整个公网。某些 OpenClaw 镜像使用 18789 作为网关端口，但应以本机配置和镜像说明为准：
ss -lntp
sudo ufw status安全组、防火墙和应用自身监听地址是三层不同的控制面。安全组放行了端口，不代表应用一定在监听；应用监听在 127.0.0.1，公网也无法直接访问；如果监听在 0.0.0.0，则必须配合访问令牌、反向代理或 VPN 使用。
更稳妥的做法是让 WebUI 只监听本机，再通过 SSH 隧道访问：
ssh -L 18789:127.0.0.1:18789 root@YOUR_SERVER_IP确实需要公网访问时，再在 HTTPS 反向代理后增加身份认证、来源限制和访问日志。不要为了“先看看效果”而长期裸露管理面板。
3. 配置模型服务，但不要混用密钥
Coding 类订阅、按 Token 或 Credits 计量的订阅，以及普通按量调用接口，可能使用不同的密钥、Endpoint 或额度体系。配置时不要根据名称猜接口，直接从模型服务控制台复制当前方案对应的兼容接口地址、模型标识和密钥。
推荐把配置拆成环境变量或受限权限的配置文件，避免把密钥写进脚本、镜像或 Git 仓库：
export LLM_API_KEY='YOUR_API_KEY'
export LLM_BASE_URL='YOUR_ENDPOINT'
export LLM_MODEL='YOUR_MODEL_NAME'如果 OpenClaw 使用配置文件，示意结构可以是：
{
"llm": {
"provider": "custom",
"base_url": "YOUR_ENDPOINT",
"api_key": "YOUR_API_KEY",
"default_model": "YOUR_MODEL_NAME"
}
}这里的字段名仅用于说明配置关系，不能替代当前版本的配置格式。修改后重启网关，并通过日志确认实际加载了哪个配置文件和模型。若服务商要求地域匹配，还要保证订阅、Endpoint 和实例网络路径处于可用组合。
4. 用最小测试验证链路
不要一上来就测试浏览器抓取、文件批处理和多工具并发。先完成三层验证：
- 服务进程是否存活；
- 本地健康检查是否正常；
- 模型请求是否能够返回。
例如，若当前版本提供健康接口，可先在服务器本机执行：
curl http://127.0.0.1:18789/health再用一条不涉及敏感数据的短问题测试模型调用。确认模型返回后，才逐项打开文件读写、命令执行、浏览器和自定义技能。每打开一个高权限工具，都应重新评估它能访问哪些目录、网络和凭据。
运行维护与故障排查
服务自启动、日志和数据持久化
裸机部署需要确认网关是否由 systemd 或镜像服务托管，并在服务器重启后验证它能自动恢复。容器部署则要设置明确的重启策略，同时把配置和会话目录挂载到宿主机或持久化卷中。不要只在容器内部修改文件，否则重建容器后配置可能消失。
建议至少保留三类数据：模型与网关配置、会话和技能目录、运行日志。日志需要轮转，避免长期运行把系统盘写满；配置和会话目录应定期备份，备份文件中如果含有密钥，必须单独加密并限制访问。
常见问题可以按下面的顺序定位：
- WebUI 打不开：先查进程状态和本机监听，再查系统防火墙与云安全组，最后确认访问地址和端口；
- 模型鉴权失败：核对密钥是否属于当前订阅，Endpoint、模型名和地域是否匹配，并检查复制时是否带入空格或换行；
- 调用成功但额度异常：确认使用的是对应方案的接口，不要把普通按量接口的密钥替换过来；
- 运行一段时间后退出：查看内存和磁盘，暂时关闭浏览器工具和并发任务，判断是否存在 OOM；
- 重启后“配置丢失”：检查实际配置路径、容器挂载和 systemd 服务的运行用户；
- Agent 执行危险操作：收紧工具权限、限制工作目录，避免让服务账号拥有不必要的 root 权限。
怎么选：个人试用、持续运行还是生产接入
个人试用的目标是验证模型和工具链，轻量服务器加镜像通常足够；持续运行更关注重启恢复、日志、备份和成本，应优先把服务配置成可观测、可回滚的形态；如果要接入真实业务，则需要把 WebUI、模型密钥和工具执行分别隔离，必要时使用专用执行节点、反向代理和最小权限账号。
模型订阅的选择也应围绕任务，而不是只看名称。高频短对话、代码修改和脚本调试，重点看按次或按量规则是否适合实际调用模式；长文档、多模态输入和复杂链路，重点看上下文、模型覆盖和额度扣减方式。配置完成后，记录实际消耗和失败原因，再决定是否切换方案。
把 OpenClaw 放到云服务器的价值，主要是获得稳定的运行环境和远程可达性，而不是简单地把本地程序搬到公网。先用小规格和最小权限跑通闭环，再补上安全入口、持久化、监控和备份，通常比一开始堆叠大量工具更容易维护。