如果你也遇到过这种情况——拿到一台完全隔离的内网服务器要求在它上面把 Openclaw 服务部署起来而整个环境既没有外网访问权限也没有可用的软件源镜像那这篇方案应该能帮到你。这套 Openclaw 2026.3.7 Docker 离线部署方案是我在实际交付过程中整理出来的。核心就四件事在联网机器上做好镜像打包、把离线包安全搬进内网、在内网完成加载与编排、最后做一套可重复的功能验证。先把这个方案解决的核心问题说清楚。在线部署的时候命令基本就三条拉镜像、写 compose、启动。到了内网环境这三条全都会被卡住。没有软件源装不了环境依赖没有镜像仓库访问权限拉不了镜像如果连 DNS 都不通甚至连外网地址都解析不了。更麻烦的是Openclaw 这类服务通常不是一个容器就能跑起来的它至少要依赖一个数据库实例和一个缓存实例也就是说你需要的不是一个镜像而是一整组镜像。我在动手前给自己定了三条验收标准这三条标准决定了后面所有打包和编排的细节。第一交付物必须能在全新服务器上按文档从零复现。也就是说只要拿到这套离线包再跟着文档操作即使执行的人没有参与过最初构建也能完成部署。这意味着所有命令、所有镜像、所有配置都必须是完整的不存在到时候再查一下这种悬空环节。第二交付物必须是一个独立目录而不是一堆聊天记录里的命令。离线部署的时间窗口通常很短要是临时发现少了某个镜像或者配置文件很难再回外网补一次。第三整个部署过程不能依赖任何外网资源。包括镜像仓库、软件源、公共 DNS统统不能依赖。只有把这三条标准想清楚后面的结构才不会走偏。我最终交付的离线包目录大概长这样openclaw-offline-2026.3.7/ ├── images/ │ ├── openclaw-2026.3.7.tar.gz │ ├── postgres-15.4-alpine.tar.gz │ ├── redis-7.2-alpine.tar.gz │ └── sha256sums.txt ├── config/ │ ├── docker-compose.yml │ ├── .env.example │ └── deployment.md └── scripts/ ├── 01-load-images.sh ├── 02-import-registry.sh └── 03-verify.shimages 目录装的是所有镜像的归档文件config 目录装的是编排文件和环境变量模板scripts 目录把重复性操作固化成脚本。这个结构不一定适合所有项目但如果你也在做类似交付可以参考这个思路镜像与配置分离、配置与脚本分离、文档与操作分离。1. 离线部署这件事难点到底在哪儿很多人在刚开始做离线部署时会有一个误解觉得离线部署不过是把在线安装的步骤照抄一遍只是把拉镜像换成了导入镜像包。但实际跑一遍就会发现在线环境里大量默认就有的能力到了内网全部要靠自己补齐。1.1 在线部署的顺手恰恰是离线部署最大的障碍在线环境里你根本不需要考虑镜像从哪来docker pull 直接解决不需要考虑容器启动时要不要联网宿主机的网络环境天然可用不需要考虑 DNS 解析问题公共 DNS 就在那。但内网环境把这些便利全部拿掉之后你才发现一条 docker compose up -d 背后藏了多少隐式依赖。Openclaw 这种服务更明显。它启动时要连数据库、连缓存这些依赖服务的镜像也得一起准备好。更不起眼的是很多镜像构建时基于的基础镜像比如 alpine、debian-slim一旦缺失整个镜像就无法加载。所以离线部署的第一难点不是Docker 怎么用而是你要把所有隐式依赖提前暴露出来并一一打包。1.2 我给自己定的三条验收标准这次做完 Openclaw 2026.3.7 的离线包之后我把整个部署流程沉淀成了一套固定动作。以后不管换到哪台内网机器执行节奏都是一样的校验离线包完整性加载镜像或者推送到内网仓库调整 compose 文件和环境变量启动并跑验证清单。这四条按顺序下来中间不需要临时查文档也不需要临时摸去外网补镜像。三条验收标准里我最看重第一条可复现。因为离线部署一旦出错排查窗口往往很短你不希望到现场才发现交付物缺胳膊少腿。1.3 镜像归集与配置分离在交付目录里我把 images 和 config 拆开是有意为之的。镜像归档是二进制文件体积大、基本不会变动compose 文件和 .env 是文本文件会随着不同内网环境的网络规划、资源限制而调整。把两者分离之后同一个镜像包可以重复使用不用为每台服务器重新打一次包。另外我还放了一个 scripts 目录专门放加载脚本和校验脚本。原因是人工敲命令最容易出错尤其在连续操作好几个 G 的镜像包时。脚本化之后执行人只需要按编号一步步跑每一步都有明确的输出出错时也能直接定位到是加载问题还是网络问题。2. 打包阶段联网机器上需要完成的准备工作离线部署的第一步是在一台能正常访问外网的机器上把镜像准备好。这个阶段看起来简单实际最容易埋雷。镜像架构、导出命令、依赖清单任何一个环节漏掉到了内网都会变成数小时起步的排查时间。2.1 先确认目标服务器的 CPU 架构打包之前必须知道内网服务器的 CPU 架构。这一步决定了你要拉取的是 x86_64 镜像还是 arm64 镜像。查询命令很简单docker image inspect openclaw/openclaw:2026.3.7 --format {{.Architecture}}如果你是在 x86 机器上打包但内网服务器是 ARM 架构直接用默认参数 pull 出来的镜像load 进内网后大概率启动不了或者报错报得莫名其妙。拉取时可以显式指定平台docker pull --platform linux/arm64 openclaw/openclaw:2026.3.7指定了--platform之后docker save 出来的镜像归档里架构字段就是linux/arm64load 到 ARM 服务器上才能正常工作。我见过有同事在打包时没有指定平台结果所有镜像都按 x86 拉取到了 ARM 服务器上只有基础镜像能跑应用镜像全都报exec format error日志里又看不出任何配置问题。还有一个很容易被忽略的点打包机器的 Docker 版本最好不低于内网服务器的 Docker 版本。虽然镜像格式有向后兼容的设计但比较新的镜像层压缩格式在很老版本的 Docker 上 load 时可能遇到unknown compression algorithm这类报错。稳妥的做法是提前确认两边 Docker 版本差距不要太大。2.2 用 docker save 而不是 docker export这一步是我最想强调的细节。导出镜像有两种命令docker save和docker export很多人会把它们弄混。docker save导出的是镜像本身的完整结构包括每一层、环境变量、入口命令、标签信息docker export导出的是某个容器的文件系统它会丢失镜像的历史层和元数据。离线部署必须用docker save因为导入之后你仍然要以镜像的方式运行而不是以裸文件系统的方式运行。实际操作中我习惯用归档加压缩的方式一条命令完成docker save openclaw/openclaw:2026.3.7 | gzip images/openclaw-2026.3.7.tar.gz压缩的好处是传输体积能明显降下来。如果镜像很大归档文件有几个 G 甚至十几个 G还可以再拆成多卷split -b 4G -d openclaw-2026.3.7.tar.gz openclaw-2026.3.7.tar.gz_到了内网再合并cat openclaw-2026.3.7.tar.gz_* openclaw-2026.3.7.tar.gz分卷和合并本身不复杂真正需要养成习惯的是在传输前计算校验值。用 sha256sum 生成一份清单随镜像包一起带到内网sha256sum images/*.tar.gz images/sha256sums.txt数据包在内网传输过程中经历过移动硬盘拷贝、网络共享、其他中转方式之后是否完整其实是不确定的。我遇到过归档文件在传输中少了一个分卷加载时 Docker 也不报明显错误最后是启动阶段才暴露出缺层的诡异问题。有了校验清单加上一个核对步骤这类问题就能提前挡掉。2.3 依赖镜像一个都不能少Openclaw 这类服务很少是单个容器独立运行的。我这次部署的版本就依赖一个 PostgreSQL 数据库实例和一个 Redis 缓存实例。如果你在联网环境下已经用 docker compose 跑通过可以直接用这条命令把 compose 里实际引用的镜像完整展开docker compose config --images这条命令比人工一个个翻配置文件可靠得多。列出来之后逐一执行 docker save 归档。还有一个容易漏的点compose 里可能引用了辅助容器比如初始化数据库的 migrate 容器这类容器只在启动时运行一段脚本如果漏掉它后面 Openclaw 主服务启动时会一直报连不上数据库。打包阶段的最后用docker images检查所有镜像是否已经在本地。确认没有遗漏后再进入下一步。宁可在这里多花十分钟核对清单也不要等到了内网才发现缺这个缺那个。3. 镜像进内网的两种主流路径与我的选型取舍镜像打包完之后核心问题就是如何把它们弄进隔离的服务器。通常有两条路用 docker load 直接加载归档或者在内网部署一个私有镜像仓库再把镜像推上去。3.1 路径 Adocker load适合少量节点最简单直接的方式把归档文件拷贝到内网服务器上然后一条命令加载docker load -i images/openclaw-2026.3.7.tar.gz加载完成后用docker images确认镜像名称和标签。这里有个常见问题docker save 归档里保存的是打包时的完整镜像名和标签。如果内网里你需要改成私有仓库地址的命名加载后得再打一次 tagdocker tag openclaw/openclaw:2026.3.7 192.168.1.100:5000/openclaw/openclaw:2026.3.7docker load 适合镜像数量少、节点数量也少的场景。比如单机部署或者最多两三台机器直接 load 就够了不需要额外考虑镜像仓库的维护问题。3.2 路径 B私有镜像仓库适合规模化环境如果内网节点很多一台一台 load 显然不现实。这种场景下我会在隔离环境里先部署一个私有镜像仓库然后把离线包里的镜像全部 push 进去。最简单的方式是直接用 registry 容器docker run -d --name registry --restartalways -p 5000:5000 -v /opt/registry:/var/lib/registry registry:2注意registry 这个容器本身的镜像也需要提前打包进离线包里否则内网环境同样拉取不到。推送前把镜像重新打标签改成内网仓库地址docker tag openclaw/openclaw:2026.3.7 192.168.1.100:5000/openclaw/openclaw:2026.3.7 docker push 192.168.1.100:5000/openclaw/openclaw:2026.3.7这里有一个内网环境非常典型的拦截点如果你的私有镜像仓库没有配置 TLS 证书Docker 默认会拒绝通过 HTTP 方式推送。解决办法是在内网每台节点的/etc/docker/daemon.json里配置 insecure-registries{ insecure-registries: [192.168.1.100:5000] }修改完 daemon 配置后需要重启 Dockersystemctl restart docker如果你所在团队已经有现成的镜像仓库那就更简单了直接把离线包推到已有仓库即可不需要额外部署一个新的。3.3 两种路径可以同时保留我最后交付的方案里两条路径都保留了。为什么因为不同内网环境的现状差异很大。有的团队已经维护了自己的镜像仓库离线包只需要推到已有仓库有的环境则什么组件都不让装registry 这种新容器可能还要走额外的审批流程这时直接 load 反而更省事。所以我只是把 01-load-images.sh 和 02-import-registry.sh 两个脚本都放进交付目录并写明各自的适用场景。使用者按自己的内网条件选一条不会因为没有某个组件而被卡死。这里也提醒一句无论走哪条路径镜像打好 tag 并推送到仓库之后原始归档文件不要急着删留到验证完成后再处理。因为如果仓库临时出问题至少还能重新 load。4. compose 启动之前内网特有的配置调整点镜像就位只是第一步真正决定部署能否一次成功的是 compose 编排文件里的那些细节。很多在线环境里不是问题的配置到了内网全部变成必须处理的坑。这一段我按实际使用顺序来写你照着一项项核对基本能避开大多数坑。4.1 显式关闭自动拉取和隐式依赖在线部署时docker compose up -d 会自动去远程仓库拉取缺失的镜像。内网环境没有这个能力所以在 compose 文件里尽量显式声明pull_policy: never强制 Docker 只使用本地已经存在的镜像。否则 compose 仍然会尝试访问远程仓库连接不通时整段启动过程可能卡在拉取阶段半天不报错。我这次使用的 compose 文件结构大致如下services: postgres: image: 192.168.1.100:5000/postgres/postgres:15.4-alpine environment: POSTGRES_DB: openclaw POSTGRES_USER: openclaw POSTGRES_PASSWORD: ${POSTGRES_PASSWORD} volumes: - pg_data:/var/lib/postgresql/data healthcheck: test: [CMD-SHELL, pg_isready -U openclaw -d openclaw] interval: 10s timeout: 5s retries: 5 networks: - openclaw_net redis: image: 192.168.1.100:5000/redis/redis:7.2-alpine healthcheck: test: [CMD, redis-cli, ping] interval: 10s timeout: 5s retries: 5 networks: - openclaw_net openclaw: image: 192.168.1.100:5000/openclaw/openclaw:2026.3.7 pull_policy: never depends_on: postgres: condition: service_healthy redis: condition: service_healthy ports: - 8080:8080 environment: OPENCLAW_DB_URL: postgresql://openclaw:${POSTGRES_PASSWORD}postgres:5432/openclaw OPENCLAW_REDIS_URL: redis://redis:6379/0 OPENCLAW_LOG_LEVEL: info volumes: - openclaw_data:/opt/openclaw/data - openclaw_config:/opt/openclaw/config healthcheck: test: [CMD, curl, -f, http://127.0.0.1:8080/health] interval: 30s timeout: 10s retries: 5 start_period: 40s networks: - openclaw_net volumes: pg_data: openclaw_data: openclaw_config: networks: openclaw_net: driver: bridge提示上面的环境变量名、健康检查路径是我在实际版本里写出来的典型形态。不同版本的 Openclaw 命名可能有差异拿到镜像后先跑一次docker history或者docker inspect确认真正的环境变量名再套用文件。4.2 健康检查决定启动顺序不只是好习惯很多人部署时不加 healthcheck因为在线环境下docker compose 默认的启动顺序基本够用。但如果数据库或缓存还没就绪就让 Openclaw 启动它会在启动阶段反复重试连接严重时会造成初始化失败。所以我在依赖服务上都加了 healthcheck并在 Openclaw 上用 condition 语法等待它们健康后再启动。这个写法的效果是只有当 PostgreSQL 返回pg_isready成功、Redis 返回PONG之后Openclaw 才会被拉起。需要注意的是condition: service_healthy这种写法需要 Docker Compose v2 支持如果你的内网服务器还在用很早期的 docker-compose v1可能需要先升级或者改用一个等待脚本。start_period参数也别省。Openclaw 这类服务启动时可能要做配置解析、建表、迁移前几十秒探活失败是正常的。没有 start_period 的话健康检查会按固定间隔重试一旦超过 retries 次数就标记为不健康哪怕服务只是启动慢了一点。4.3 数据持久化、日志轮转和 .env 管理离线环境里没有云厂商的后置存储数据一旦丢失恢复成本非常高。所以数据库和主服务的数据目录必须用命名卷或绑定挂载落到宿主机。我上面写的是命名卷方案实际部署时也可以用宿主机路径/opt/openclaw/pgdata:/var/lib/postgresql/data /opt/openclaw/appdata:/opt/openclaw/data日志也得提前想好。容器默认的 json-file 日志会无限增长内网磁盘空间本来就紧张建议显式配置轮转logging: driver: json-file options: max-size: 20m max-file: 5还有一个容易被忽略的问题密码和敏感配置不能直接写死在 compose 文件里。我在交付包里只放.env.example不填真实密码。部署时复制一份.env填入符合内网要求的强密码。好处是交付包可以反复流转不会带出敏感凭据。5. 启动之后的验证标准与回滚预案离线部署不是容器起来了就算成功它是一门需要验收标准的工程。我把部署完成后的验证项整理成了一张清单每次部署结束之后照着跑一遍能省掉后面很多折腾。检查项操作期望结果容器状态docker compose ps所有服务 UpOpenclaw 显示 healthy健康检查接口curl -fsS http://127.0.0.1:8080/health返回 HTTP 200主应用日志docker compose logs --tail200 openclaw无连续的 Error 级别日志数据库连接docker compose exec postgres pg_isready -U openclaw返回 accepting connections数据落盘docker volume inspect openclaw_openclaw_dataMountpoint 目录存在内网访问从内网另一台机器访问服务地址页面或接口可以正常打开每一项都有意义而不是走过场。容器状态只能证明进程在跑健康检查接口证明服务真的响应了数据库连接证明主服务和数据库之间的链路通了内网访问证明端口映射和网络策略都没问题。5.1 回滚预案数据卷不动镜像换一下一旦部署后出现线上问题回滚的第一原则是数据卷不动镜像换一下。因为 Openclaw 的数据基本都存在命名卷里回滚只是把 compose 文件里的 image 标签切回旧版本再 up 一次。前提是旧版本镜像在内网里还有保留。我建议打包时把旧版本镜像也一并导入原因就在这。有一个很关键的坑千万别顺手执行docker compose down -v。-v参数会把命名卷一并删掉数据一旦删除回滚就无从谈起。日常维护只需要docker compose down不带任何删除数据参数。5.2 平滑升级的固定步骤如果要升级到下一个版本我的操作顺序是固定的备份数据卷或者至少把数据目录完整拷贝一份在联网机器上拉取新版本镜像导出归档传输到内网load 并 push 进镜像仓库修改 compose 文件里的 image 标签重新 up跑一遍验证清单。这六步里最容易忽略的是第一步。备份动作一定要独立写一份命令文档跟着执行不要靠记忆。很多线上事故都是升级前没做备份结果配置迁移失败后进退两难。6. 几个差点让我翻车的细节问题前面梳理的都是主线流程最后聊几个实际操作中真真切切踩过的坑。每一个都耽误过不少时间整理出来给后来人提个醒。6.1 架构不匹配报错和原因对不上这是离线部署里最隐蔽的问题之一。在 x86 机器上打包内网服务器却可能是 ARM 架构。如果一开始不知道这个情况启动后的常见现象是容器反复重启日志里只有一行exec format error。这个报错和镜像损坏、配置错误的表面现象完全不同很容易让人往配置文件方向排查实际上原因只是架构不一致。排查命令很简单docker image inspect openclaw/openclaw:2026.3.7 --format {{.Architecture}}如果在打包机器上显示amd64而目标服务器是 ARM就必须重新用--platform linux/arm64拉取后再打包。6.2 健康检查接口不要死抄模板我把健康检查地址写成了 /health但很多服务的实际健康检查接口并不是这个路径。有的叫 /status有的根本没有健康检查接口。这种情况下健康检查不能写 HTTP 探测可以退而求其次用进程检查比如检查主进程是否存活healthcheck: test: [CMD-SHELL, pgrep -f openclaw || exit 1] interval: 30s timeout: 10s retries: 3原则很简单健康检查必须对应服务自身的真实探活能力。宁可保守一点也不要写一个永远失败的探活脚本。6.3 容器时间不同步引发的诡异问题这是一个藏在镜像里的坑。容器继承的是宿主机内核时间如果宿主机时间不对容器内的服务可能不会立刻报错但在日志时间戳、缓存过期、账号有效期这些场景里会表现出间歇性的异常。内网服务器如果长期没有时间同步策略时间偏差可能达到几分钟甚至更长。部署前先把宿主机的时钟校准一遍至少要在部署文档里加一条检查命令date timedatectl status如果内网没有可用的时间服务器也要尽量人工校准到接近真实时间否则后续排查问题的成本会很高。6.4 大文件传输后一定要核对完整性镜像归档文件动辄好几个 G传输过程出问题并不是小概率事件。我遇到过一种情况归档文件大小看起来没少但加载时 Docker 提示某个 layer 不存在后来才发现是传输过程中文件被截断了。从那以后所有归档文件都走 sha256 校验流程。生成校验清单在工作目录里执行传输到内网后执行一次校验确认两边完全一致后再进入 load 或 push 阶段。这几次部署之后我的习惯是只要执行完验证清单就把整个交付目录重新归档一次命名加上日期和镜像版本。这样做的好处是下次任何一个同事接手都只需要照着同一个目录结构操作不需要再来问我当时的命令是什么。离线部署这件事本身不难难的是把每一个步骤固定成可复现的流程。希望这份 Openclaw 2026.3.7 Docker 离线部署方案能帮你少走几步弯路。