04-运维 · 05 支持包与脱敏排障

预计阅读：9 分钟适用版本：公开稳定包 OpenClaw 2026.5.2；作者端已验证 2026.5.7 · 最后审核：2026-05-09 前置：04-结构化状态与 State Doctor 目标：知道什么时候该打支持包、包里到底会带什么、哪些敏感信息会被脱敏、发出去前要自查什么

为什么支持包值得单独讲

很多 OpenClaw 故障不是一句“报错了”能定位的。

作者真正需要的是：

你的 openclaw 版本
doctor 和 gateway status 的真实输出
脱敏后的配置
最近状态文件
对应时间段的日志 tail

这也是为什么现在更推荐：

bash ~/.openclaw/scripts/collect-support-bundle.sh

而不是手工截十几张图。

什么时候该打支持包

下面这些场景都值得直接打：

install.sh 或 update.sh 最终失败
runtime-self-heal.sh 跑完仍有 warn 或 failed
maintenance-queue-status 里长期有 failed
state-doctor 出现 FAIL
你已经定位不清，准备把问题交给作者看

反过来说，如果只是想确认 gateway 还活着，先看 runtime-status 就够，不要一上来就打包。

一条标准命令

# 默认输出到当前用户 HOME 目录
bash ~/.openclaw/scripts/collect-support-bundle.sh

# 自定义输出路径
bash ~/.openclaw/scripts/collect-support-bundle.sh --output /tmp/openclaw-support.tgz

脚本跑完后，通常还会同步写入：

~/.openclaw/state/support-bundle-result.json
~/.openclaw/state/events.jsonl

也就是说，这次“你打过支持包”本身也会进入状态时间线。

支持包里通常会带什么

当前买家侧支持包重点收这几类内容：

类别	典型内容	为什么要带
环境快照	`node / npm / python3 / openclaw` 版本	判断是不是版本偏移
OpenClaw 自检	`openclaw doctor`、`openclaw gateway status`	先让机器自己说话
配置快照	脱敏后的 `openclaw.json`、`USER.md`	看结构和字段，不看密钥原文
状态文件	`runtime-status / next-steps / queue-status / index / state-doctor / state-migrate`	直接还原当前系统状态
日志 tail	`gateway.log`、`gateway.err.log` 等最近 200 行	定位错误发生在哪段
插件版本	`extensions.json`	看插件是不是对齐

这套内容的目的不是“把整台机器打包走”，而是给排障保留刚好够用的证据。

哪些东西不会直接带走

默认红线很明确：

不直接打包 credentials/ 明文密钥
不直接打包私钥文件
不直接带明文 open_id
不直接带 allowFrom
不直接带 token / access_token / bearer token
不直接带 session_id / request_id / trace_id / signature

这不是“尽量少打一点”，而是脚本里明确做了脱敏规则。

当前脱敏规则大致是什么

支持包脚本会对文本和 JSON 两条线分别处理。

JSON 脱敏

重点处理这些键：

apiKey
appSecret
verifyToken
encryptKey
token
secret
clientSecret
accessKey
secretKey
password

这些值会被替换成：

<redacted>

而像 allowFrom、groupAllowFrom、main_open_id 这类用户标识相关字段，会被替换成：

<redacted-open-id>

文本脱敏

日志和 Markdown 文本还会额外过滤：

URL 里的 token=...
Authorization: Bearer ...
session_id
request_id
trace_id
sig
signature
形如 ou_xxx 的 open_id

这就是为什么支持包比“你自己手拷日志”更安全。

发出去前建议自己检查一眼

打完包后，别盲发。先做最小自查：

# 1. 看包里有哪些文件
tar -tzf ~/openclaw-support-*.tgz | sed -n '1,120p'

# 2. 抽看脱敏后的配置
tar -xzf ~/openclaw-support-*.tgz -C /tmp

# 3. 检查是否还残留敏感串
rg -n "ou_|access_token|Authorization: Bearer|appSecret|verifyToken|encryptKey|session_id|request_id|signature" /tmp/openclaw-support-* || true

如果上面还能 grep 出明显明文敏感值，先停，不要直接发。

结果文件怎么读

支持包生成后，结果会写进：

cat ~/.openclaw/state/support-bundle-result.json

它至少会告诉你：

本次动作是不是 support-bundle
生成时间
输出状态
输出路径
bundle 目录名

如果作者问你“你打包成功了吗”，这份比口头回答更可靠。

和结构化状态的关系

支持包不是独立体系，它会复用 state 主链：

先尝试刷新 state-migrate
再刷新 state-dashboard
再刷新 state-doctor
然后把这些结果一起打进去

也就是说，支持包不是只带日志，它还会把“日志之外的状态解释层”一起带走。

这也是为什么现在排障质量明显比早期只发截图高。

常见误区

误区 1：支持包越大越好

错。越大往往说明：

混进了不该进的目录
日志没做 tail
记忆文件被误打包
敏感暴露面变大

支持包应该是“证据浓缩包”，不是“整个家目录镜像”。

误区 2：日志已经脱敏，就不用看配置

也错。很多问题不是日志里能看出来的，而是配置结构不对。
所以支持包里必须同时有：

脱敏配置
状态文件
日志 tail

缺任何一类，判断都容易歪。

误区 3：支持包只在完全失败时才打

不对。很多“间歇性”问题最值得打包，因为过一会儿状态就没了。

红线：不要这样做

❌ 不要手工把 `credentials/` 压进去

支持包默认就故意不带这层。你手工补进去，相当于把安全边界直接拆掉。

❌ 不要把完整日志整份发过去

脚本只取最近 tail 是有原因的：降低噪声，也降低泄露面。

❌ 不要发一个自己都没看过的压缩包

最少做一次 tar -tzf 和关键词 grep，自查成本很低。

❌ 不要把支持包长期堆在桌面不清理

诊断包本身也是高敏感资产。排障完成后，按你的保留策略清掉旧包。

验证清单

检查项	怎么验
支持包能生成	`bash ~/.openclaw/scripts/collect-support-bundle.sh` 返回 0
有结果文件	`~/.openclaw/state/support-bundle-result.json` 存在
有事件记录	`events.jsonl` 里能看到 `support-bundle`
配置已脱敏	解压后 grep 不到明文 `appSecret` / `verifyToken`
`open_id` 已脱敏	解压后 grep 不到明文 `ou_`
日志有 tail 而不是全量	包内是 `*.tail` 或最近摘要文件，不是整个日志目录镜像

下一步

06-每周维护编排 —— 哪些周维护失败值得顺手打支持包
05-排障/00-常见问题 —— 具体报错对应什么诊断路径
07-实战/11-记忆候选到周合并的完整链路 —— 记忆链路出问题时要补哪些证据

本章准确性保证 本章对齐了当前模板里的 collect-support-bundle.sh 与对应 e2e 回归里的实际采集项和脱敏规则，文中所有示例路径都已按公开文档要求脱敏为 ~/.openclaw/ 形式。

导航：← 结构化状态与 State Doctor · 📖 目录 · → 每周维护编排