简介：基于阿里云ECS的OpenClaw一键部署方案，是一份面向无运维经验技术爱好者与开发者的实操指南，旨在帮助用户借助一台低配云服务器，在十五分钟内完成个性化AI助手的云端搭建与管理。整份指南以单个PDF文档呈现，压缩包仅有138KB，篇幅精炼但覆盖完整部署链路：从服务器规格选择、Ubuntu系统环境准备、安全组端口放行，到一键安装脚本、主流大模型接入、访问密码设定与技能扩展，再到域名绑定、本地模型部署和数据备份等进阶优化，均有分步说明。特别的是，文中不仅给出了安装验证与开机自启的命令示例，还整理了常见问题排查思路和年度成本估算，让没有运维背景的读者也能避开坑点、按图索骥。目前已有148人学习，适合希望将OpenClaw私有化部署、通过Web或客户端远程访问的个人用户，照此操作即可获得一套高性价比、多端同步的私有AI工作流。

1. 为什么把 OpenClaw 放到阿里云 ECS 上跑：本地折腾半年后的结论

先在开头把结论摆出来：OpenClaw 这个云端 AI 助手框架，最省心的跑法不是放在你家里的电脑上，也不是塞进安卓手机里用 Termux 凑合，而是买一台阿里云 ECS 轻量服务器，用一键部署脚本把它立起来。原因很简单——OpenClaw 要长期挂着干活，它需要稳定的网络环境、不受关机影响的常驻进程、以及随时能从手机和办公电脑连回去的入口。本地机器一合盖子、一断电、一换 Wi-Fi，助手就失联，这种体验用上半年你就会明白什么叫折腾到怀疑人生。

本文要解决的就是这条路：怎么在一台新买的 ECS 上，把一个 OpenClaw 实例跑起来，并且让它真的能接 API、能干杂活、能远程管。你会看到我实际用的部署命令、踩过的坑、以及那些文档里没写但你一定会撞上的边界条件。这套方案的核心价值就一句话：用最低的云资源成本，换一个 7x24 小时在线的 AI 助手底座。适合的人群很明确——想正经把 OpenClaw 用起来、但不想把家里电脑变成永不关机的服务器的开发者。

2. OpenClaw 是什么、为什么它适合跑在云上：架构拆解与选型理由

2.1 OpenClaw 在技术栈里的定位：先分清它和 Ollama、ROS 的关系

OpenClaw 这个名字在检索时经常和几样东西混在一起，先说清楚它的位置。OpenClaw 本身是一个云端 AI 助手的运行时框架，它负责的事情是：连接大模型 API、管理会话上下文、调用外部工具或技能（skill）、以及暴露一个可以被客户端访问的接口。它不是一个模型训练框架，也不是一个单纯的聊天前端。

所以当你搜到「ollama部署openclaw」这类热词时，要理解那是两件事的组合：Ollama 负责在本地或者云主机上跑开源模型权重，OpenClaw 负责调用这个模型（或者调用云端 API）来完成助手逻辑。OpenClaw 可以通过 OpenAI 兼容接口接到 Ollama 上，也可以直接接 DashScope、Model Studio 这类云厂商的模型 API。这一点直接决定了你的 ECS 配置选多大。

另外有个高频混淆点：「openclaw 只能用接入 api 的方式使用算力吗」。答案是——不是只能，但对你部署在 ECS 上的场景来说，接 API 是性价比最高的方式。你也可以在 ECS 上装 Ollama 跑 7B 或者 14B 的小模型，但一张没有 GPU 的 2 核 4G 云服务器跑量化模型，推理速度只能说是「能响应，但谈不上流畅」。我的建议是：ECS 上跑 OpenClaw 进程，模型走 API，这样 2 核 4G 的配置就绰绰有余。

2.2 为什么选阿里云 ECS 而不是本地主机：四个关键维度对比

拿我自己的使用经历来说，OpenClaw 在本地跑和在云上跑，差距最大的四个维度是网络稳定性、公网可达性、进程常驻能力、以及成本。

