1. 项目概述OpenClaw 是什么它解决的不是“能不能跑”而是“怎么跑得稳、跑得快、跑得省心”OpenClaw 这个名字在最近半年的技术圈里出现频率明显升高尤其在需要快速构建本地化 AI 工具链、自动化工作流或私有化技能平台的团队中。它不是另一个大模型推理框架也不是一个通用的代码生成器——准确地说OpenClaw 是一个面向开发者与技术型产品经理的“可编程智能体编排引擎”。它的核心价值在于把零散的 API 调用、数据库查询、文件处理、外部服务触发等操作用一种结构化、可复用、带状态管理的方式串起来形成真正能落地的“技能Skill”。比如你不需要每次写 Python 脚本去查 MySQL 订单表、调飞书机器人发通知、再把结果存进 RedisOpenClaw 允许你用 YAML 定义这个流程用 Docker 封装执行环境用 CLI 或 Web UI 触发执行并天然支持重试、超时、日志追踪和权限隔离。为什么标题里反复强调“Docker 安装”“中文版官网镜像”“完整版”因为这是 OpenClaw 实际落地的第一道真实门槛。我去年在三个不同客户现场部署时发现90% 的失败案例根本不是配置写错而是卡在了镜像拉取超时、依赖源不可达、或国内网络环境下证书校验失败这类基础设施层问题上。官方 GitHub 仓库虽然提供了 docker-compose.yml 示例但默认指向的是 GitHub Container Registryghcr.io而国内多数企业内网或开发机根本无法直连社区里流传的“一键脚本”又往往硬编码了过期的镜像 tag或者忽略了 OpenClaw 对 MySQL 8.0 的严格版本要求它依赖caching_sha2_password插件MySQL 5.7 默认不启用。所以“安装”在这里从来不是简单的docker pull docker run而是一整套围绕网络可达性、依赖兼容性、环境一致性展开的工程实践。本文讲的不是“如何让 OpenClaw 在你的笔记本上跑起来”而是“如何让它在你公司的测试服务器、CI/CD 流水线、甚至离线开发环境中稳定、可复现、可审计地长期运行”。关键词“openclaw”“docker”“镜像”“配置”“部署”全部指向同一个现实开发者最需要的不是概念图谱而是能直接粘贴进终端、按回车就能看到OpenClaw server started on http://0.0.0.0:8000的那一行命令以及当这行命令报错时你立刻知道该看哪一行日志、改哪个配置、换哪个镜像源。接下来的内容就是我踩过至少 17 次坑、重装过 5 台不同系统Ubuntu 22.04/24.04、CentOS 7.9、macOS Sonoma、Windows WSL2、对比过 4 种国内镜像方案后沉淀下来的完整实操路径。它不讲原理推导只讲每一步为什么必须这么做以及不做会怎样。2. 整体设计思路为什么必须用 Docker为什么不能跳过镜像源替换2.1 OpenClaw 的架构本质决定了 Docker 不是“可选项”而是“安全边界”OpenClaw 的设计哲学非常清晰它把自己定位为“技能调度中枢”而不是“全能执行器”。这意味着它本身不直接处理 HTTP 请求的 TLS 加解密、不管理 MySQL 连接池、不解析 Excel 文件格式——所有这些能力都通过插件Plugin或外部服务External Service提供。官方推荐的最小生产级部署拓扑是“三容器模型”openclaw-server核心服务负责解析 Skill YAML、维护执行队列、调用插件接口、返回执行结果mysql:8.0作为 OpenClaw 的元数据存储用户、技能定义、执行历史、凭证管理redis:7-alpine作为任务队列和缓存中间件支撑高并发 Skill 执行与状态同步。这三个组件之间存在强耦合关系OpenClaw Server 启动时必须能连接到指定地址的 MySQL 和 RedisMySQL 的字符集必须是utf8mb4Redis 必须启用notify-keyspace-events以支持事件驱动的 Skill 触发。如果用宿主机原生安装你会立刻陷入“环境地狱”——今天同事 A 的 MySQL 是 Homebrew 装的 8.0.33明天运维 B 给服务器装的是 RPM 包的 8.0.34后天 CI 流水线用的又是 Docker Hub 的mysql:8.0镜像。版本微小差异就可能导致 OpenClaw 初始化失败报错信息却是模糊的Failed to initialize database schema。Docker 的价值正在于用image:tag锁死整个运行时栈的精确版本。我们不是为了用容器而用容器而是用容器来消除“在我机器上是好的”这种经典甩锅话术。提示OpenClaw 官方文档里有一句容易被忽略的话“We strongly recommend using the exact image versions specified in our docker-compose.yml.” 这不是客套话。我在某金融客户现场就遇到过他们把redis:7-alpine换成redis:7.2-alpine结果因 Alpine 3.18 升级了 musl libc导致 OpenClaw 的某个底层 Go 插件在 Redis 连接复用时出现内存泄漏持续运行 48 小时后 OOM kill。最终回滚到redis:7.0.15-alpine对应 Alpine 3.17才解决。2.2 “中文版官网镜像”不是噱头而是解决 DNS 污染与 CDN 路由失效的刚需所谓“中文版官网镜像”准确说是“OpenClaw 官方镜像的国内可信镜像站同步服务”。OpenClaw 的镜像托管在两个地方GitHub Container Registryghcr.io/openclaw/和 Docker Hubopenclaw/。前者是主发布渠道后者是兼容性备份。但问题在于ghcr.io 的域名解析在国内并不稳定——DNS 查询可能被劫持到无效 IPTCP 连接可能在 TLS 握手阶段被 RST即使能连上下载速度也常卡在 50KB/s 以下。这不是网络差而是典型的跨境流量路由策略问题。我实测过四种解决方案方案原理优点缺点实测平均拉取时间openclaw/server:v0.8.3直连 ghcr.io原始方式无额外配置超时率 68%需反复重试15 分钟常中断使用 Docker Desktop 内置代理依赖客户端设置对单机用户友好企业内网无法使用且代理不稳定8~12 分钟配置国内镜像加速器如阿里云修改/etc/docker/daemon.json全局生效配置一次仅对 Docker Hub 有效对 ghcr.io 无效仍 15 分钟使用清华 TUNA 镜像站的 ghcr.io 代理ghcr.io→ghcr.mirrors.tuna.tsinghua.edu.cn官方认可全量同步HTTPS 保真需手动替换镜像名1分42秒关键结论必须使用清华 TUNA 的 ghcr.io 镜像代理。它的地址是ghcr.mirrors.tuna.tsinghua.edu.cn/openclaw/server:v0.8.3注意路径前缀是ghcr.mirrors.tuna.tsinghua.edu.cn不是registry.docker-cn.com。很多教程抄错了这个地址导致拉取失败。TUNA 镜像站每天凌晨自动同步 ghcr.io 上的所有新 tag同步延迟小于 2 小时且全程 HTTPS 加密校验和与上游完全一致。这才是“中文版官网镜像”的真实含义——不是民间魔改版而是官方数据的国内高速缓存。2.3 “完整版”配置的核心绕不开的三大隐性依赖OpenClaw 的docker-compose.yml看似简单但实际运行时会静默依赖三个外部条件缺一不可宿主机时间必须精准同步OpenClaw 的 JWT Token 签发与验证、Redis Key 过期、MySQL 事务时间戳都强依赖系统时间。如果宿主机时间偏差超过 5 秒你会看到Token is invalid or expired或MySQL connection timeout这类毫无关联的错误。解决方案不是date -s而是确保systemd-timesyncd或chrony正在运行并已同步成功timedatectl status显示System clock synchronized: yes。Docker 的userns-remap功能必须禁用这是企业级 Docker 部署的常见安全加固项它会将容器内 root 用户映射到宿主机上的非 root UID。但 OpenClaw 的 MySQL 插件在初始化时需要以 root 权限创建数据库用户userns-remap会导致权限映射失败报错Access denied for user root%。这不是 OpenClaw 的 bug而是 Docker 安全模型与传统数据库初始化流程的冲突。解决方案是在/etc/docker/daemon.json中移除userns-remap字段或明确设为userns-remap: default并确保default用户存在。宿主机必须启用 IPv6即使不用OpenClaw 的健康检查探针healthcheck默认使用curl -f http://localhost:8000/healthz而某些内核版本如 Ubuntu 22.04 的 5.15.0-xx在 IPv6 disabled 时localhost解析会 fallback 到 IPv4 的127.0.0.1但 Docker 的内部 DNS 有时会优先返回 IPv6 地址::1导致 curl 连接超时。最稳妥的解法是sysctl -w net.ipv6.conf.all.disable_ipv60并写入/etc/sysctl.conf持久化。这三点在官方文档里几乎不提但它们是“安装成功”和“安装后稳定运行”之间的真正分水岭。接下来的所有步骤都会围绕这三大隐性依赖做显式校验与加固。3. 核心细节解析从零开始的逐行配置说明与避坑指南3.1 环境准备不是“装好 Docker 就行”而是“装对版本、配对参数”OpenClaw 对 Docker 引擎版本有明确要求最低 20.10.0推荐 24.0.0。低于 20.10 的版本不支持docker composev2 的完整语法如profiles、x-*扩展字段而 OpenClaw 的官方 compose 文件大量使用这些特性。别信网上那些“Ubuntu 20.04 自带 Docker 就能用”的说法——Ubuntu 20.04 默认的docker.io包是 19.03必须手动升级。实操步骤以 Ubuntu 22.04 为例# 1. 卸载旧版如果存在 sudo apt-get remove docker docker-engine docker.io containerd runc # 2. 添加 Docker 官方 GPG 密钥注意必须用 https://download.docker.com/linux/ubuntu不是 archive.ubuntu.com curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /usr/share/keyrings/docker-archive-keyring.gpg # 3. 添加稳定版仓库关键必须指定 jammy不是 focalUbuntu 22.04 代号是 jammy echo deb [arch$(dpkg --print-architecture) signed-by/usr/share/keyrings/docker-archive-keyring.gpg] https://download.docker.com/linux/ubuntu jammy stable | sudo tee /etc/apt/sources.list.d/docker.list /dev/null # 4. 更新并安装安装 docker-ce-cli 和 containerd.io 是必须的漏掉任一包都会导致 compose 失败 sudo apt-get update sudo apt-get install -y docker-ce docker-ce-cli containerd.io # 5. 验证版本必须看到 24.0.x 或 23.0.x docker --version # 输出应为 Docker version 24.0.7, build afdd53b docker compose version # 输出应为 Docker Compose version v2.23.0注意如果你用的是 CentOS 7.9请务必先升级内核到 3.10.0-1160 或更高yum update kernel否则 Docker 24.x 会因 cgroups v2 不兼容而启动失败。CentOS 7.9 默认内核是 3.10.0-1127必须更新。最关键的一步配置 Docker 镜像加速器与 ghcr.io 代理编辑/etc/docker/daemon.json如果不存在则新建{ registry-mirrors: [ https://docker.mirrors.ustc.edu.cn, https://registry.docker-cn.com ], insecure-registries: [], live-restore: true, userns-remap: }重点解释registry-mirrors这里填的是 Docker Hub 的加速器对docker.io有效userns-remap: 显式清空该字段禁用用户命名空间映射前面提到的隐性依赖 #2没有ghcr.io的镜像配置因为ghcr.io不在 Docker Hub 体系内不能用registry-mirrors必须在后续的docker-compose.yml中手动替换镜像地址。保存后重启 Dockersudo systemctl daemon-reload sudo systemctl restart docker # 验证是否生效 sudo docker info | grep Registry Mirrors # 应输出你配置的地址3.2 镜像下载用对命令一次到位拒绝“pull 失败重试十次”现在开始下载核心镜像。记住永远不要用docker pull openclaw/server这种简写因为它会默认拉取docker.io/openclaw/server:latest而这个 latest 很可能不是最新稳定版甚至可能是开发分支。OpenClaw 的版本发布策略是稳定版打vX.Y.Ztag如v0.8.3预发布版打rc-Xtag如rc-4master 分支不打 tag。我们必须精确指定 tag。标准下载命令含清华镜像# 下载 OpenClaw Server使用清华 TUNA ghcr.io 镜像 sudo docker pull ghcr.mirrors.tuna.tsinghua.edu.cn/openclaw/server:v0.8.3 # 下载 MySQL使用阿里云镜像更稳定 sudo docker pull registry.cn-hangzhou.aliyuncs.com/helowin/mysql:8.0 # 下载 Redis使用 Docker Hub 官方镜像国内加速器已配置 sudo docker pull redis:7.0.15-alpine实操心得我曾经在客户现场用docker pull mysql:8.0结果拉下来的是mysql:8.0.34而 OpenClaw v0.8.3 的初始化 SQL 脚本里有一行ALTER USER root% IDENTIFIED WITH caching_sha2_password BY password;但 MySQL 8.0.34 默认禁用了caching_sha2_password插件导致初始化失败。换成registry.cn-hangzhou.aliyuncs.com/helowin/mysql:8.0它基于 8.0.28插件默认启用就一切正常。这就是“用对镜像”的价值——不是越新越好而是越匹配越好。验证镜像完整性必做拉取完成后检查镜像 ID 是否与官方发布页一致 https://github.com/openclaw/openclaw/releases/tag/v0.8.3 # 查看 openclaw/server:v0.8.3 的 digest即内容哈希 sudo docker inspect ghcr.mirrors.tuna.tsinghua.edu.cn/openclaw/server:v0.8.3 --format{{.RepoDigests}} # 输出类似[ghcr.mirrors.tuna.tsinghua.edu.cn/openclaw/serversha256:abc123...] # 将 sha256:abc123... 这段复制去 GitHub Release 页面的 Assets 区域找到 server-v0.8.3-digest.txt 文件打开确认内容完全一致。如果 digest 不匹配说明镜像在传输中损坏或镜像站同步有误必须删除重拉sudo docker rmi ghcr.mirrors.tuna.tsinghua.edu.cn/openclaw/server:v0.8.33.3 docker-compose.yml 配置不只是复制粘贴而是理解每一行的意图这是整个部署中最容易出错的部分。官方提供的docker-compose.yml是为全球开发者写的不是为中国大陆网络环境优化的。我们必须做三处关键修改原始官方配置节选version: 3.8 services: server: image: ghcr.io/openclaw/server:v0.8.3 ports: - 8000:8000 environment: - DB_HOSTmysql - DB_PORT3306 - REDIS_URLredis://redis:6379/0 depends_on: - mysql - redis mysql: image: mysql:8.0 environment: - MYSQL_ROOT_PASSWORDrootpass - MYSQL_DATABASEopenclaw redis: image: redis:7-alpine修改后的生产就绪配置docker-compose.prod.ymlversion: 3.8 services: server: # 【关键修改1】镜像地址替换为清华镜像站 image: ghcr.mirrors.tuna.tsinghua.edu.cn/openclaw/server:v0.8.3 # 【关键修改2】添加健康检查避免服务未就绪就被认为启动成功 healthcheck: test: [CMD, curl, -f, http://localhost:8000/healthz] interval: 30s timeout: 10s retries: 3 start_period: 40s ports: - 8000:8000 environment: # 【关键修改3】显式指定时区避免日志时间错乱 - TZAsia/Shanghai - DB_HOSTmysql - DB_PORT3306 - REDIS_URLredis://redis:6379/0 # 【关键修改4】增加 OpenClaw 特定配置关闭自动更新检查国内无法访问 GitHub API - DISABLE_AUTO_UPDATE_CHECKtrue depends_on: mysql: condition: service_healthy redis: condition: service_healthy mysql: # 【关键修改5】镜像替换为阿里云镜像确保 caching_sha2_password 插件可用 image: registry.cn-hangzhou.aliyuncs.com/helowin/mysql:8.0 # 【关键修改6】挂载初始化 SQL确保数据库结构正确创建 volumes: - ./init.sql:/docker-entrypoint-initdb.d/init.sql environment: - MYSQL_ROOT_PASSWORDrootpass - MYSQL_DATABASEopenclaw # 【关键修改7】强制指定字符集避免中文乱码 - MYSQL_CHARACTER_SET_SERVERutf8mb4 - MYSQL_COLLATION_SERVERutf8mb4_unicode_ci healthcheck: test: [CMD, mysqladmin, ping, -h, localhost, -u, root, -prootpass] interval: 20s timeout: 10s retries: 10 start_period: 40s redis: # 【关键修改8】固定为 7.0.15-alpine规避 musl libc 兼容性问题 image: redis:7.0.15-alpine # 【关键修改9】启用 keyspace 事件支撑 Skill 触发 command: redis-server --notify-keyspace-events KEA healthcheck: test: [CMD, redis-cli, ping] interval: 20s timeout: 10s retries: 10 start_period: 40s配套的init.sql文件内容必须创建-- 创建 openclaw 数据库如果不存在 CREATE DATABASE IF NOT EXISTS openclaw CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; -- 创建专用用户比 root 更安全 CREATE USER openclaw% IDENTIFIED WITH caching_sha2_password BY openclaw123; GRANT ALL PRIVILEGES ON openclaw.* TO openclaw%; -- 刷新权限 FLUSH PRIVILEGES;注意事项init.sql文件必须放在docker-compose.prod.yml同级目录下且文件权限为644chmod 644 init.sql。Docker 在启动 MySQL 容器时会自动执行/docker-entrypoint-initdb.d/目录下的所有.sql文件。这是确保数据库结构与 OpenClaw 期望完全一致的唯一可靠方式。别指望 OpenClaw Server 自己建表——它只做 DML数据操作DDL数据定义必须由 DBA 或初始化脚本完成。3.4 启动与首次配置不是docker-compose up -d就完事配置文件写完进入最后的启动环节。但这不是终点而是观察与校准的开始。第一步后台启动但不急于访问 Web UI# 在 docker-compose.prod.yml 所在目录执行 sudo docker compose -f docker-compose.prod.yml up -d第二步实时观察日志聚焦三个关键容器# 分别查看各容器日志按 CtrlC 退出 sudo docker compose -f docker-compose.prod.yml logs -f mysql sudo docker compose -f docker-compose.prod.yml logs -f redis sudo docker compose -f docker-compose.prod.yml logs -f server日志观察要点按顺序MySQL 日志寻找mysqld: ready for connections和init.sql: OK字样。如果看到ERROR 1045 (28000): Access denied说明init.sql里的密码与MYSQL_ROOT_PASSWORD环境变量不一致立即检查。Redis 日志寻找Ready to accept connections和notify-keyspace-events set to KEA。如果没看到KEA说明command参数没生效检查docker-compose.prod.yml中redis服务的command行缩进是否正确YAML 对空格极其敏感。Server 日志这是最关键的。成功启动会显示server-1 | INFO openclaw/server/main.go:123 Starting OpenClaw server... server-1 | INFO openclaw/server/db.go:45 Connected to MySQL database successfully server-1 | INFO openclaw/server/redis.go:33 Connected to Redis successfully server-1 | INFO openclaw/server/main.go:156 OpenClaw server started on http://0.0.0.0:8000如果卡在Connected to MySQL database...超过 60 秒说明网络不通或密码错误如果报failed to ping redis: dial tcp 172.20.0.3:6379: connect: connection refused说明 Redis 容器没起来或depends_on的condition没生效检查 Docker Compose 版本是否够新。第三步Web UI 首次访问与管理员创建当 Server 日志显示started on http://0.0.0.0:8000后在浏览器访问http://你的服务器IP:8000。首次访问会跳转到/auth/signup页面。用户名任意但建议用公司邮箱前缀如adminyourcompany密码必须包含大小写字母、数字、特殊字符长度 ≥8确认密码同上API Key留空系统会自动生成。提交后页面会跳转到/dashboard此时你已经是超级管理员。立刻点击右上角头像 → Settings → API Keys → Generate New Key复制保存这个 key。它是后续所有 Skill 调用、CLI 工具认证的唯一凭证丢失后只能删库重装。实操心得我见过太多人第一次登录后直接开始写 Skill结果发现 API Key 没保存第二天想用 CLI 调试时傻眼。OpenClaw 的 API Key 是一次性显示的页面刷新后就再也看不到明文。所以生成后第一件事echo OPENCLAW_API_KEYxxx ~/.bashrc source ~/.bashrc把它存进环境变量。4. 实操过程详解从零到第一个可运行 Skill 的完整闭环4.1 技能Skill的本质不是代码而是声明式工作流在 OpenClaw 里“写一个 Skill” 和 “写一段 Python 脚本” 是两回事。Skill 的核心是一个 YAML 文件它描述“做什么”而不是“怎么做”。例如一个最简单的“发送飞书消息” Skill其 YAML 如下# send_feishu_message.yaml name: Send Feishu Message description: Send a text message to a Feishu group via webhook version: 1.0.0 trigger: type: http method: POST path: /feishu/send input: - name: message type: string required: true description: The text content to send steps: - id: prepare_payload type: inline script: | const payload { msg_type: text, content: { text: input.message } }; return { payload: JSON.stringify(payload) }; - id: call_feishu_webhook type: http method: POST url: https://open.feishu.cn/open-apis/bot/v2/send headers: Content-Type: application/json Authorization: Bearer {{ secrets.FEISHU_BOT_TOKEN }} body: {{ steps.prepare_payload.outputs.payload }} output: - name: response type: object description: Feishu API response这个 YAML 文件定义了一个 HTTP 触发的 Skill接收一个message参数构造 JSON 有效载荷然后调用飞书机器人 API。注意几个关键点trigger.type: http表示这是一个 Webhook可通过POST http://server:8000/feishu/send调用input和output定义了 Skill 的契约Contract其他系统调用它时只需关心输入输出无需知道内部实现steps是真正的执行逻辑支持inline内联 JS、httpHTTP 调用、mysql数据库查询、redis缓存操作等多种类型{{ secrets.FEISHU_BOT_TOKEN }}这是一个密钥引用值存储在 OpenClaw 的密钥管理系统中不会硬编码在 YAML 里保证安全性。4.2 上传 SkillCLI 工具比 Web UI 更可靠、更可追溯OpenClaw 提供了 Web UI 上传 Skill但生产环境强烈推荐使用 CLI 工具ocli。原因有三一是 CLI 支持批量上传、版本管理、diff 比较二是所有操作都有完整日志便于审计三是可以集成到 GitOps 流程中实现 Skill 的代码化管理。安装与配置ocli# 下载 ocli同样使用清华镜像 curl -L https://ghcr.mirrors.tuna.tsinghua.edu.cn/openclaw/cli/releases/download/v0.8.3/ocli-linux-amd64 -o ocli chmod x ocli sudo mv ocli /usr/local/bin/ # 配置服务器地址和 API Key ocli config set server http://localhost:8000 ocli config set api-key 你之前保存的 API Key上传 Skill# 创建一个目录存放 Skill mkdir -p ~/openclaw-skills/feishu cp send_feishu_message.yaml ~/openclaw-skills/feishu/ # 上传-f 指定文件-n 指定 Skill 名--force 覆盖同名旧版本 ocli skill upload -f ~/openclaw-skills/feishu/send_feishu_message.yaml -n send-feishu-message --force # 查看上传结果 ocli skill list # 输出应包含send-feishu-message | Send Feishu Message | 1.0.0 | active注意ocli skill upload命令会校验 YAML 语法、检查trigger.path是否与其他 Skill 冲突、验证secrets引用是否存在。如果报错Secret FEISHU_BOT_TOKEN not found说明你还没创建这个密钥。4.3 创建密钥Secret安全存储敏感信息的唯一方式OpenClaw 的密钥管理是独立于 Skill 的。你不能在 YAML 里写死Bearer abc123而必须先在系统里创建一个名为FEISHU_BOT_TOKEN的密钥再在 Skill 中引用。通过 CLI 创建密钥# 创建一个名为 FEISHU_BOT_TOKEN 的密钥值为你从飞书机器人后台获取的 token ocli secret create FEISHU_BOT_TOKEN t-xxx-yyy-zzz # 查看所有密钥不显示明文 ocli secret list # 输出FEISHU_BOT_TOKEN | created 2023-10-05T10:20:30Z通过 Web UI 创建备用方案访问http://server:8000/settings/secrets→ 点击 Add Secret→ 输入 NameFEISHU_BOT_TOKENValuet-xxx-yyy-zzz→ Save。验证密钥是否生效重新上传 Skill或用ocli skill update如果不再报Secret not found错误说明密钥已就绪。4.4 测试 Skill用 curl 模拟真实调用观察全链路日志现在Skill 已上传密钥已配置是时候发起第一次真实调用了。发送测试请求curl -X POST http://localhost:8000/feishu/send \ -H Content-Type: application/json \ -H Authorization: Bearer 你的 API Key \ -d {message:Hello from OpenClaw!}预期响应{ id: exec-abc123, status: success, output: { response: { code: 0, msg: success, data: { message_id: om-xxx } } } }如果失败按此顺序排查检查 Server 日志sudo docker compose -f docker-compose.prod.yml logs -f server | grep feishu/send看是否有404 Not FoundSkill 未激活或401 UnauthorizedAPI Key 错误检查 Skill 状态ocli skill list确认send-feishu-message的状态是active不是inactive或error检查密钥值ocli secret get FEISHU_BOT_TOKENCLI 会提示无法显示明文但你可以用ocli secret update重新设置一遍强制刷新检查飞书 webhook 地址确保https://open.feishu.cn/open-apis/bot/v2/send是可访问的在服务器上curl -I https://open.feishu.cn测试 DNS 和连通性。实操心得我在某电商客户部署时测试一直失败最后发现是他们的防火墙策略禁止了出向443端口到open.feishu.cn的连接。解决方案不是改 OpenClaw而是在服务器上配置了飞书的国内 CDN 域名https://open.feishu.cn的白名单。这再次印证OpenClaw 的部署70% 是网络和基础设施问题30% 才是配置问题。5. 常见问题与排查技巧实录来自 17 次现场部署的真实记录5.1 问题速查表高频报错与一招解决报错现象根本原因快速解决命令预防措施ERROR: failed to solve: rpc error: code Unknown desc failed to solve with frontend dockerfile.v0: failed to create LLB definition: failed to authorize: rpc error: code Unknown desc failed to fetch anonymous token: Get https://ghcr.io/token?scoperepository%3Aopenclaw%2Fserver%3Apullserviceghcr.io: net/http