你已经能跑通 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 篇；本文适合卡在「起不来」阶段时阅读。