关闭 Bonjour 后 CPU 下降，能不能直接认定根因已经确认？

这已经是很强的边界证据，但还不是对具体代码行的最终定性。它至少说明最值得优先隔离的是服务广播 sidecar，而不是先去做泛化的宿主机调优或无关的文档处理排查。

怎么快速区分这是 sidecar 空转，还是正常文档负载过高？

看时间关系和吞吐关系。如果 CPU 峰值从广播初始化开始就持续存在，但看不到成比例的文档任务量、队列增长或实际处理量，那更像是 sidecar 失控，而不是正常业务负载。

等待上游修复期间，最安全的临时止血方案是什么？

先缩小爆炸半径。优先关闭广播路径、只重启受影响组件，并验证真实文档任务是否恢复，而不是一上来就改一整套无关参数。先止住资源空烧，再保留足够证据做后续复盘。

什么情况下不该立刻全局关闭 Bonjour？

只有当你的部署真的依赖局域网发现，比如局域网内设备要自动发现服务时，才应该先在预发环境隔离验证。对 VPS、CI、反向代理后面的无头部署来说，Bonjour 往往不是核心入口，优先保稳定更划算。

设置 OPENCLAW_DISABLE_BONJOUR=1 之后，还要补验什么？

不要只看 CPU 是否下降。至少补验一条真实文档任务、一轮代表性 agent 流程，以及此前出问题时间窗口内的容器存活情况，确认你修掉的是高成本故障模式，而不是只是把表面症状压下去。

OpenClaw v2026.4.8 在无头 Docker 中可能打满单核 CPU，Bonjour Sidecar 故障该怎么判断和绕开

一则新开启的 Bug 报告指出，OpenClaw v2026.4.8 在普通 Docker bridge 网络中运行时，bonjour/mDNS 广播逻辑可能进入失控重试循环，把一个子 openclaw 进程推到 99% CPU，并在数分钟后诱发容器退出。

来源 issue：openclaw/openclaw#63248

对跑在 VPS、CI 环境、临时测试容器里的运维者来说，这条线索值得优先检查。因为它不是泛泛的“Docker 不稳定”，而是一个很具体的故障模式：

OpenClaw 能正常启动
gateway 初期可用
一个子 openclaw 进程持续打满单核
日志反复出现 bonjour watchdog 重新广播
容器随后可能无明显解释地退出

可能发生了什么

根据 issue 描述，问题主要出现在无头容器且未使用 --network=host 的场景。

这点很关键。bonjour/mDNS 本来是为局域网服务发现设计的。在标准 Docker bridge 网络里，这类广播行为对容器来说往往并不可靠，甚至根本没有实际意义。该报告怀疑 OpenClaw 在广播始终失败时，没有优雅退避，而是不断重试重播。

issue 中提到的日志特征大致如下：

[bonjour] watchdog detected non-announced service; attempting re-advertise
[bonjour] restarting advertiser (service stuck in announcing ...)

如果这个循环始终无法收敛，问题就不只是日志难看，而是会实打实吞掉宿主机的计算资源。

为什么这对生产环境麻烦很大

1）它先吃掉的是小 VPS 最缺的 CPU 预算

很多 OpenClaw 部署本来就在轻量主机上运行。单核被广播重试循环长期占满，剩余资源就会明显不足，影响：

agent 执行
CLI 命令
browser 或其他工具调用
后台任务稳定性

2）它会制造很误导的症状链

你最先看到的，未必是“bonjour 出问题了”，而更可能是：

容器在 9 到 18 分钟后退出
docker exec 进去跑命令像卡死
一些辅助 CLI 命令没有返回
gateway 看起来先正常，随后逐步失稳

这很容易被误判为通用的 Docker、资源或网络问题。

3）它对 CI 和测试容器尤其不友好

很多临时环境默认就是 bridge 网络。如果这个报告具有普遍性，那么越是干净、标准、自动化的 Docker 测试环境，越容易先踩到这个坑。