对于「openclaw 安卓部署」「手机连回家里的 OpenClaw」这类诉求，ECS 方案最大的优势就是你不用去折腾内网穿透。手机用 4G 网络直接访问 ECS 的公网 IP 加端口就行，不存在 NAT 穿越的问题。

提示：如果你的核心诉求是「手机上随时能用」，那 ECS 方案远优于 Termux 方案。Termux 里跑 OpenClaw 不是不行，但手机后台进程被系统回收是常态，你得每次手动拉起服务，这在实战中几乎不可接受。

2.3 需要一个什么样的 ECS 实例：配置、镜像与地域选择的实操建议

我的建议是：不要一上来就买高配。OpenClaw 的进程本身占用极小，主要内存消耗在会话历史和 Python 运行时上。实测下来，2 核 4G 的轻量应用服务器足够同时跑 OpenClaw 主进程和一个轻量级的 Ollama 服务（如果你非要在云上跑开源模型的话）。地域选择上，如果你主要是调用国内的模型 API（比如 DashScope），那就选华东、华北这些 region，延迟低；如果你要用 OpenAI 官方 API，那需要考虑网络可达性问题，这一点你自己权衡，我不展开。

镜像选择上，直接用 Ubuntu 22.04 或者 24.04 LTS 是最省事的。Debian 系的好处是依赖安装方便，Python 版本也比较新。CentOS 已经被社区放弃维护了，新手别选。购买完成后，先做两件事：第一，重置 root 密码或者绑定密钥对；第二，在安全组里放行你后面要用到的端口。这两步不做，后面部署脚本跑通了也连不上。

安全组规则我一般只放行三个端口：SSH 用的 22（建议改成非标准端口或者用密钥登录）、OpenClaw 的 Web 管理端口（一般是 8080 或者你自己映射的端口，按部署脚本实际为准）、以及如果你要开放 API 端口的话再单独加。不要图省事放行 0.0.0.0/0 的所有端口，这是血泪经验。

3. 在阿里云 ECS 上跑通 OpenClaw 一键部署：从裸机到服务可用的完整步骤

3.1 部署前的环境准备：登录 ECS、更新系统、装基础依赖

新买回来的 ECS 是一台裸机，你需要先 SSH 登上去把基础环境整干净。用你购买时设置的密码或者密钥登录：

ssh root@你的服务器公网IP # 登录成功后，先更新系统包索引和已安装的软件包 apt update && apt upgrade -y # 安装基础工具：curl 用于下载脚本，git 用于拉取代码，vim 用于改配置 apt install -y curl git vim net-tools

这里有一个细节：Ubuntu 24.04 默认不带 net-tools，也就是没有 ifconfig 命令。如果你后面要排查端口监听情况，net-tools 里的 netstat 是必须要的。有的人喜欢用ss -tlnp，那个也行，但 netstat 的输出格式我看了十几年更习惯。更新系统这一步别跳过，新镜像里的内核和 OpenClaw 依赖的 Python 库版本之间偶尔会有兼容性问题，先把系统升到最新能省掉很多莫名其妙的报错。

安全组的事单独再提醒一次：你需要在阿里云控制台的 ECS 实例详情页里找到「安全组」配置，把 TCP 端口 22、8080（或者部署脚本指定的 Web 端口）加进去。源地址不要填 0.0.0.0/0，建议填你自己的家庭宽带公网 IP 或者公司出口 IP。不然你的 OpenClaw 管理面板就等于裸奔在公网上，AI 助手的会话记录和 API Key 都有泄露风险。

3.2 拉取 OpenClaw 一键部署脚本：动手安装的主流程

环境干净之后，下一步就是拿到 OpenClaw 的部署脚本。常见的做法是项目仓库里提供一个install.sh或者类似的脚本，你只要把它拉到服务器上执行即可。具体命令如下：

