你已經能跑通 onboard，但 CLI 或面板長時間停在 Gateway 無法就緒 / not ready：這往往發生在進程真正監聽之前，與站內 gateway closed(1000) 排錯篇（偏會話、scope、Token）不同層。本文給平臺工程一條最短路徑：先用七條清單排除端口、內存、超時、鏡像與卷權限，再用一張裸機 systemd vs Docker 對照表選對日誌入口，最後執行六步 Runbook（含 openclaw doctor / 日誌命令示意），並與 安裝總覽、Docker 生產、觀測篇 分工閱讀。
not ready 通常表示控制面還沒等到監聽成功、依賴進程就緒或健康探針通過；它不等於 WebSocket 已建立後被策略踢下線——後者請優先讀 closed(1000) 篇。下面七條用於安裝後首周的平臺自檢。
端口被舊進程或別的服務佔用：升級或反覆 docker compose up 後，宿主機仍殘留舊 Gateway 綁定同一端口，新進程半啟動，CLI 只顯示 not ready。
內存與 swap 不足觸發 OOM：小內存 VPS 上同時拉模型與 Gateway，Node 進程在就緒前被內核殺掉，日誌裡常見 exit code 137 或無聲消失。
啟動超時過短：冷啟動拉鏡像或編譯原生依賴耗時超出默認 startupTimeout，健康檢查提前失敗，表現為「永遠 not ready」。
看錯日誌文件：在 systemd 與 Docker 混用調試時，盯著容器日誌卻忘了宿主 unit 仍在拉起舊二進制，或反之。
命名卷權限與 UID 映射：容器內用戶無法寫狀態目錄，Gateway 反覆崩潰重啟，外部只看到 not ready。
鏡像 digest 與配置版本漂移：compose 指向 :latest 但本地緩存層與新 openclaw.json 字段不兼容，啟動腳本提前退出。
把網絡問題誤判為啟動失敗：拉模型或插件倉庫超時，進程卡在初始化；需要先區分 DNS/出口與 Gateway 自身。
這些項的共同點是：進程還沒進入可服務狀態，因此 status/RPC 往往也「半綠不綠」。把它們寫進工單模板後，再用下表選對日誌入口，避免在 journal 與 docker logs 之間來回橫跳。
與 跨平臺安裝篇 對齊：安裝腳本負責「能裝上」，本文負責「裝完起不來」；與 觀測篇 對齊：觀測篇講長期指標與升級回滾，本文講第一次就緒之前的硬故障。
若你把 Gateway 跑在獨佔遠程 Mac或小型 Linux VPS 上，建議把最小內存與磁盤水位寫進變更評審，而不是隻盯版本號；否則 not ready 會在業務演示前集中爆發。下面用一張表把「該看哪份日誌」收斂成決策。
最後提醒：不要在未確認監聽面的情況下把 Gateway 臨時暴露到公網試連通；排錯順序應遵循 安全加固篇 的最小暴露原則。
排錯 not ready 時，第一決策是入口形態：進程由 systemd 拉起，還是由 compose 起容器。混查會浪費大量時間。
| 維度 | Linux / macOS 裸機 + systemd（或 launchd） | Docker / Compose |
|---|---|---|
| 第一屏日誌 | journalctl -u <unit> -n 200 --no-pager 或平臺等價命令 | docker compose logs --tail=200 <service>，對齊重啟時間戳 |
| 端口衝突排查 | 宿主機 lsof -nP -iTCP:<port> -sTCP:LISTEN（示意） | 同時檢查宿主機與容器內監聽；publish 端口是否與宿主已有服務撞車 |
| 權限/卷問題 | 狀態目錄屬主與運行用戶是否一致 | 命名卷 UID、只讀根與可寫掛載是否分離；參見 Docker 生產篇 |
| 超時與重試 | unit 中 TimeoutStartSec、Restart= 策略 | healthcheck start_period、retries 與鏡像冷啟動時間 |
| 升級回滾抓手 | 包版本 + 上次已知良好配置備份路徑 | 鏡像 digest 固定 + compose 文件版本化；與觀測篇回滾段落一致 |
「先確認監聽，再談會話」：not ready 階段最值得投資的是端口 + 資源 + 正確日誌窗口，而不是先改 Token。
若你按 Ubuntu 24.04 + systemd + Tunnel 部署，還要核對 Tunnel 上游是否仍指向舊端口；這類錯位會讓外部永遠 not ready，而本地 curl 127.0.0.1 卻看似正常。
Docker 場景下，常見誤判是「容器已 Exited 但 compose 仍顯示 creating」：用 docker compose ps -a 看退出碼，再回到卷權限與入口腳本。
一旦確認進程已監聽且健康探針通過，若客戶端仍異常，再切換到 closed(1000) 的會話排查路徑。
下列順序刻意把低成本檢查放在前：先確認資源與端口，再動配置與鏡像。具體子命令以你安裝的 OpenClaw 版本為準。
凍結併發重試：暫停其他同事的自動重連腳本，避免你排查時被連接風暴淹沒。
採集版本與資源快照：openclaw --version、uname -a、內存與磁盤可用率寫入工單。
驗證端口與舊進程：對配置端口執行監聽檢查；若發現舊 PID，按 systemd/Docker 文檔有序停止再拉起。
跑 doctor / validate：openclaw doctor 或等價命令，修復明顯缺失項後再嘗試啟動。
拉長啟動觀察窗：如支持，臨時提高 gateway.startupTimeout 或 compose healthcheck start_period，區分「慢」與「死」。
最小驗收：本地 curl 健康檢查或官方 status 子命令返回就緒後，再恢復他人使用；仍失敗則帶著第四節日誌樣本升級工單。
openclaw --version openclaw doctor # systemd 示例： # journalctl -u openclaw-gateway -n 120 --no-pager # Docker 示例： # docker compose logs --tail=120 gateway # 然後按發行版文檔重啟 unit / compose 服務
提示：CLI 日誌若提示模型或插件下載超時，先區分網絡出口與 Gateway 自身；必要時在維護窗臨時放寬 egress 白名單，再收緊，參見 安全加固篇。
與 安裝總覽 對齊：若你剛切換 Anthropic 計費或 API Key 形態，確保環境變量與配置文件同源，否則進程可能在解析密鑰階段阻塞，看起來像 not ready。
若在 獨佔遠程 Mac 上長期跑 Gateway，建議把 launchd/unit 的自動重啟策略與磁盤清理寫進同一 Runbook，避免日誌佔滿磁盤後進入「反覆 not ready」。
把下面這張「口頭描述 → 動作」貼在 on-call 頻道置頂，能顯著減少無效 @。若症狀已涉及 WebSocket 關閉碼，請轉 closed(1000) 篇。
端口已被佔用：先停舊進程再啟新進程；不要在未釋放端口時反覆 scale。內存不足：先降併發或加 swap/升配，再談調參。鏡像拉取失敗：先 docker pull 或檢查 registry 憑據，再回到 Gateway 配置。
注意：不要在生產環境無記錄地執行 docker system prune 類命令清理「試試看」；可能刪掉仍在用的命名卷備份。清理路徑應寫進變更單。
與 觀測篇 聯動：not ready 解決後，把本次根因標籤寫進監控看板（端口/內存/鏡像/卷），避免下週同類問題重複打開。
若 Gateway 與 MCP 子進程 同機部署，啟動階段還要關注子進程可執行路徑與沙箱掛載是否在容器內可見；否則主進程阻塞在工具發現階段。
下列字段用於跨團隊對齊；外發前請脫敏。
僅把 Gateway 跑在個人筆記本上，易受睡眠與系統更新打斷；純小內存 VPS 又常在冷啟動階段 OOM。若你需要長期在線、可合同化的 macOS 執行層來承載 OpenClaw 與周邊工具鏈，獨佔遠程 Mac通常比反覆借用本機更穩。相較自建零散機器，NodeMini 的 Mac Mini 雲端租賃提供固定 SSH 與清晰磁盤檔位，更易把「Gateway + 工具鏈」做成可交接節點；規格與價格見 租賃價格說明，接入問題見 幫助中心，OpenClaw 系列文章可從 部落格分類 進入。
進程未監聽、端口/內存/超時問題先看本文；WebSocket 已建立後被策略或會話關閉再看 closed(1000) 篇。需要算力與接入規劃可打開 算力訂購 與 幫助中心。
docker compose logs --tail=120 gateway 與宿主機同一時段的 dmesg/資源快照；若懷疑卷權限，再附 docker compose ps -a 退出碼。
從 部落格 OpenClaw 分類進入安裝、Docker、systemd、安全、觀測與 MCP 篇；本文適合卡在「起不來」階段時閱讀。