已报告的连带影响：CLI 也可能被拖垮

同一 issue 里还提到，当 bonjour 循环已经把 CPU 打满后，下面这些命令可能也会进入 busy-wait，迟迟不返回：

openclaw cron list
openclaw message --help
openclaw channels list

这部分后续也许会被拆成独立问题，但对运维者来说，核心结论不变：一旦运行时被无效重试拖住，排障本身都会变得更困难。

运维者的快速决策树

如果你需要一个更快的 go / no-go 判断，可以先这样分流：

CPU 峰值紧跟在广播启动后出现，日志持续刷 bonjour watchdog
- 先把 Bonjour 当成首要故障边界，优先测试 OPENCLAW_DISABLE_BONJOUR=1。
CPU 高，但文档吞吐也确实同步很高
- 先别急着认定是 sidecar，先核对队列深度、任务量和 worker 活跃度。
你的部署依赖局域网自动发现
- 先在预发环境验证，再决定是否全局关闭 Bonjour，避免把确实需要的能力一起关掉。
你跑的是 VPS、CI 或反向代理后的无头容器
- 优先保稳定，把关闭 Bonjour 视为最快的低风险止血动作。

现在可以怎么做

issue 中给出的当前绕过方案，是在容器里关闭 bonjour：

docker run -d \
  -e OPENCLAW_DISABLE_BONJOUR=1 \
  -p 28789:18789 \
  -v <state>:/home/node/.openclaw \
  ghcr.io/openclaw/openclaw:2026.4.8

报告者称，设置后 99% CPU 的失控进程会消失，bonjour 相关日志刷屏也会停止。

如果你在无头 Docker 中运行 OpenClaw，一个务实的短清单是：

先看 docker top，确认是否存在异常的子 openclaw 进程长期接近 99% CPU。
再看 docker logs，确认是否持续出现 bonjour watchdog 或 re-advertise 日志。
如果你并不依赖局域网服务发现，直接测试 OPENCLAW_DISABLE_BONJOUR=1。
用同一套容器负载复测，对比 CPU 占用和容器存活时间。

关闭 bonjour 前，先留 5 个取证点

这类问题很容易被一句“CPU 99%”带偏。为了让后续修复、回滚或上游 issue 更快收敛，先保存 5 个证据：

容器环境：是否是 Docker、headless、VPS、CI runner，是否本来就不需要 LAN discovery。
CPU 时间线：记录启动后多久开始飙高，是立即飙高，还是运行一段时间后进入 announce/retry 循环。
bonjour 日志片段：保留重复 advertise、mDNS、socket、network interface 相关日志，不只截 top 输出。
禁用前后对照：同一镜像、同一入口命令下，分别记录设置和不设置 OPENCLAW_DISABLE_BONJOUR=1 的 CPU 与 CLI 响应差异。
业务影响范围：确认 agent run、helper command、gateway health 哪些被拖慢，哪些仍正常。

这样处理能把“主机很卡”转成可复现的 headless discovery 故障，而不是让读者盲目升级、重装或扩大回滚范围。

在宣布事故结束前，要补验什么

当 CPU 峰值消失后，真正要补验的是用户侧可靠性有没有回来：

至少一条真实文档或无头任务能正常完成。
一轮代表性 agent 流程不会再把辅助命令拖挂。
容器存活时间已经跨过此前常见崩溃窗口。
日志里不再持续出现 bonjour re-advertise 重试。

原因很简单，CPU 降下去不等于事故结束。真正的完成条件，是高意图工作负载重新稳定。

如果你是从安全/成本、版本评估或 CLI 卡顿入口来的

这篇 Bonjour CPU 问题页不应该只服务已经看到 bonjour watchdog 日志的人。GA4 里 /zh/safety-and-cost、/zh/news/openclaw-2026-3-13 和 CLI 回归页都在同一天出现访问，说明读者很可能是在判断“这是成本失控、版本风险，还是命令路径真的变慢”。

可以按这个顺序分流：

