OpenClaw Gateway 装完只是起点；生产里真正消耗值班时间的是健康检查失真、日志找不到、升级后配置漂移。本文写给已跟完 Linux systemd + Tunnel、Docker Compose 或 三端安装 的团队，补齐最小观测面、日志分流、升级回滚与症状对照表；需要路由策略时再接 modelRouting 篇。
安装教程验证的是 happy path；生产环境要面对的是进程假活、端口撞车、权限变更、下游模型超时等长尾问题。下面六条是把 on-call 从「猜」变成「查」的入口清单。
健康检查过宽：只判断进程存在，不验证 Gateway 真在处理路由，导致流量切入后才发现半残。
日志分散：systemd、容器、应用 stdout 与反向代理各写一处，排障时拼不出时间线。
升级无基线：不记得上一版镜像 digest 或 npm 全局版本，回滚只能「重装试试」。
配置与密钥混放：openclaw.json 与 env 注入不同步，表现为间歇性 401 或路由静默失败。
观测与变更不同步：改了监听地址或 Tunnel 目标，却未更新监控探测路径。
把 Gateway 当万能执行器：把重负载 Xcode 任务硬塞在同一台小 VPS，CPU 打满后误判为「模型慢」。
若你命中两条以上，先把最小观测面补齐，再谈功能迭代；否则每次发布都会在同一类故障上重复交学费。
用一张表把职责切开，避免「装得上」和「稳得住」混在同一轮评审里。
| 主题 | 安装 / 常驻篇（systemd · Docker · 三端） | 本文（生产观测与变更） |
|---|---|---|
| 进程与暴露面 | unit/Compose、回环监听、Tunnel 或防火墙策略 | 存活探针、端口冲突巡检、变更后探测路径回归 |
| 配置模型 | 首次写入 openclaw.json、目录权限 | diff 评审、备份、灰度与回滚顺序 |
| 日志 | 先能落盘或被 journal/docker 收集 | 字段含义、关联 ID、常见错误模式归档 |
| 升级 | 提供一条可复制的升级命令或镜像拉取路径 | 记录 digest/版本号、备份点、回滚验证清单 |
| 模型路由 | 可选提及 | 深度策略见 modelRouting 专文 |
运维的可复制性来自「同一套检查命令 + 同一套回滚顺序」，而不是负责人的记忆力。
下列顺序兼容 systemd 与 Docker：先确认事实层（进程/端口/健康端点），再进入解释层（日志与下游）。具体命令随发行版略有差异，但检查点应保持一致。
确认主进程：systemd 用 systemctl status；Docker 用 docker compose ps，关注重启计数与退出码。
核对监听：ss -lntp 或容器端口映射，确保与 Tunnel/反代目标一致。
健康检查：对文档或自建探针路径做 HTTP 探测，并区分「进程起」与「路由可用」。
拉取最近日志：journalctl -u 或 docker compose logs --tail=200，先锁定时间窗再全文搜索。
验证下游模型：用最小请求夹具排除「Gateway 正常但上游 API 异常」。
输出变更记录：每次发布写清版本号/digest、配置 diff、探测截图，方便下一轮 on-call。
# 示例：快速巡检（按你的 unit / 容器名替换） systemctl status openclaw-gateway.service --no-pager || true ss -lntp | grep -E '18789|LISTEN' || true # Docker 路径（示例） # docker compose -f /opt/openclaw/docker-compose.yml ps # docker compose -f /opt/openclaw/docker-compose.yml logs --tail=200 gateway
提示：若使用 Cloudflare Tunnel，请在变更后同时验证公网探测与本机回环探测，避免「内网通、边缘缓存旧路由」的误判。
可回滚的升级需要三件事：发布前快照、发布中只动一条变更向量、发布后按同一探针集合验收。Docker 路径优先用固定 digest 或私有镜像仓标签策略；裸机/npm 路径锁定全局包版本号与 lockfile（若适用）。
灰度思路：先在单台预发或低流量副本验证，再滚动到生产；若 Gateway 后挂远程执行节点，记得分层发布——先确认控制面，再扩容执行面。
注意：不要在未备份 openclaw.json 与环境注入的情况下并行尝试「顺手改路由」；生产里最常见的不可用来自配置半提交状态。
下列数字为工程经验量级，用于评审对齐；实际超时与配额以供应商与合同为准。
| 症状 | 优先怀疑 | 处理方向 |
|---|---|---|
| 启动即退出 | 配置 JSON 语法、环境变量缺失、端口占用 | 用前台模式复现一次，对照安装篇检查点 |
| 间歇 401 | 密钥轮换不同步、多个配置文件路径 | 统一注入源，清理历史 shell profile 污染 |
| CPU 长期打满 | 执行负载堆在 Gateway 同机 | 把重任务迁到专用执行节点或远程 Mac |
| 延迟飙升 | 下游模型限速、DNS、TLS 握手 | 分层抓包/日志，先隔离网络再调模型 |
把重 macOS 构建、签名与 GUI 依赖任务硬塞在与 Gateway 同一台小型 Linux VPS 上，短期省事，但会同时拖垮控制面稳定性与排障信噪比；纯本地笔记本又难做到 7×24 与可审计隔离。对需要稳定 iOS CI、自动化 Agent 与可合同化算力的团队，更稳妥的路径是：Gateway 留在通用 VPS，把 macOS 执行层放到独占远程 Mac 节点。综合运维边界与扩展弹性，NodeMini 的 Mac Mini 云端租赁适合承接这类执行层：按地区与磁盘选节点，与 OpenClaw 控制面分层部署，值班只盯清晰的观测面。
可在博客列表使用 OpenClaw 分类筛选，并按 systemd → Docker → 观测 → modelRouting 的顺序阅读。
请查阅 帮助中心，再回到本文健康检查与日志章节做交叉验证。