什么是Gateway Safety
Gateway Safety 是一套用于安全更新 OpenClaw 网关配置的操作约束与脚本机制，核心目标不是“改配置更快”，而是尽量避免把网关改到无法正常重启、反复进入异常循环，甚至造成当前会话永久中断。它针对的配置文件是 ~/.openclaw/openclaw.json，并明确要求不要直接手工编辑，而是统一通过提供的 safe-gateway-update.sh 脚本完成变更。
这套机制的价值在于把一次高风险的配置修改，拆成一套可验证、可回退的安全流程。执行更新时，脚本会先检查新 JSON 配置的语法是否有效，再备份当前配置，随后应用新配置并重启网关。真正决定是否“提交成功”的，不只是文件写入完成，而是网关能否在重启后通过健康检查，出现成功的 RPC 探测结果；如果检查失败或超时，系统会自动回滚到旧配置。
从运维角度看，Gateway Safety 相当于给网关配置变更加了一层保险丝。它既保留了脚本自动备份能力，也提醒在关键改动前人工确认 ~/.openclaw/openclaw.json.known-good 是否是最新的可用版本，避免在回退时找不到真正可靠的基线配置。相比直接覆盖配置文件，这种做法更适合对稳定性要求高、不能轻易掉线的网关环境。
另外，它还内置了一条非常严格的防护规则：如果安全更新脚本连续失败 3 次，就会生成 GATEWAY_LOCKOUT 文件。一旦这个文件存在，就必须停止后续操作，不能尝试绕过锁定，而是等待指定负责人介入处理。这个设计说明 Gateway Safety 不只是一个“更新脚本”，更像是一套防止误操作不断放大问题的安全边界。
核心功能特点
- 禁止直接编辑 openclaw.json，统一通过 safe-gateway-update.sh 执行配置更新
- 更新流程自带 JSON 语法校验、当前配置备份、重启后的健康检查与失败回滚
- 以“RPC probe: ok”作为提交新配置前的验证信号，避免网关重启后失联
- 关键变更场景下可结合 known-good 配置做人工确认，提升回退基线的可靠性
- 脚本连续失败 3 次会触发 GATEWAY_LOCKOUT 锁定机制，阻止继续高风险操作
适用场景
它最适合用在 OpenClaw 网关已经承载实际连接或会话的场景中。此时一次看似很小的配置调整，都可能带来重启失败、连接中断或服务不可达的问题。通过先校验、再应用、再健康检查、失败即回滚的流程，Gateway Safety 能把“改完才知道出问题”的被动局面，变成“验证通过才真正切换”的受控发布过程，尤其适合不希望因为配置失误而失去远程访问能力的环境。
在日常运维中，只要涉及网关配置变更——无论是准备好的新 JSON 配置文件上线，还是对现有网关参数做较关键的调整——都适合通过它来执行。它并不强调复杂的功能扩展，而是聚焦于把变更这一步做稳：检查配置本身是否成立、给旧版本留后路、确认网关真的恢复健康。这种方式很适合那些更新频率不一定高，但每次失败代价都比较大的团队或个人维护者。
如果当前环境已经出现连续失败、脚本触发锁定文件的情况，它的适用场景就从“继续修改”转为“立刻止损”。规则要求在检测到 GATEWAY_LOCKOUT 后停止全部后续操作，不尝试绕过限制。这说明它也适用于故障扩大前的风险隔离：当系统判断当前变更过程已经不安全时，优先阻断进一步尝试，而不是让操作者在压力下反复重试，把可恢复的问题推向更难处理的状态。
对于需要保留稳定基线的配置管理场景，Gateway Safety 也有现实意义。脚本自身会维护备份，而在关键调整前再核对一次 known-good 配置是否最新，可以让回滚不只是“回到上一个版本”，而是尽量回到经过确认可用的版本。因此，它尤其适合那些把网关可用性放在首位、希望降低配置发布风险、同时愿意遵循严格操作边界的 OpenClaw 使用环境。