先看安全/成本页：如果你的首要问题是 API 账单、8080 暴露、凭据轮换或预算护栏，先回到安全与成本控制，不要把所有资源异常都归因于 Bonjour。
再看 2026.3.13 发布说明：如果你正在评估团队是否能把 OpenClaw 作为稳定基线，回到 2026.3.13 发布说明，把 Bonjour 视为后续版本/部署形态里的专项风险。
最后看 CLI 回归页：如果命令是在 hook loading 后稳定卡 20-40 秒，而不是容器启动后单核被 mDNS 广播打满，去看 CLI 性能回归排查。

这样能减少无头 Docker 运维读者的误判：CPU 空烧、成本止血、版本准入和命令卡顿是四条不同路径，只有日志与时间线命中 Bonjour 重播时，才把 OPENCLAW_DISABLE_BONJOUR=1 放到第一优先级。

从 mDNS CPU 流量转成无头部署防护清单

如果你是因为 Bonjour/mDNS sidecar 在 headless 环境里把 CPU 打到 99% 搜到这里，先不要只重启进程。要把问题拆成三类证据：服务发现是否在无网络接口上空转、advertise sidecar 是否重复注册同一服务、以及健康检查是否把高 CPU 误判成可恢复状态。

最小防护清单包括：记录 headless 主机的网络接口、mDNS advertise 开关状态、进程级 CPU 曲线、以及禁用 sidecar 后的对照负载。这样 mDNS 故障流量会被引导到“无头部署、资源保护、自动降级”三类高意图入口，而不是停在单次 CPU 截图。

FAQ：无头 OpenClaw 部署里的 Bonjour / mDNS CPU 异常

所有 VPS 部署都应该立刻关闭 Bonjour 吗？

不需要一刀切。优先在无头主机、用户路径不依赖局域网发现，并且 CPU 曲线或日志已经指向 mDNS advertise 重播时关闭。如果本地设备发现仍是关键能力，先保留证据，再做小范围 canary。

怎么证明这不是模型慢或 CLI 回归？

看时间线。Bonjour 事故通常围绕服务广播或容器启动出现，并伴随进程级 CPU 空烧；模型或 CLI 回归更常和 provider 调用、hook loading、命令执行阶段相关。先把这些时间线拆开，再决定是否套用关闭 Bonjour 的 workaround。

最安全的临时止血方式是什么？

只在受影响的无头部署上设置 Bonjour 禁用开关，在可控窗口重启，并对比前后的 CPU 负载与命令延迟。同时保留原始日志，避免 workaround 抹掉上游修复所需的证据。

什么情况下关闭 bonjour 是合理取舍

对于很多服务端部署来说，bonjour 不是刚需。

如果你的 OpenClaw：

跑在远程 VPS 上
通过域名、反向代理、隧道或固定端口访问
核心用途是自动化，而不是局域网发现

那么在当前阶段关闭 bonjour，通常是很合理的短期止血手段。

换句话说，这很像一个典型的“桌面友好默认值”，放到“无头基础设施环境”里反而变成了负担。

上游更值得补的地方

issue 里提出的修复方向基本都靠谱：

正式文档化 OPENCLAW_DISABLE_BONJOUR=1
在容器或无头环境里自动关闭 bonjour
给广播失败重试加指数退避
不要让失败重播无限制地满速运行

其中最关键的是最后一点。哪怕广播失败了，失败模式也应该是可控的，而不是把整个运行时拖进高 CPU 空转。

结论

如果你的 OpenClaw v2026.4.8 容器启动后表面正常，但随后出现 CPU 异常、辅助命令卡住，或者容器无故退出，bonjour 重播循环现在已经是一个值得优先排查的高可信根因。

对运维者来说，当前最现实的动作就是：

先核对日志特征是否命中
尽快测试 OPENCLAW_DISABLE_BONJOUR=1
不要把问题笼统归咎于 Docker，本质可能是容器里的服务广播逻辑没有正确收敛

来源

Issue：openclaw/openclaw#63248