国内服务器部署 OpenClaw 踩坑实录

OpenClaw 是一个功能强大的 AI 助手框架,可以理解为一个“AI 机器人中枢”。它能接入 QQ、飞书、Telegram 等多个聊天平台,让你在任何地方都能和 AI 对话。同时支持接入各种大模型(如 DeepSeek、通义千问、Claude 等),还能通过 Skills 扩展技能(比如写公众号文章、代码开发等)。简单说:一个能干活、能聊天、能接入各种平台的 AI 管家。

写在前面

最近想在国内服务器上部署 OpenClaw,本以为是个简单的 Docker 拉取运行的事,结果还是踩了不少坑的,于是打算踩到的坑和解决方案记录下来,希望对遇到困难的朋友们有所帮助。

我的环境

  • 服务器:国内某云 CentOS 7.x
  • 目标:部署 OpenClaw + QQ 机器人

踩坑实录

坑一:CentOS 7版本过低,Node 22+ 版本无法安装

现象
安装小龙虾需要比较新的node版本,一般是推荐 node 22+ 以上。 在这里我安装node时候,是采用的官方教程。具体的安装命令如下:

# Download and install nvm:
curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.40.4/install.sh | bash

# in lieu of restarting the shell
\. "$HOME/.nvm/nvm.sh"

# Download and install Node.js:
nvm install 24

# Verify the Node.js version:
node -v # Should print "v24.14.1".

# Verify npm version:
npm -v # Should print "11.11.0".

然而在 nvm install 后,执行node -v,就会有以下各种的报错。