# 进入一个固定的工作目录，我习惯用 /opt，避免和用户目录混在一起 cd /opt # 克隆 OpenClaw 的部署仓库，注意仓库名和分支以你实际拿到的官方地址为准 git clone https://your-openclaw-repo-url/openclaw-deploy.git cd openclaw-deploy # 给脚本加执行权限，然后开始安装 chmod +x install.sh ./install.sh

执行之前最好用vim install.sh打开脚本看一眼里面做了什么。这不是不信任，而是运维的基本习惯。重点看三件事：第一，脚本是否会修改系统全局的 Python 环境；第二，脚本默认安装到哪个目录；第三，脚本末尾是否会自动创建 systemd 服务。我见过太多一键脚本装完就让你手动配 systemd 的，那不能叫一键部署，那叫半键部署。

安装过程会下载 Python 依赖包和 OpenClaw 的核心代码，耗时取决于 ECS 的带宽。国内地域的服务器拉 GitHub 有时会很慢，如果卡在下载步骤，常见的做法是给 pip 配国内镜像源，比如在命令前加PIP_INDEX_URL=https://pypi.tuna.tsinghua.edu.cn/simple。这一步能帮你把安装时间从半小时缩短到几分钟，属于实战里必用的技巧。

3.3 初始化配置：模型 API 接入、管理员账号与端口设置

脚本跑完不代表 OpenClaw 就能用了，你还要做初始化配置。OpenClaw 启动后的第一件事是读取配置文件，通常是一个 YAML 或者 JSON 文件，里面要写明你用哪个模型服务商、API Key 是多少、Web 面板监听哪个端口。下面是一个典型的配置片段：

# config.yaml 核心片段 server: host: 0.0.0.0 # 监听所有网卡，这样才能从公网访问 port: 8080 # Web 管理面板端口，和安全组放行的规则对应 model: provider: dashscope # 可以是 dashscope / openai-compatible / ollama api_key: "你的API密钥，不要写在公开仓库里" model_name: qwen-plus auth: username: admin password: "设置一个强密码，别用 admin123"

这段配置里最容易踩坑的是host字段。默认值经常是127.0.0.1，这意味着只能在服务器本机访问面板，你从手机和办公室电脑全都连不上。必须改成0.0.0.0。另外api_key字段，如果你用环境变量的方式注入，配置里就别写死，改成${DASHSCOPE_API_KEY}这种占位符，然后把真实 Key 放在 systemd 服务文件的环境变量里。这样既方便换 Key，也避免配置文件备份时泄露密钥。

改完配置后，启动 OpenClaw 并验证面板能打开：

# 如果脚本没有自动创建 systemd 服务，用 nohup 先手动起一次 cd /opt/openclaw-deploy nohup python3 -m openclaw.server --config config.yaml > openclaw.log 2>&1 & # 查看监听端口，确认服务起来了 netstat -tlnp | grep 8080 # 本机 curl 一下健康检查接口 curl http://127.0.0.1:8080/health

curl返回 JSON 且包含status: ok之类的字段，说明服务本体没问题。这时候再用手机浏览器访问http://你的ECS公网IP:8080，能打开登录页就说明安全组和 host 配置都对了。打不开的话，百分之八十是安全组没放行端口，百分之二十是云防火墙没关或者系统防火墙拦截，排查顺序从外到内。

4. OpenClaw 在 ECS 上的系统化托管：systemd 常驻、日志治理与低成本监控

4.1 用 systemd 把 OpenClaw 变成开机自启服务：告别 nohup 和掉线

用nohup启动服务只能应付临时验证，服务器一重启进程就没了。要让 OpenClaw 真正成为一个云端常驻助手，必须写 systemd 服务。这也是「OpenClaw 搭建」从玩具走向生产的标志性一步。

# 创建 systemd 服务文件 vim /etc/systemd/system/openclaw.service

文件内容如下：

