2026-08-01T05:55:37.471Z
OpenClaw 门口代码: 诊断无需泄露
通过秘密安全证据合同,分开网关可访问性,凭证来源,握手,设备范围,配对和准备性.
一个OpenClaw Gateway代币不健康,仅仅是因为它存在于配置文件中,或者因为仪表板上 HTML 加载. 有用的证据是链接:Gateway可访问,预期的凭证来源已解决,WebSocket握手接受了它,设备具有所需的范围,Gateway已经足够准备好执行预期的操作. 这种区别早就会回答常见的故障解决问题. 如果您看到 unauthorized , 1008 , AUTH TOKEN MISMATCH , AUTH SCOPE MISMATCH ,或 pairing required ,请不要开始禁用 auth或旋转每个代币. 首先分类失败层. 一个共享代币的不匹配,一个不够范围的识别设备和一个未经批准的新设备是不同的事件, 最安全的默认方式是从Gateway主机工作,使用 openclaw dashboard 来启动浏览器,在本地主机,TailscaleServe或SSH道上保留Control UI,并在门票和健康报告中保存只有无秘密证据. 分开五层,可以独立失败. OpenClaw的当前文档描述了Gateway为道,节点,会议和的WebSocket服务器. 它的仪表板是一个管理面:它可以暴露聊天,配置和执行批准. 在WebSocket连接被拒绝时,页面可以通过HTTP到达. 这就是为什么显示Control UI的浏览器还不是一个认证的会话. 使用五层: 层 问题 安全证据 它没有证明的 交通 客户端可以达到预期的主机,端口,道和TLS终端点吗? 目的地类,连接结果,时间印 这位作者曾经尝试过 证书来源 预期的代币,密码,SecretRef或身份模式是否解决了? auth模式,源类型,现/缺 客户端和服务器值一致 握手 网关是否接受了提出的路径? 正常化结果如 ok , token missing 或 token mismatch 设备范围足够 设备权限 设备是否配对并获得要求范围的批准? 设备ID别名,要求范围,批准状态 插件和道已经准备好了 准备 验证的客户能执行预期的操作吗? 准备结果和一个有限的操作收据 一个单独的代理任务完成 这种模型可以防止熟悉的假绿色: /healthz 响应活力,而 /readyz 更严格. 目前的Gateway CLI文档显示,在启动插件侧车,道或配置的子仍在定位时,准备仍然是红色的. 任何终端都不能取代一个认证的WebSocket握手. 另一方面也是重要的. 一个成功的握手,然后是 not ready , 在这种状态中旋转共享的秘密增加了漂移,而不需要修复阻塞组件. 收集证据而不是收集代币 一个有用的事件记录从来不需要共享的代币值. 它还不需要代币前,可逆的指纹, Authorization 标题,cookie,包含碎片的仪表板截图或 openclaw.json 副本. 仅记录: 这足以引导案件. 它说源已解决,服务器还在线, 但一个被识别的设备没有要求的权威. 下一个正确的举动是批准范围或重新对不共享代币转换. 目前的仪表板合同有几个值得保存的细节: 在 WebSocket 握手时执行 auth; 在 sessionStorage 中保存到仪表板上传输的代币,用于当前浏览器选项和选定的Gateway URL,然后从URL中删除; openclaw dashboard 是推的本地启动线路; 由于没有配置共享秘密而生成的运行时间代币是短暂的,不能用 openclaw config get gateway.auth.token 获取; 一个由SecretRef管理的代币故意生成一个非代币化仪表板URL; 控制UI不应公开曝光. 这些是处理规则,而不是邀请将代币粘贴在支持门票上. 如果主机本地故障解决真的需要查看或解决一个凭证,请保持该步骤是互动的,并且不会被捕获的输出. 永远不要通过聊天,截图,CI日志,痕或文章连接发送. 当远程CLI命令使用明确的 url 时,当前的GatewayCLI文档表示它不会回到配置或环境凭证. 呼叫者必须提供明确的答案. 这种行为可以解释缺失证书的失败, 即使当地的命令成功. 它不合理直接将真正的代币放入文档或可重复使用的命令历史记录中. 在选择修复之前分类故障 为了本文构建的文物接受上述无秘密字段,并拒绝诸如 token , password , Authorization , cookie , secret 等密钥,甚至是代币哈希. 根据证据文件进行测试: 对于范围不匹配,输出量是故意缩小的: 伴侣装置包括八个案例:无法到达的运输,失踪的凭证,代币漂移,范围不匹配,需要对配,准备,验证但未准备,和现实但未验证. 许多案件都与 httpLiveness: true 相同. 他们仍然作出不同的判决,因为活力不是决定的边界. 使用此维修表: 判决 最强的证据 限制性维修 验证 UNREACHABLE 与预期目的地连接失败 修复路线,道,绑定,TLS,听器或DNS 在自动驾驶前重复运输检查 CREDENTIAL MISSING auth模式需要一个秘密,但预期的来源不存在,或者手握报告不存在 在 Gateway 主机上解决配置的源 新的握手结果;输出没有秘密 TOKEN DRIFT 经过任何记录的可信度重试后, AUTH TOKEN MISMATCH 确定配置的源和客户端路径有什么不同;只使用权限旋转 使用预期来源的认证握手 SCOPE REPAIR REQUIRED 已识别的设备的 AUTH SCOPE MISMATCH 批准所需的范围设定或重组 在批准的范围下,所要求的操作取得成功 WAITING FOR PAIRING 服务器请求设备批准 授权所有者批准悬而未决的设备 握手成功,达到预期范围 AUTHENTICATED NOT READY 握手成功了,但准备仍然是红色的. 诊断准备组件 准备性加上一个预期操作 READY 握手和准备签证 没有修复 保存时间印记的收据 UNCERTAIN 缺乏证据或矛盾 收集下一个缺失的层 重新分类;不要猜测健康 AUTH TOKEN MISMATCH 值得照顾. 现在的仪表板指导显示,当Gateway提供重试提示时,客户端可能会使用缓存设备代币进行一次可信的重试. 如果重复尝试失败,请手动修复代币漂移. 不要构建无限的连接循环,不要将旧的 gateway.remote.token 解决方案从历史问题中作为当前合同. AUTH SCOPE MISMATCH 更具体. 设备的凭证被认可,但它缺乏所需的范围. 转换共享代币不提供这些范围. 通过授权的路径修复或批准新的范围. pairing required 是一个等待状态,不一定是一个破碎的门户. 产品所有者必须决定该设备和要求的权威是否合法. 如果把它视为停电, 预期运营的检测检测 恢复需要一个步骤,而不是绿色连接. 在运输,握手,范围和准备经过后,执行一个有限的操作,代表客户的实际需求. 一个仅阅读的状态或健康查询可能足够于观察者. 一个行政客户需要自己的经营证. 不要扩大许可仅仅是为了通过测试. 一份复原收据可以包含: 收据遗漏了代币和任何经纪人返回的内容. 这证明了预期层没有将事件记录转化为证书存储器. 有三个有用的界限: 1. 无法禁用 auth 诊断 auth. 在 none 下成功连接只证明了未经过 auth 检查. 它也改变了管理器表面的威胁模型. 2. 在发现漂移之前不要旋转. 旋转可以使健康的客户无效并将本地源解决问题转化为整个机队的代币漂移. 3. 不要要求对配或范围批准自动恢复. 两者都授予权. 它们需要拥有者决定和审计轨迹. 这件文物有故意的限制:它分类提供证据,但不能检索,比较或验证真正的证书. 这是一个特征. 秘密检索将在网关主机上留在授权操作员那里. 报告仍然可以分享. Sidewisp的计划健康模型包括可用性,工具访问,许可丢失,等待状态和安全恢复界限. 未来的OpenClaw适配器可以收集无秘密连接和准备性证据,但它必须区分诊断与权威,不得上传代币,密码,提示或原始日志. Sidewisp 目前处于私密预览阶段。 生产监测引擎,OpenClaw适配器和恢复执行器一般不出货. 公共网站和文章系统现场; 如果您想在您已经经营的代理人中获得一项健康的证据,请加入预览. 来源:通过OpenClaw门户 CLI,OpenClaw 仪表板认证,OpenClaw 网关配置和Sidewisp产品状况.