2026 年 2 月 22 日，安全研究员 @GrMPbody 在 Twitter 上发了一组截图：Shodan 搜索显示超过 40,000 个 OpenClaw 实例的 Web 端口直接暴露在公网上。不需要密码，不需要认证令牌，打开浏览器输入 IP 地址就能访问——包括对话历史、配置信息，在某些情况下甚至包括 API 密钥。
这条推文在 12 小时内被转发了 3000 多次。OpenClaw 社区紧急发布了安全公告，建议用户立即配置反向代理和认证中间件。但 4 万个暴露的实例意味着大量用户可能根本不知道自己的 agent 正在向整个互联网敞开大门。
问题的根源很清楚：OpenClaw 默认启动一个 Web 服务器来提供管理界面和 API 端点，而大多数用户在部署时没有配置额外的安全层。
默认配置的陷阱
OpenClaw 的默认安装会在 3000 端口（或用户配置的端口）启动一个 HTTP 服务器。这个服务器提供 Web 界面、REST API、WebSocket 连接和健康检查端点。在本地开发环境中，这没有问题——你的 localhost 不对外暴露。
问题出在部署环境。当用户把 OpenClaw 部署到 VPS、云实例或家庭服务器上时，如果没有额外配置防火墙规则或反向代理，这个端口就直接暴露在公网上了。OpenClaw 的安装文档中确实提到了安全配置建议，但"提到"和"强制"是两回事。4 万个暴露实例证明，大多数用户不会去读安全配置文档。
这是一个经典的安全设计问题：安全应该是默认的，而不是可选的。当安全配置需要用户主动操作时，它实际上是不存在的——因为永远有用户不会做。
NanoClaw 的零暴露面
NanoClaw 不启动任何 Web 服务器。不监听任何 TCP 端口。不提供任何 HTTP API。
NanoClaw 的通信模型完全基于出站连接：它主动连接到 WhatsApp（通过 Baileys 库的 WebSocket 连接）和 Anthropic API（通过 HTTPS）。这两个连接都是出站的——NanoClaw 连接到外部服务，而不是等待外部服务连接到它。
这意味着从网络安全的角度看，NanoClaw 的攻击面是零。你无法用 Shodan 扫描到它，因为它不监听任何端口。你无法从外部连接到它，因为它没有提供任何接受入站连接的服务。你无法通过 HTTP 请求获取它的数据，因为它没有 HTTP 服务器。
这不是一个安全功能——这是架构的自然结果。NanoClaw 的功能不需要 Web 服务器。用户通过 WhatsApp 和 agent 交互，不通过 Web 界面。管理操作通过命令行完成，不通过 REST API。所以根本就没有理由启动一个 Web 服务器。
最安全的代码不是写了很多安全检查的代码，而是根本不需要安全检查的代码——因为攻击面本身就不存在。
服务端口 vs 消息驱动
两种架构的差异可以用一个简单的模型来理解。
OpenClaw 是一个服务端架构：它启动后监听端口，等待请求到来，处理请求，返回响应。这种架构天然需要处理"谁可以连接到我"这个问题——这就是认证和授权。
NanoClaw 是一个消息驱动架构：它启动后连接到消息源（WhatsApp），等待消息到来，处理消息，通过同一个连接发送响应。它不需要处理"谁可以连接到我"这个问题，因为没有人连接到它——它连接到别人。
消息驱动架构不是在所有场景下都优于服务端架构。如果你需要一个 Web 界面，你就需要一个 Web 服务器。如果你需要一个 API 供其他系统调用，你就需要监听端口。但如果你的核心使用场景是通过聊天平台交互，消息驱动架构提供了一个根本性的安全优势：没有入站攻击面。
4 万个教训
这 4 万个暴露的 OpenClaw 实例是一个行业级别的教训：不要假设用户会正确配置安全。
安全必须是默认的。如果你的软件默认不安全，那么它的大多数部署就是不安全的。这不是用户的错——这是设计的错。安全不应该是一个额外的步骤，不应该是文档中的一个章节，不应该是一个可选的配置项。
NanoClaw 的做法是最彻底的：消除需要安全配置的攻击面。你不需要配置防火墙规则，因为没有端口需要保护。你不需要设置认证中间件，因为没有 HTTP 端点需要认证。你不需要阅读安全配置文档，因为没有安全配置需要做。
安全最好的状态不是"配置正确时很安全"，而是"无论怎么配置都安全"——或者更好——"根本不需要配置"。