[Unit] Description=OpenClaw AI Assistant Service After=network-online.target Wants=network-online.target [Service] Type=simple WorkingDirectory=/opt/openclaw-deploy ExecStart=/usr/bin/python3 -m openclaw.server --config /opt/openclaw-deploy/config.yaml Restart=always RestartSec=5 # 环境变量在这里注入，避免写在配置文件里 Environment=DASHSCOPE_API_KEY=你的API密钥 [Install] WantedBy=multi-user.target

写好之后执行systemctl daemon-reload让 systemd 重新加载配置，然后systemctl enable openclaw设置开机自启，systemctl start openclaw启动服务。Restart=always这个参数是这整套托管方案里最重要的一行——OpenClaw 底层依赖的 Python 进程偶发崩溃时，systemd 会在 5 秒后自动拉起来，你甚至不会感知到它挂过。

提示：ExecStart里的 python3 路径最好写全。用which python3查一下实际路径填进去，因为在 systemd 环境里 PATH 变量和你在终端里看到的不一样，写python3有时会报「找不到命令」，这个坑我翻车过两次。

4.2 日志治理：journalctl 查崩溃、logrotate 防磁盘爆掉

服务托管后，另一个绕不开的问题是日志。OpenClaw 运行时的所有输出都会进到 journald 里，用journalctl可以随时排查问题。三条最常用的命令：

# 实时看 OpenClaw 的输出 journalctl -u openclaw -f # 看最近一次崩溃前后的完整日志，带时间戳 journalctl -u openclaw --since "10 minutes ago" -p err # 查看服务当前运行状态和最近重启记录 systemctl status openclaw

实战里我发现日志量最大的是 OpenClaw 的会话记录和工具调用输出。默认配置下 systemd 的 journal 只按容量限制，不按时间清理，如果服务器磁盘只有 40G，跑一两个月后/var/log/journal可能会膨胀到几个 G。我的做法是在/etc/systemd/journald.conf里设SystemMaxUse=500M，再加上 logrotate 对 OpenClaw 自己的日志目录做轮转。这属于「平时没人管、出问题才想起」的角落，但你只要经历过一次磁盘写满导致服务拒绝写入的故障，就会老老实实配好。

4.3 低成本监控：ECS 基础监控配合一个外部 uptime 探活

OpenClaw 在云端跑，你不一定 24 小时盯着，但要保证它挂了你第一时间知道。最低成本的方案是两层：第一层用阿里云 ECS 自带的基础监控看 CPU、内存、磁盘，超过阈值就设报警规则；第二层用一个外部的 HTTP 探活服务定时去请求 OpenClaw 的/health接口，接口不返回 200 就发邮件或者钉钉通知给你。两层结合的好处是：第一层能发现资源耗尽导致的假死，第二层能发现公网链路异常或者进程死掉但端口还在监听的情况。

这套监控不用一开始就做得很重。我建议至少把第二层做了，因为 ECS 基础监控不会告诉你「OpenClaw 进程还在但无法响应请求」这种事。外部探活服务很多，你甚至可以写一个十行的 Python 脚本扔在另一台便宜的机器上跑，效果一样。核心思想就一个：不要在失联之后才被动发现，要在第一分钟就知道它挂了。

5. OpenClaw 部署避坑指南：六个高频故障的现象、原因与解决

5.1 安装时卡在 pip 下载依赖：国内网络拉取 GitHub 与 PyPI 超时

现象：install.sh执行到pip install -r requirements.txt时就一直转圈或者直接报TimeoutError，重复执行还是老样子。

原因：OpenClaw 的依赖包大多托管在 PyPI 官方源上，国内服务器直连速度极不稳定，大一点的包（比如包含 numpy、pydantic 这种）很容易超时。

解决：给 pip 换国内镜像源。在安装命令前导出环境变量：

export PIP_INDEX_URL=https://pypi.tuna.tsinghua.edu.cn/simple

或者更持久的方式，修改~/.pip/pip.conf把 index-url 写死。改成清华源之后，安装速度立竿见影。如果脚本内部硬编码了 pip 命令不带-i参数，你就用环境变量方式，优先级最高，覆盖脚本里的默认源。