$ node -v
node: /lib64/libc.so.6: version `GLIBC_2.18' not found (required by node)
node: /lib64/libc.so.6: version `GLIBC_2.25' not found (required by node)
node: /lib64/libc.so.6: version `GLIBC_2.28' not found (required by node)

原因
CentOS 7 自带的 glibc 版本是 2.17,Node.js 新版本(18+)需要更高版本的 glibc,而 CentOS 7 的 glibc 版本太老了。,所以也就没法安装node 22+。

最终解决
放弃在宿主机直接装,拥抱 Docker。Docker 容器内有完整的运行时环境,彻底绕过宿主机库兼容性问题。


坑二:网络不通,拉取镜像超时

现象
我根据openclaw的官方docker安装教程,首先第一步将 git仓库拉下来,然后在项目根路径,执行镜像构建命令

./scripts/docker/setup.sh

这块的报错就不贴出来了,就上在构建镜像时候,各种依赖的库由于网络问题拉不下来,卡住。没法下一步。

尝试过的无效方案

  • 配置 Docker 镜像加速器(阿里云/中科大/腾讯云,不太好使)
  • 反复重试(大部分时间失败)
  • 用国外的小机器作为http代理,然后配置国内服务器的docker http代理(可能是国外的小机器性能太差,配置代理是成功的,但是还是各种网络问题卡住,不能完全的拉下来)

**配置了 HTTP_PROXY/HTTPS_PROXY,curl 能通但 docker pull 死活不走代理。

原因
Docker 守护进程的 systemd 配置不读这些环境变量,需要专门配置。

尝试过的无效方案

  • export HTTP_PROXY=...(没用,docker pull 无视)
  • 修改 ~/.docker/config.json(部分生效,但 ghcr.io 仍然不行

最终解决
放弃代理思路,改用镜像搬运


🎯 核心解决方案:镜像搬运工(最终版)

经历了以上所有坑之后,我找到了一个100% 可靠的方法:用一台能顺畅访问外网的机器(比如你的 Mac开加速 或国外服务器)拉取镜像,打包成 tar 文件,传到国内服务器加载

完整操作流程

第一步:在 Mac(或国外服务器)上拉取镜像

# 注意:国内服务器一般是 x86_64 架构,Mac M芯片要加 --platform
docker pull --platform linux/amd64 ghcr.io/openclaw/openclaw:latest

# 导出为 tar 文件
docker save -o openclaw.tar ghcr.io/openclaw/openclaw:latest

# 压缩一下,传输更快
gzip openclaw.tar

第二步:传输到国内服务器

# 用 scp 或 rsync
scp openclaw.tar.gz root@你的国内服务器IP:/root/

第三步:在国内服务器上导入并运行

# 解压并导入
gunzip -c openclaw.tar.gz | docker load

# 运行容器
docker run -d \
  --name openclaw \
  --restart unless-stopped \
  --network host \
  -v /root/openclaw/config:/home/node/.openclaw \
  -v /root/openclaw/workspace:/home/node/.openclaw/workspace \
  -e TZ=Asia/Shanghai \
  ghcr.io/openclaw/openclaw:latest

为什么这个方法靠谱?

问题 镜像搬运如何解决
CentOS 版本低 ✅ 不需要宿主机装任何运行时
Node.js 装不上 ✅ 环境在容器里,与宿主机无关
网络不通 ✅ 只需一次 scp 传输,不需要服务器通外网
代理不好使 ✅ 完全不依赖代理
反复失败 ✅ 一次拉取成功,永久使用

其他小坑与避坑指南

配置文件权限问题

现象:容器启动后报 EACCES: permission denied, mkdir '/home/node/.openclaw/agents'

解决

chown -R 1000:1000 /root/openclaw

Web UI 无法访问

现象:浏览器打开 http://IP:18789 显示 origin not allowedpairing required

解决:修改配置文件 /root/openclaw/config/openclaw.json里的 "allowedOrigins": ["*"],

{
  "gateway": {
    "port": 18789,
    "bind": "0.0.0.0",
    "controlUi": {
      "allowedOrigins": ["*"],
      "dangerouslyDisableDeviceAuth": true
    }
  }
}

总结:国内部署的最优路径

如果你也在国内服务器上部署 OpenClaw,我的建议是:

  1. 放弃在宿主机直接装,拥抱 Docker,也出于一定的安全角度考量
  2. 放弃代理、镜像加速,直接用“镜像搬运”法
  3. 准备一台能顺畅访问外网的机器(你的 Mac 或一台海外服务器)
  4. 一条命令拉取,一条命令打包,一条命令传输,一条命令导入

这套流程不仅适用于 OpenClaw,也适用于任何在国内拉取困难的 Docker 镜像。希望你能少踩坑,顺利部署!

评论

  1. Gwendolyn3173
    2 月前
    2026-4-23 9:03:44
  2. Aspen4240
    2 月前
    2026-4-23 9:50:43
  3. 2 月前
    2026-5-02 16:49:44

    无话可说,只是看看

  4. 3 周前
    2026-6-09 16:35:48

    All the best

  5. Alexa4971
    2 周前
    2026-6-16 5:52:52
  6. 2 周前
    2026-6-17 19:35:19

    Enjoy every single day

  7. 2 周前
    2026-6-20 17:21:41

    Just tried 2jli and the GCash withdrawals are super fast! If you want premium slots without hassle, head over to 2jli slot now. The registration is smooth, two-factor auth keeps you safe, and live dealer games feel totally authentic.

  8. 5 天前
    2026-6-28 3:03:33

    Wish you happiness

  9. 5 天前
    2026-6-28 7:55:38

    yahoo,im go

  10. 3 天前
    2026-6-29 14:57:16

    This is a perfect case study on technical debt. The GLIBC incompatibility highlights the friction between rapidly evolving AI stacks and legacy infrastructure. Containerization is the necessary abstraction layer for operational resilience. Maintaining compatibility across diverse systems, whether it’s a backend service or a consumer platform like ph987, requires robust deployment strategies.

发送评论 编辑评论


				
|´・ω・)ノ
ヾ(≧∇≦*)ゝ
(☆ω☆)
(╯‵□′)╯︵┴─┴
 ̄﹃ ̄
(/ω\)
∠( ᐛ 」∠)_
(๑•̀ㅁ•́ฅ)
→_→
୧(๑•̀⌄•́๑)૭
٩(ˊᗜˋ*)و
(ノ°ο°)ノ
(´இ皿இ`)
⌇●﹏●⌇
(ฅ´ω`ฅ)
(╯°A°)╯︵○○○
φ( ̄∇ ̄o)
ヾ(´・ ・`。)ノ"
( ง ᵒ̌皿ᵒ̌)ง⁼³₌₃
(ó﹏ò。)
Σ(っ °Д °;)っ
( ,,´・ω・)ノ"(´っω・`。)
╮(╯▽╰)╭
o(*////▽////*)q
>﹏<
( ๑´•ω•) "(ㆆᴗㆆ)
😂
😀
😅
😊
🙂
🙃
😌
😍
😘
😜
😝
😏
😒
🙄
😳
😡
😔
😫
😱
😭
💩
👻
🙌
🖕
👍
👫
👬
👭
🌚
🌝
🙈
💊
😶
🙏
🍦
🍉
😣
Source: github.com/k4yt3x/flowerhd
颜文字
Emoji
小恐龙
花!
上一篇