向导打印了带 token 的 URL 但浏览器打不开，是 Gateway 坏了吗？

常见情况是容器仍在拉起或向导在等待 Gateway 完全就绪；应先确认 Docker Desktop 与 WSL2 后端正常，再用 compose 或官方推荐命令单独拉起 Gateway 服务并查看日志。若官方安装流程调整，以 OpenClaw 当前文档为准。

Windows 笔记本 Docker 里跑不稳定，生产 OpenClaw 应该放哪？

交互与开发可留在本机 Docker；7×24 或团队共享的 Gateway 更适合落在网络策略简单、磁盘与进程可预测的独占远程 Mac 上，并与 SSH 转发或 Tailscale 等文并联设计。

2026 OpenClaw Windows Docker 安装与 Gateway 故障：向导卡住、compose 与 doctor 分症状复现清单

Windows Docker 路径上最常见的六类「假死」与误判

把 Docker Desktop 未就绪当成 OpenClaw 安装失败：引擎还在 starting 时跑向导，日志里只有超时，没有明确报错栈。
WSL2 集成漂移：更新 Windows 或 Docker 后 distro 版本与集成开关变化，volume 路径或 DNS 解析与昨天不一致。
向导与 compose 双轨并行：一边跑官方脚本、一边手工 docker compose up，造成双 Gateway或端口争用（常见回环端口如文档所述的网关端口，请以你本机 openclaw gateway status 为准）。
版本真源不唯一：宿主机 openclaw --version 与容器内 CLI 不一致，doctor 报「配置与运行时不匹配」类信息时被误读为模型问题。
企业代理与 MITM：HTTPS 拦截导致镜像拉取或注册表握手偶发失败，症状像「Gateway 随机挂」。
把交互问题强行塞进 CI 同一镜像：缺图形会话或凭据助手时重复踩坑；应与安装总览中的平台注意点并列维护。

本篇不写「从零概念介绍 OpenClaw」，只收 Windows + Docker 的可操作分诊；与 macOS 原生、Linux systemd、Tailscale 尾网等文的关系是：同一套验证命令，不同的宿主责任面。

若你已经在看doctor 无回复与模型错误，请把本文当作前置条件检查：先确认引擎与端口，再进入模型与通道层。

症状簇	首发检查（5 分钟内）	建议下一步
向导停在某一步 / URL 不弹出	Docker Desktop 是否 Running；WSL2 是否启用；磁盘剩余是否 >20GB（经验阈值，请按团队基线调整）	按官方文档用 compose 单独拉起 Gateway 容器并 `docker logs`；避免脚本与手工双启
容器 running 但本机 CLI 不通	端口是否被其它进程占用；是否误把 Gateway bind 到仅容器内可见地址	跑 `openclaw gateway status` / `openclaw status`；对照 Compose 配对文的 TOKEN 与网络命名空间表
升级后立刻异常	宿主机 CLI 与镜像 tag 是否同一发布线；旧 volume 是否残留冲突配置	对齐版本后 `openclaw doctor`；必要时按文档执行强制重装 Gateway 服务（保留备份目录）

warning

社区经验（非官方承诺）：部分用户在向导「假死」时会中断后改用 docker compose up -d 拉起服务；若你曾修改过本机 pending/向导相关 JSON，请以官方最新文档为准回滚，不要长期依赖未文档化的静默开关。生产变更仍应走变更单。

六步 Windows Docker Runbook：从「能复现」到「能交接」

冻结环境切片：记录 Windows 版本、Docker Desktop 版本、WSL wsl --version、OpenClaw CLI --version 与镜像 digest；贴进工单。
确认 Docker 数据面：镜像拉取是否走公司代理；必要时为 *.docker.io / GHCR 配置显式代理或离线镜像同步（与GHCR Runbook对齐）。
单轨启动 Gateway：选择「向导」或「compose 常驻」之一作为真相源；另一路径只用于排障临时会话，结束后回收容器。
跑验证阶梯：openclaw status → openclaw gateway status → openclaw doctor → openclaw channels status --probe（命令以你安装渠道文档为准）。
版本对齐：若 doctor 提示二进制与运行时不一致，按官方顺序执行 gateway 重装或镜像 pin，并记录回滚点。
写回 RUNBOOK.md：把「本司 Windows 镜像 tag」「代理例外」「禁止双启」写成三条红线，避免下一位同事从搜索引擎随机拼命令。

第 3 步与第 4 步之间若仍卡住，优先打印容器环境变量子集（脱敏后）与 docker port 映射，而不是先调模型温度；多数「无回复」是传输层未就绪而非 prompt。

与SSH 转发远端 Gateway组合时：笔记本只做客户端，Gateway 在远程独占机；Windows Docker 侧只需保证到转发端口的 TCP 连通与 TOKEN 真源一致，不要把 18789 类端口无鉴权暴露到公网。

powershell

# 示例：确认 WSL 与 Docker（输出随环境变化）
wsl --status
docker version

# 示例：验证 OpenClaw CLI 是否可用（需已按文档安装）
openclaw --version
openclaw gateway status
openclaw doctor

三条应写进值班手册的「硬信息」（数值请替换为你们基线）

Docker Desktop 未显示 Running 之前禁止执行向导第二步：把这一条写成自动化前置检查，而不是口头约定。
磁盘水位：在 256GB 系统盘上，若 Docker 数据根分区长期低于约 12GB 空闲（示例阈值），应先清理悬空镜像与 build cache，再诊断 OpenClaw。
版本对齐 SLA：升级后 30 分钟内必须完成 doctor 清零或已登记豁免项，否则禁止合并「依赖 Gateway 的流水线」变更。

为什么「长期靠个人笔记本 Docker 扛生产 Gateway」往往不如独占远程 Mac

笔记本睡眠、域策略、补丁星期二与 Docker Desktop 升级窗口会把可用性切成不可预测片段；团队共享时更难做同构镜像 + 固定监听 + 审计日志。把 7×24 或多通道并发绑在个人机上，短期省钱，长期把 on-call 绑在单人习惯配置上。

相对这种路径，当你需要可预测的 Apple Silicon 宿主、固定大区出口、与 SSH 转发 / Tailscale 文档化拓扑来承载 Gateway，而把 Windows Docker 留在开发沙箱时，MACCOME 的 Mac 云主机通常是更稳的生产承载面：六国节点、弹性租期、独占磁盘与进程空间，先把 Gateway 变成「基础设施」，再让笔记本回到「客户端」——这与本站多篇 OpenClaw 与远程 Mac Runbook 的结论一致，而不是重复销售话术。

收束：把 Windows 特例写进 ONCALL.md，而不是散落在微信群

交接物应包含：镜像 tag、compose 片段版本、代理策略、验证命令输出样例。任何无法被同事在另一台 Windows 上复现的步骤，都应视为未完成。

与macOS 原生 Runbook对照时，记住：验证阶梯一致，宿主责任不同；不要混用两套 launch 逻辑。

最后五分钟核对：Docker 是否单真源就绪、Gateway 是否单轨启动、doctor 是否清零；再打开模型与通道排障文档。