5.2 服务起来了但手机浏览器连不上管理面板

现象：SSH 进去curl http://127.0.0.1:8080/health正常，但手机 4G 网络下访问http://ECS公网IP:8080就是超时。

原因：99% 是阿里云安全组没有放行 8080 端口的入方向规则。安全组是网络层的第一道闸门，实例内部的防火墙反而是第二道，而这道闸门默认全关。

解决：登录阿里云控制台，找到 ECS 实例 → 安全组 → 配置规则 → 入方向，添加一条规则：协议选 TCP，端口填 8080，源地址填你自己的 IP 或者 0.0.0.0/0（不推荐，但求快可以先这样，完了再收紧）。改完安全组一般秒级生效，不需要重启服务器。如果确认安全组放行了还是不通，再检查 Ubuntu 自带的 ufw 防火墙有没有开，ufw status看一眼，开着就ufw allow 8080。

5.3 systemd 服务启动失败，日志提示 Python 模块找不到

现象：systemctl start openclaw执行后显示active (failed)，journalctl -u openclaw -e里报ModuleNotFoundError: No module named 'openclaw'。

原因：一键部署脚本默认把 OpenClaw 装进了某个 Python 虚拟环境（venv），而 systemd 服务文件里用的ExecStart指向的是系统全局的python3，全局环境里当然没有这个模块。这是没有把脚本生成的 venv 路径对齐到服务文件导致的。

解决：在/etc/systemd/system/openclaw.service里，把ExecStart改成指向 venv 里的 python 绝对路径。找到你的安装目录下的venv/bin/python3，然后：

ExecStart=/opt/openclaw-deploy/venv/bin/python3 -m openclaw.server --config /opt/openclaw-deploy/config.yaml

改完systemctl daemon-reload再重启服务。记住一个原则：凡是用了 venv 的 Python 项目，systemd 里的 python 路径必须指向 venv 内部的那个，不要用/usr/bin/python3。

5.4 配置了模型 API 但 OpenClaw 回复报错 401 或者 InvalidApiKey

现象：面板能打开，也能发起对话，但 OpenClaw 的日志里报HTTP 401 Unauthorized或InvalidApiKey，对话没有回复。

原因：API Key 没被正确加载。如果你用了${DASHSCOPE_API_KEY}这类环境变量占位符，但 systemd 服务文件的Environment没写对，或者 Key 本身复制多了空格、少了几位字符。

解决：先在终端里手动echo $DASHSCOPE_API_KEY确认当前 shell 有没有这个变量；没有就说明你只在.bashrc里写了而 systemd 不会读取.bashrc。最稳妥的做法是直接在服务文件里写Environment=DASHSCOPE_API_KEY=你的完整密钥，然后systemctl daemon-reload && systemctl restart openclaw。如果还是不行，把配置里的 api_key 临时改成明文测试，通了之后再改回环境变量方案——尽快定位是加载问题还是 Key 本身问题。

5.5 ECS 磁盘被日志和模型缓存塞满导致服务假死

现象：服务从外部探活看是通的，但发消息不回复，SSH 上去执行命令特别卡，df -h显示/分区使用率 100%。

原因：OpenClaw 的日志、会话历史、以及如果你跑了 Ollama 的话，模型权重文件会非常占空间。轻量服务器默认数据盘就 40G 到 60G，日志不轮转、历史不清空，几个月就满了。

