如果你也遇到過這種情況——拿到一臺完全隔離的內(nèi)網(wǎng)服務器要求在它上面把 Openclaw 服務部署起來而整個環(huán)境既沒有外網(wǎng)訪問權(quán)限也沒有可用的軟件源鏡像那這篇方案應該能幫到你。這套 Openclaw 2026.3.7 Docker 離線部署方案是我在實際交付過程中整理出來的。核心就四件事在聯(lián)網(wǎng)機器上做好鏡像打包、把離線包安全搬進內(nèi)網(wǎng)、在內(nèi)網(wǎng)完成加載與編排、最后做一套可重復的功能驗證。先把這個方案解決的核心問題說清楚。在線部署的時候命令基本就三條拉鏡像、寫 compose、啟動。到了內(nèi)網(wǎng)環(huán)境這三條全都會被卡住。沒有軟件源裝不了環(huán)境依賴沒有鏡像倉庫訪問權(quán)限拉不了鏡像如果連 DNS 都不通甚至連外網(wǎng)地址都解析不了。更麻煩的是Openclaw 這類服務通常不是一個容器就能跑起來的它至少要依賴一個數(shù)據(jù)庫實例和一個緩存實例也就是說你需要的不是一個鏡像而是一整組鏡像。我在動手前給自己定了三條驗收標準這三條標準決定了后面所有打包和編排的細節(jié)。第一交付物必須能在全新服務器上按文檔從零復現(xiàn)。也就是說只要拿到這套離線包再跟著文檔操作即使執(zhí)行的人沒有參與過最初構(gòu)建也能完成部署。這意味著所有命令、所有鏡像、所有配置都必須是完整的不存在到時候再查一下這種懸空環(huán)節(jié)。第二交付物必須是一個獨立目錄而不是一堆聊天記錄里的命令。離線部署的時間窗口通常很短要是臨時發(fā)現(xiàn)少了某個鏡像或者配置文件很難再回外網(wǎng)補一次。第三整個部署過程不能依賴任何外網(wǎng)資源。包括鏡像倉庫、軟件源、公共 DNS統(tǒng)統(tǒng)不能依賴。只有把這三條標準想清楚后面的結(jié)構(gòu)才不會走偏。我最終交付的離線包目錄大概長這樣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 目錄裝的是編排文件和環(huán)境變量模板scripts 目錄把重復性操作固化成腳本。這個結(jié)構(gòu)不一定適合所有項目但如果你也在做類似交付可以參考這個思路鏡像與配置分離、配置與腳本分離、文檔與操作分離。1. 離線部署這件事難點到底在哪兒很多人在剛開始做離線部署時會有一個誤解覺得離線部署不過是把在線安裝的步驟照抄一遍只是把拉鏡像換成了導入鏡像包。但實際跑一遍就會發(fā)現(xiàn)在線環(huán)境里大量默認就有的能力到了內(nèi)網(wǎng)全部要靠自己補齊。1.1 在線部署的順手恰恰是離線部署最大的障礙在線環(huán)境里你根本不需要考慮鏡像從哪來docker pull 直接解決不需要考慮容器啟動時要不要聯(lián)網(wǎng)宿主機的網(wǎng)絡(luò)環(huán)境天然可用不需要考慮 DNS 解析問題公共 DNS 就在那。但內(nèi)網(wǎng)環(huán)境把這些便利全部拿掉之后你才發(fā)現(xiàn)一條 docker compose up -d 背后藏了多少隱式依賴。Openclaw 這種服務更明顯。它啟動時要連數(shù)據(jù)庫、連緩存這些依賴服務的鏡像也得一起準備好。更不起眼的是很多鏡像構(gòu)建時基于的基礎(chǔ)鏡像比如 alpine、debian-slim一旦缺失整個鏡像就無法加載。所以離線部署的第一難點不是Docker 怎么用而是你要把所有隱式依賴提前暴露出來并一一打包。1.2 我給自己定的三條驗收標準這次做完 Openclaw 2026.3.7 的離線包之后我把整個部署流程沉淀成了一套固定動作。以后不管換到哪臺內(nèi)網(wǎng)機器執(zhí)行節(jié)奏都是一樣的校驗離線包完整性加載鏡像或者推送到內(nèi)網(wǎng)倉庫調(diào)整 compose 文件和環(huán)境變量啟動并跑驗證清單。這四條按順序下來中間不需要臨時查文檔也不需要臨時摸去外網(wǎng)補鏡像。三條驗收標準里我最看重第一條可復現(xiàn)。因為離線部署一旦出錯排查窗口往往很短你不希望到現(xiàn)場才發(fā)現(xiàn)交付物缺胳膊少腿。1.3 鏡像歸集與配置分離在交付目錄里我把 images 和 config 拆開是有意為之的。鏡像歸檔是二進制文件體積大、基本不會變動compose 文件和 .env 是文本文件會隨著不同內(nèi)網(wǎng)環(huán)境的網(wǎng)絡(luò)規(guī)劃、資源限制而調(diào)整。把兩者分離之后同一個鏡像包可以重復使用不用為每臺服務器重新打一次包。另外我還放了一個 scripts 目錄專門放加載腳本和校驗腳本。原因是人工敲命令最容易出錯尤其在連續(xù)操作好幾個 G 的鏡像包時。腳本化之后執(zhí)行人只需要按編號一步步跑每一步都有明確的輸出出錯時也能直接定位到是加載問題還是網(wǎng)絡(luò)問題。2. 打包階段聯(lián)網(wǎng)機器上需要完成的準備工作離線部署的第一步是在一臺能正常訪問外網(wǎng)的機器上把鏡像準備好。這個階段看起來簡單實際最容易埋雷。鏡像架構(gòu)、導出命令、依賴清單任何一個環(huán)節(jié)漏掉到了內(nèi)網(wǎng)都會變成數(shù)小時起步的排查時間。2.1 先確認目標服務器的 CPU 架構(gòu)打包之前必須知道內(nèi)網(wǎng)服務器的 CPU 架構(gòu)。這一步?jīng)Q定了你要拉取的是 x86_64 鏡像還是 arm64 鏡像。查詢命令很簡單docker image inspect openclaw/openclaw:2026.3.7 --format {{.Architecture}}如果你是在 x86 機器上打包但內(nèi)網(wǎng)服務器是 ARM 架構(gòu)直接用默認參數(shù) pull 出來的鏡像load 進內(nèi)網(wǎng)后大概率啟動不了或者報錯報得莫名其妙。拉取時可以顯式指定平臺docker pull --platform linux/arm64 openclaw/openclaw:2026.3.7指定了--platform之后docker save 出來的鏡像歸檔里架構(gòu)字段就是linux/arm64load 到 ARM 服務器上才能正常工作。我見過有同事在打包時沒有指定平臺結(jié)果所有鏡像都按 x86 拉取到了 ARM 服務器上只有基礎(chǔ)鏡像能跑應用鏡像全都報exec format error日志里又看不出任何配置問題。還有一個很容易被忽略的點打包機器的 Docker 版本最好不低于內(nèi)網(wǎng)服務器的 Docker 版本。雖然鏡像格式有向后兼容的設(shè)計但比較新的鏡像層壓縮格式在很老版本的 Docker 上 load 時可能遇到unknown compression algorithm這類報錯。穩(wěn)妥的做法是提前確認兩邊 Docker 版本差距不要太大。2.2 用 docker save 而不是 docker export這一步是我最想強調(diào)的細節(jié)。導出鏡像有兩種命令docker save和docker export很多人會把它們弄混。docker save導出的是鏡像本身的完整結(jié)構(gòu)包括每一層、環(huán)境變量、入口命令、標簽信息docker export導出的是某個容器的文件系統(tǒng)它會丟失鏡像的歷史層和元數(shù)據(jù)。離線部署必須用docker save因為導入之后你仍然要以鏡像的方式運行而不是以裸文件系統(tǒng)的方式運行。實際操作中我習慣用歸檔加壓縮的方式一條命令完成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_到了內(nèi)網(wǎng)再合并cat openclaw-2026.3.7.tar.gz_* openclaw-2026.3.7.tar.gz分卷和合并本身不復雜真正需要養(yǎng)成習慣的是在傳輸前計算校驗值。用 sha256sum 生成一份清單隨鏡像包一起帶到內(nèi)網(wǎng)sha256sum images/*.tar.gz images/sha256sums.txt數(shù)據(jù)包在內(nèi)網(wǎng)傳輸過程中經(jīng)歷過移動硬盤拷貝、網(wǎng)絡(luò)共享、其他中轉(zhuǎn)方式之后是否完整其實是不確定的。我遇到過歸檔文件在傳輸中少了一個分卷加載時 Docker 也不報明顯錯誤最后是啟動階段才暴露出缺層的詭異問題。有了校驗清單加上一個核對步驟這類問題就能提前擋掉。2.3 依賴鏡像一個都不能少Openclaw 這類服務很少是單個容器獨立運行的。我這次部署的版本就依賴一個 PostgreSQL 數(shù)據(jù)庫實例和一個 Redis 緩存實例。如果你在聯(lián)網(wǎng)環(huán)境下已經(jīng)用 docker compose 跑通過可以直接用這條命令把 compose 里實際引用的鏡像完整展開docker compose config --images這條命令比人工一個個翻配置文件可靠得多。列出來之后逐一執(zhí)行 docker save 歸檔。還有一個容易漏的點compose 里可能引用了輔助容器比如初始化數(shù)據(jù)庫的 migrate 容器這類容器只在啟動時運行一段腳本如果漏掉它后面 Openclaw 主服務啟動時會一直報連不上數(shù)據(jù)庫。打包階段的最后用docker images檢查所有鏡像是否已經(jīng)在本地。確認沒有遺漏后再進入下一步。寧可在這里多花十分鐘核對清單也不要等到了內(nèi)網(wǎng)才發(fā)現(xiàn)缺這個缺那個。3. 鏡像進內(nèi)網(wǎng)的兩種主流路徑與我的選型取舍鏡像打包完之后核心問題就是如何把它們弄進隔離的服務器。通常有兩條路用 docker load 直接加載歸檔或者在內(nèi)網(wǎng)部署一個私有鏡像倉庫再把鏡像推上去。3.1 路徑 Adocker load適合少量節(jié)點最簡單直接的方式把歸檔文件拷貝到內(nèi)網(wǎng)服務器上然后一條命令加載docker load -i images/openclaw-2026.3.7.tar.gz加載完成后用docker images確認鏡像名稱和標簽。這里有個常見問題docker save 歸檔里保存的是打包時的完整鏡像名和標簽。如果內(nèi)網(wǎng)里你需要改成私有倉庫地址的命名加載后得再打一次 tagdocker tag openclaw/openclaw:2026.3.7 192.168.1.100:5000/openclaw/openclaw:2026.3.7docker load 適合鏡像數(shù)量少、節(jié)點數(shù)量也少的場景。比如單機部署或者最多兩三臺機器直接 load 就夠了不需要額外考慮鏡像倉庫的維護問題。3.2 路徑 B私有鏡像倉庫適合規(guī)模化環(huán)境如果內(nèi)網(wǎng)節(jié)點很多一臺一臺 load 顯然不現(xiàn)實。這種場景下我會在隔離環(huán)境里先部署一個私有鏡像倉庫然后把離線包里的鏡像全部 push 進去。最簡單的方式是直接用 registry 容器docker run -d --name registry --restartalways -p 5000:5000 -v /opt/registry:/var/lib/registry registry:2注意registry 這個容器本身的鏡像也需要提前打包進離線包里否則內(nèi)網(wǎng)環(huán)境同樣拉取不到。推送前把鏡像重新打標簽改成內(nèi)網(wǎng)倉庫地址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這里有一個內(nèi)網(wǎng)環(huán)境非常典型的攔截點如果你的私有鏡像倉庫沒有配置 TLS 證書Docker 默認會拒絕通過 HTTP 方式推送。解決辦法是在內(nèi)網(wǎng)每臺節(jié)點的/etc/docker/daemon.json里配置 insecure-registries{ insecure-registries: [192.168.1.100:5000] }修改完 daemon 配置后需要重啟 Dockersystemctl restart docker如果你所在團隊已經(jīng)有現(xiàn)成的鏡像倉庫那就更簡單了直接把離線包推到已有倉庫即可不需要額外部署一個新的。3.3 兩種路徑可以同時保留我最后交付的方案里兩條路徑都保留了。為什么因為不同內(nèi)網(wǎng)環(huán)境的現(xiàn)狀差異很大。有的團隊已經(jīng)維護了自己的鏡像倉庫離線包只需要推到已有倉庫有的環(huán)境則什么組件都不讓裝registry 這種新容器可能還要走額外的審批流程這時直接 load 反而更省事。所以我只是把 01-load-images.sh 和 02-import-registry.sh 兩個腳本都放進交付目錄并寫明各自的適用場景。使用者按自己的內(nèi)網(wǎng)條件選一條不會因為沒有某個組件而被卡死。這里也提醒一句無論走哪條路徑鏡像打好 tag 并推送到倉庫之后原始歸檔文件不要急著刪留到驗證完成后再處理。因為如果倉庫臨時出問題至少還能重新 load。4. compose 啟動之前內(nèi)網(wǎng)特有的配置調(diào)整點鏡像就位只是第一步真正決定部署能否一次成功的是 compose 編排文件里的那些細節(jié)。很多在線環(huán)境里不是問題的配置到了內(nèi)網(wǎng)全部變成必須處理的坑。這一段我按實際使用順序來寫你照著一項項核對基本能避開大多數(shù)坑。4.1 顯式關(guān)閉自動拉取和隱式依賴在線部署時docker compose up -d 會自動去遠程倉庫拉取缺失的鏡像。內(nèi)網(wǎng)環(huán)境沒有這個能力所以在 compose 文件里盡量顯式聲明pull_policy: never強制 Docker 只使用本地已經(jīng)存在的鏡像。否則 compose 仍然會嘗試訪問遠程倉庫連接不通時整段啟動過程可能卡在拉取階段半天不報錯。我這次使用的 compose 文件結(jié)構(gòu)大致如下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提示上面的環(huán)境變量名、健康檢查路徑是我在實際版本里寫出來的典型形態(tài)。不同版本的 Openclaw 命名可能有差異拿到鏡像后先跑一次docker history或者docker inspect確認真正的環(huán)境變量名再套用文件。4.2 健康檢查決定啟動順序不只是好習慣很多人部署時不加 healthcheck因為在線環(huán)境下docker compose 默認的啟動順序基本夠用。但如果數(shù)據(jù)庫或緩存還沒就緒就讓 Openclaw 啟動它會在啟動階段反復重試連接嚴重時會造成初始化失敗。所以我在依賴服務上都加了 healthcheck并在 Openclaw 上用 condition 語法等待它們健康后再啟動。這個寫法的效果是只有當 PostgreSQL 返回pg_isready成功、Redis 返回PONG之后Openclaw 才會被拉起。需要注意的是condition: service_healthy這種寫法需要 Docker Compose v2 支持如果你的內(nèi)網(wǎng)服務器還在用很早期的 docker-compose v1可能需要先升級或者改用一個等待腳本。start_period參數(shù)也別省。Openclaw 這類服務啟動時可能要做配置解析、建表、遷移前幾十秒探活失敗是正常的。沒有 start_period 的話健康檢查會按固定間隔重試一旦超過 retries 次數(shù)就標記為不健康哪怕服務只是啟動慢了一點。4.3 數(shù)據(jù)持久化、日志輪轉(zhuǎn)和 .env 管理離線環(huán)境里沒有云廠商的后置存儲數(shù)據(jù)一旦丟失恢復成本非常高。所以數(shù)據(jù)庫和主服務的數(shù)據(jù)目錄必須用命名卷或綁定掛載落到宿主機。我上面寫的是命名卷方案實際部署時也可以用宿主機路徑/opt/openclaw/pgdata:/var/lib/postgresql/data /opt/openclaw/appdata:/opt/openclaw/data日志也得提前想好。容器默認的 json-file 日志會無限增長內(nèi)網(wǎng)磁盤空間本來就緊張建議顯式配置輪轉(zhuǎn)logging: driver: json-file options: max-size: 20m max-file: 5還有一個容易被忽略的問題密碼和敏感配置不能直接寫死在 compose 文件里。我在交付包里只放.env.example不填真實密碼。部署時復制一份.env填入符合內(nèi)網(wǎng)要求的強密碼。好處是交付包可以反復流轉(zhuǎn)不會帶出敏感憑據(jù)。5. 啟動之后的驗證標準與回滾預案離線部署不是容器起來了就算成功它是一門需要驗收標準的工程。我把部署完成后的驗證項整理成了一張清單每次部署結(jié)束之后照著跑一遍能省掉后面很多折騰。檢查項操作期望結(jié)果容器狀態(tài)docker compose ps所有服務 UpOpenclaw 顯示 healthy健康檢查接口curl -fsS http://127.0.0.1:8080/health返回 HTTP 200主應用日志docker compose logs --tail200 openclaw無連續(xù)的 Error 級別日志數(shù)據(jù)庫連接docker compose exec postgres pg_isready -U openclaw返回 accepting connections數(shù)據(jù)落盤docker volume inspect openclaw_openclaw_dataMountpoint 目錄存在內(nèi)網(wǎng)訪問從內(nèi)網(wǎng)另一臺機器訪問服務地址頁面或接口可以正常打開每一項都有意義而不是走過場。容器狀態(tài)只能證明進程在跑健康檢查接口證明服務真的響應了數(shù)據(jù)庫連接證明主服務和數(shù)據(jù)庫之間的鏈路通了內(nèi)網(wǎng)訪問證明端口映射和網(wǎng)絡(luò)策略都沒問題。5.1 回滾預案數(shù)據(jù)卷不動鏡像換一下一旦部署后出現(xiàn)線上問題回滾的第一原則是數(shù)據(jù)卷不動鏡像換一下。因為 Openclaw 的數(shù)據(jù)基本都存在命名卷里回滾只是把 compose 文件里的 image 標簽切回舊版本再 up 一次。前提是舊版本鏡像在內(nèi)網(wǎng)里還有保留。我建議打包時把舊版本鏡像也一并導入原因就在這。有一個很關(guān)鍵的坑千萬別順手執(zhí)行docker compose down -v。-v參數(shù)會把命名卷一并刪掉數(shù)據(jù)一旦刪除回滾就無從談起。日常維護只需要docker compose down不帶任何刪除數(shù)據(jù)參數(shù)。5.2 平滑升級的固定步驟如果要升級到下一個版本我的操作順序是固定的備份數(shù)據(jù)卷或者至少把數(shù)據(jù)目錄完整拷貝一份在聯(lián)網(wǎng)機器上拉取新版本鏡像導出歸檔傳輸?shù)絻?nèi)網(wǎng)load 并 push 進鏡像倉庫修改 compose 文件里的 image 標簽重新 up跑一遍驗證清單。這六步里最容易忽略的是第一步。備份動作一定要獨立寫一份命令文檔跟著執(zhí)行不要靠記憶。很多線上事故都是升級前沒做備份結(jié)果配置遷移失敗后進退兩難。6. 幾個差點讓我翻車的細節(jié)問題前面梳理的都是主線流程最后聊幾個實際操作中真真切切踩過的坑。每一個都耽誤過不少時間整理出來給后來人提個醒。6.1 架構(gòu)不匹配報錯和原因?qū)Σ簧线@是離線部署里最隱蔽的問題之一。在 x86 機器上打包內(nèi)網(wǎng)服務器卻可能是 ARM 架構(gòu)。如果一開始不知道這個情況啟動后的常見現(xiàn)象是容器反復重啟日志里只有一行exec format error。這個報錯和鏡像損壞、配置錯誤的表面現(xiàn)象完全不同很容易讓人往配置文件方向排查實際上原因只是架構(gòu)不一致。排查命令很簡單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 容器時間不同步引發(fā)的詭異問題這是一個藏在鏡像里的坑。容器繼承的是宿主機內(nèi)核時間如果宿主機時間不對容器內(nèi)的服務可能不會立刻報錯但在日志時間戳、緩存過期、賬號有效期這些場景里會表現(xiàn)出間歇性的異常。內(nèi)網(wǎng)服務器如果長期沒有時間同步策略時間偏差可能達到幾分鐘甚至更長。部署前先把宿主機的時鐘校準一遍至少要在部署文檔里加一條檢查命令date timedatectl status如果內(nèi)網(wǎng)沒有可用的時間服務器也要盡量人工校準到接近真實時間否則后續(xù)排查問題的成本會很高。6.4 大文件傳輸后一定要核對完整性鏡像歸檔文件動輒好幾個 G傳輸過程出問題并不是小概率事件。我遇到過一種情況歸檔文件大小看起來沒少但加載時 Docker 提示某個 layer 不存在后來才發(fā)現(xiàn)是傳輸過程中文件被截斷了。從那以后所有歸檔文件都走 sha256 校驗流程。生成校驗清單在工作目錄里執(zhí)行傳輸?shù)絻?nèi)網(wǎng)后執(zhí)行一次校驗確認兩邊完全一致后再進入 load 或 push 階段。這幾次部署之后我的習慣是只要執(zhí)行完驗證清單就把整個交付目錄重新歸檔一次命名加上日期和鏡像版本。這樣做的好處是下次任何一個同事接手都只需要照著同一個目錄結(jié)構(gòu)操作不需要再來問我當時的命令是什么。離線部署這件事本身不難難的是把每一個步驟固定成可復現(xiàn)的流程。希望這份 Openclaw 2026.3.7 Docker 離線部署方案能幫你少走幾步彎路。