夜雨聆风最近大家在open claw的使用还顺利吗，如果你也曾好奇为什么扫码一次就能多端共用，那这篇文章就是为你准备的，相信大部分朋友和我一样都深深的感受到了这个工具的魅力所在，接下来几期，我会详细系统的发布open claw最底层，也是最重要的--网关运行书 相关内容，分享我在官网文件下学习的内容和过程，希望可以帮助我自己和朋友们更好的了解它底层的构建与维护，也期待大家的批评建议与斧正！
——————————————————
那么话不多说，let's go!
首先我们要搞清楚一些基础概念-什么是Gateway、CLI、Websocket
Gateway：是一个常驻进程，相当于open claw的引擎，负责用来维护所有的聊天渠道（Telegram、飞书、微信等等）的长连接、会话状态、消息队列及事件广播。它绑定在本地端口（默认18789）。
CLI：是临时性的客户端程序，每次执行open claw send或open claw gateway status，CLI都会通过WebSocket连接到Gateway，发送请求，接受响应后即断开连接。CLI本身不持有任何渠道状态，因此可以随意调用，不影响Gateway的稳定性。
Websocket：是一个网络通信协议，通过它，就可以在客户端和服务器之间建立 持久、全双工（通讯双方可以同时发送和接收数据，互不干扰）的连接。
——————————————————
接下来我们看三者的关系：Gateway是常驻服务，Websocket是它对外的通信协议，CLI是通过Websocket连接Gateway的众多客户端之一。
我们进行生活化的讲述就很好理解了：
Gateway是家中的电视，保持打开，连接了很多频道（飞书、微信等），负责接收信号，播放内容。
Websocket是电视机背后的信号线。它连接了电视机和遥控器，游戏机等设备，保证数据是双向传输的。
CLI则是我们手中的遥控器（只临时使用，用完即走），按一下按钮（执行一段命令）遥控器通过信号线给电视发指令，电视执行后，则放下遥控器。我们可能会有多个遥控器，但实际都在控制一台电视机。这样理解是不是更清晰了呢！
——————————————————
那为什么要这样设计呢？如果让CLI直接管理飞书或者微信连接，会有什么问题？
结果显而易见了：
从遥控器到电视机，搞懂 OpenClaw 的底层心脏
- 你关掉了终端，WhatsApp 就掉线了。
- 你想从另一台电脑发消息，但登录状态只在你本机，无法共享。
- 写一个程序自动回复消息，还得让那个程序一直开着，容易崩溃。
当我们把“保持连接”这个累活交给Gateway后就会很自然了
- Gateway 24小时在线，崩溃了会自动重连。
- 多台电脑、多个脚本都可以通过 WebSocket 连接同一个 Gateway，共享登录状态。
- 你写一个简单的 Python 脚本，只需要连接 Gateway 的 WebSocket，就能收发消息，根本不用管 WhatsApp 的登录逻辑。
——————————————————
接下来我们说到Gateway，看看它是怎么当“苦力”的：
一个Gateway可以同时服务多个客户端，这是它设计的优势之一。
那哪些算“客户端”呢？实际上
- 你在终端里敲的每次 openclaw ... 命令（CLI）
- 浏览器打开的 Web 监控界面（http://127.0.0.1:18789）
- 你自己写的脚本（通过 WebSocket 或 HTTP 连接）
- 其他 OpenClaw 节点（Nodes）
- 任何实现了 Gateway 协议的第三方工具
所有这些客户端都可以 同时 连接到同一个 Gateway 上。
这里我们再补充一下关于CLI的特殊之处：刚才不是说它是“遥控器”，怎么又划分到客户端了？
因为它是临时发起连接、主动请求服务的角色，只不过因为它的临时性：每次运行就存在，结束就消失，但实际上CLI和其他节点程序本质上没有区别。
——————————————————
我们说回Gateway
这样多客户端的好处是什么呢
1.共享登录状态
我们部署在微信或者飞书等渠道之后，只需要在Gateway上登录一次，所有的客户端都能通过它收发消息，无需重复扫码或配置Bot token。
2.并发操作
我们可以在浏览器里看ui面板，同时在另一个终端里用CLI发消息，还有一个脚本在后台监听新消息，他们互不干扰。
同时，多个团队成员可以连接同一个Gateway，共同管理和调试。
3.使资源更加高效
我们始终只用维护一份渠道长连接，而不是每个客户端各自登录，节省了系统资源和网络开销。
这就像你家里只有一台电视机，但你和家人都可以用各自的遥控器去控制它、看它的画面——电视机只保持一个信号源，但大家都能操作和观看。
关于更深的Gateway的工作机制和源码层面在本章我们就不过多展开了。
——————————————————
接下来我们讲认证与安全，安全是 Gateway 运行的基石。
Gateway的运行需要进行token验证，配置openclaw.json，这一点相信大家都已经经历过了。
如果遇到 connect.challenge 事件，说明认证模式可能是 password，需要去配置文件检查 gateway.auth.mode，一般改成 token 并设置一个 token 就能解决。
即使我们只在本地运行，但 Gateway的认证机制仍是默认开启的。如果没有默认认证，那任何人都会访问我们的端口，控制我们的聊天渠道，读取历史会话，调用我们的智能体，这是非常恐怖的事情。
——————————————————
这里给到大家一些常见安全实践
1. 定期更换 token：使用 openclaw gateway auth rotate 生成新 token，并更新所有客户端配置。
2. 最小权限原则：如果不需要远程访问，保持 Gateway 绑定在 127.0.0.1。如果确实需要远程访问，优先用 SSH 隧道或 Tailscale，而不是直接绑到 0.0.0.0。Gateway 本身有安全护栏：绑非本地地址却没配置认证时会拒绝启动。
3. 审计：运行 openclaw security audit --deep 可以自动检查常见的安全配置问题。
4. 日志敏感信息脱敏：默认日志中 token 会被遮盖，但不要将日志文件随意分享。
5. 启用 Bonjour 发现需谨慎：如果通过 Bonjour 广播服务，可能会暴露内网地址。可禁用：discovery.mdns.mode: "off"。
6. ~/.openclaw/ 目录下存有 token 和渠道凭证，建议设置为 700，配置文件设为 600，避免其他用户读取。
——————————————————
写在最后：学 Gateway 到底有什么用？
写到这，可能有人会问：我平时用 CLI 发消息、用 Web 界面看状态，不是挺好的吗？干嘛非要搞清楚 Gateway 是什么、怎么工作的？
这个问题，我在折腾这一下午的时候也反复问过自己。直到遇到坑的时候，我才明白值在哪里。
比如那天，我明明没设置密码，Gateway 非要我处理什么 connect.challenge ，如果不懂认证模式，我可能还在那猜半天；但知道 Gateway 的认证机制后，我直接打开配置文件把auth.mode从password 改成 token ，问题解决。
再比如，有一天我想从另一台电脑控制家里的机器人。如果不理解 Gateway 的网络绑定和远程访问方式，我可能会傻傻地把端口暴露到公网；但因为知道 SSH 隧道和 Tailscale 的存在，我选择了安全的方式，几分钟就连上了。
更实际的是，当我想写一个自动回复脚本时，我不再需要去研究 WhatsApp 的登录协议、处理多设备同步——这些脏活累活 Gateway 全包了，我只需要通过 WebSocket 连上它，发几条消息，就能实现我想要的功能。
学习 Gateway 的过程，其实是从“会用”到“懂用”的跨越。
它让你知道：
- 为什么渠道掉线了，重启 Gateway 就能恢复；
- 为什么多个客户端可以共享同一个登录状态；
- 为什么你的 token 和会话文件需要严格保护；
- 为什么官方文档反复强调“绑定 127.0.0.1”。
——————————————————
这些知识不会让我们立刻写出更炫酷的机器人，它就像家里的那台电视机，平时我们只需要按遥控器，但当你学会修它、连它、甚至改造它之后，你会发现它不只是个接收信号的盒子，而是整个家庭娱乐的中枢。
接下来，我会继续把我在官网文档里啃下来的内容，用更通俗的方式分享给大家。互相学习，共同进步，持续交流，保持开源！