解决：立刻清journalctl --vacuum-size=200M，再删掉 OpenClaw 安装目录下的旧日志文件，rm -f /opt/openclaw-deploy/*.log。长期做法：设置 journald 的SystemMaxUse，给 OpenClaw 日志目录配置 logrotate，另外定期归档清理会话历史。如果你装了 Ollama，模型放在~/.ollama/models，一个 7B 的量化模型大约 4 到 5G，两台模型就 10G了，这点要提前规划好磁盘容量。

5.6 重启服务器后 OpenClaw 没起来，检查开机自启链路的两个盲区

现象：reboot之后 SSH 能登录，但 OpenClaw 面板访问不了，systemctl status openclaw显示 inactive。

原因：第一层盲区是 systemd 服务没有正确enable，只start是不开机自启的；第二层盲区是服务文件里After=network-online.target在部分云镜像上没有对应启用systemd-networkd-wait-online服务，导致 OpenClaw 启动时网络还没准备好，它去连接模型 API 失败后退出，而Restart=always也拉不回来。

解决：先systemctl enable openclaw，确保 to-enable 状态是 enabled。再在服务文件里加入Wants=network-online.target，并确保systemctl status systemd-networkd-wait-online是 active。另一种更保险的办法是给ExecStart前面加一小段等待逻辑，比如用ExecStartPre=/bin/sleep 10，虽然粗暴但非常有效，等网络稳定了再拉起进程。我个人的习惯是两者都做：既声明网络依赖，又加Restart=always和RestartSec=5，这样即使启动瞬间抢跑失败，5 秒后 systemd 会再拉一次。

6. 进阶玩法：用 ECS 上的 OpenClaw 接本地 Ollama、扩展 Skill 与手机远程管理的技巧

OpenClaw 部署到这一步，已经能正常对话和接入 API 了。但真正体现「云端 AI 助手」价值的，是下面三个进阶玩法。第一个是接本地 Ollama 跑开源模型。在 ECS 上装 Ollama 其实只需一条命令curl -fsSL https://ollama.com/install.sh | sh，然后拉一个轻量模型，比如qwen2.5:7b。OpenClaw 的模型配置里把 provider 改成ollama，base_url指向http://127.0.0.1:11434/v1，就能让 OpenClaw 切换到一个完全不依赖外部 API 的模型通道。代价是推理速度慢，适合对实时性不敏感的批量任务；好处是数据不出服务器，对隐私敏感的场景是很好的补充。

第二个是让 OpenClaw 真正干杂活——通过 skill 扩展它调用外部工具的能力。OpenClaw 的 skill 机制和很多 AI 助手的插件系统类似，你可以在配置里启用一个 skill，它会以 JSON 格式描述自己能干什么，模型在对话时根据用户意图决定是否调用。常见的做法是给 OpenClaw 挂一个「执行 Shell 命令」或者「读写文件」的 skill，这样你在手机上发一条「帮我看看服务器磁盘剩多少」，OpenClaw 会在服务器上执行df -h并把结果整理成自然语言回复给你。注意控制这个 skill 的权限边界，千万别拿 root 权限跑，给 OpenClaw 单独建一个低权限系统用户是必须做的事。

第三个是手机远程管理的完整形态。OpenClaw 的 Web 管理面板本身就是响应式设计，手机浏览器直接访问就能用，不需要装 App。我个人的习惯是配合一个二级域名加 HTTPS 来访问，而不是裸 IP 加端口。具体做法是：在云解析里加一条 A 记录指向 ECS 公网 IP，然后用 Caddy 或者 Nginx 反代 8080 端口并自动申请证书。这套方案比裸 IP 访问多一层安全加密，而且不用记 IP 和端口。如果你不想折腾域名，那至少给 Web 面板开启 OpenClaw 自带的认证，并设置强密码加登录限流。

最后说一个我自己的教训：不要在 ECS 上把所有东西都跑在一个实例里。OpenClaw、Ollama、数据库、反代全都堆一台机器，初期省钱，后期故障排查时会非常痛苦——你想重启 OpenClaw，结果发现磁盘 IO 被 Ollama 占满；想升级系统，又怕影响 OpenClaw 的服务。我现在的习惯是核心 OpenClaw 单独一台轻量实例，监控和探活扔到另一台更便宜的机器上，互相隔离。这套用法跑了大半年，没有出过一起需要半夜爬起来处理的事故。希望帮到你。

本文还有配套的精品资源，点击获取