系列：加固你的自托管 OpenClaw
L0（本文）→ L1：Basic Auth → L2：OAuth/OIDC → L3：速率限制与审计 → L4：全自动化
OpenClaw 生来是跑在你个人电脑上的。你把它部署到了 VPS。没问题——很多人都这么做。但”能用”和”放在公网上是安全的”之间，存在一道缺口。这个系列就是为了填上这道缺口。
不是在评判谁。这道缺口本来就不明显，得有人指出来才知道。
原始设计本身没有错
OpenClaw 的定位很清晰：一个本地运行的个人 AI Agent，数据留在你自己的机器上，不会把任何东西发到不该去的地方。它的威胁模型是：一个受信任的用户，在一个受信任的网络里。对于一个本地优先的工具来说，这个范围是合理的，团队也是按这个思路诚实地设计的。
官方推荐的远程访问方案是隧道——SSH 端口转发、Tailscale、Cloudflare Tunnel。私密、加密、零公网暴露。如果这套方案适合你，关掉这个标签页去做点更有意思的事，你不需要这个系列。
但”永远在线、随时用浏览器打开、也许还要分享给团队成员”是完全不同的使用场景，而这恰恰是很多 OpenClaw 部署最终走向的地方。一旦你把它放到有公网 IP 的 VPS 上，你运行的就不再是一个本地助手了。你在运行一个 Web 服务。Web 服务需要 Web 服务该有的安全措施。
默认的安全配置究竟给了你什么
Gateway 只用一个 token。你把它粘贴到 Control UI 的文本框里，点击连接，就进去了。干净、简单，在本地用完全没问题。
放到公网服务器上，这个 token 就是公网与你 Agent 完全控制权之间唯一的屏障。问题在于：没有任何机制对猜测次数加以限制。
OpenClaw 社区注意到了这个问题。GitHub issue #29567 把它说得很清楚：
“部署在公网服务器上时，没有任何内置保护来防止：暴力破解 token 猜测——认证尝试没有速率限制；token 持有者的滥用——没有针对每个 IP 或每个用户的消息量速率限制；地理/IP 过滤——没有可信 IP 范围的白名单。用户必须手动配置外部工具（Nginx、UFW、Cloudflare）来添加这些保护。这需要相当的基础设施知识，且官方安装指南中没有文档说明。”
最后那句话意味深长。这些保护手段是存在的——只是你得知道要去加，还得知道怎么加。这个系列就是那份 issue 在呼唤的文档。
需要说清楚的是：这不是一份漏洞披露报告。OpenClaw 团队构建了一个本地优先的工具，它的行为也符合这个定位。问题出在原始设计范围与人们实际部署方式之间的错位。这是文档问题，不是安全漏洞。
我们在讨论多大规模的问题
OpenClaw Exposure Watchboard 追踪可从公网访问的 OpenClaw 实例数量。当前计数已超过 60 万。
这不是 60 万人犯了错误。这是 60 万个部署，无知的配置遇上了它原本没有被设计来应对的使用场景，而没有人指出这道缺口。其中一些实例做了额外的加固，很多没有。
如果你把 OpenClaw 部署在了 VPS 上，还没有加任何外部认证层——去看看那个数字。你大概率也在里面。
三个诚实的选项
没有唯一正确答案——取决于谁需要访问，以及你对流量经过哪里有多在乎。
Tailscale（或 SSH 隧道）。 所有需要访问的人安装 Tailscale、加入你的网络，完成。零公网暴露，没有任何安全层需要维护。缺点是：每个用户都需要安装 Tailscale 客户端，这让它在分享给外部用户或无法统一部署客户端的场景下很不实用。另外值得了解的是——Tailscale 默认使用 DERP 中继服务器，意味着你的流量会经过他们的服务器，除非你自己搭建中继基础设施，而那本身又是另一个工程项目。个人使用很顺手，稍微涉及团队就开始别扭。
Cloudflare Tunnel + Access。 不需要开放端口，CF 负责 TLS 和认证界面，配置相对容易。代价是：所有流量——每一条 prompt、每一条回复、Agent 的一切行为——都流经 Cloudflare 的边缘节点。对于 OpenClaw 这样隐私优先的工具来说，这一点值得认真考虑。你还在给自己加上一个对 CF 可用性和政策决定的硬性依赖。
自托管反向代理 + 自建认证层（本系列）。 流量从客户端直达你的 VPS，再到 OpenClaw。路径上没有任何第三方，没有中继，没有边缘节点看到你的数据。对认证机制、日志、速率限制拥有完全控制权。代价是你要自己搭建和维护这个安全层——而这正是 L1 到 L4 要做的事。
如果你只需要自己访问，且 Tailscale 适合你的工作流，就用 Tailscale。如果你需要把访问权限分享给外部用户，同时在意流量不经过第三方基础设施，这个系列就是你要走的路。
L1–L3 分别构建什么
每一篇后续文章都是独立的操作手册——前置条件、执行步骤、验证方法。没有背景介绍，没有重复的上下文。背景就是你现在正在读的这篇。
L1 — Caddy + Basic Auth。 一个反向代理，在任何请求触达 Gateway 之前先要求用户名和密码。自动化 token 猜测攻击立刻被截断。一个配置文件，二十分钟。
L2 — oauth2-proxy + OAuth/OIDC。 把密码提示框换成真正的登录流程——Google、GitHub 或任意 OIDC 提供商。加入 session 管理、用户级访问控制，以及完整的审计日志。
L3 — 速率限制、IP 过滤、访问审计。 叠加在 L1/L2 之上的网络层控制。当你需要知道是什么在打你的实例、并让它慢下来的时候，这一层就派上用场了。
L4 — Warded：一句话，全部搞定
即将推出
L1 到 L3 都有效。但说实话，这也是相当多的 YAML、相当多的配置文件，以及不低的基础设施门槛。如果你喜欢折腾这些，完全没问题。但不是每个人都喜欢，就算喜欢的人，也不一定每次都想花一个下午在这上面。
Warded 是我正在构建的一个工具，用来自动处理整个安全栈——反向代理、TLS 证书、二级域名、无密码登录、速率限制、访问日志。L1 到 L3 覆盖的一切，几秒内完成配置。你会得到一个专属的 yourname.warded.me 子域名，流量直达你的实例，路径上没有任何第三方中继，整个过程只需要跟你的 OpenClaw Agent 说一句话：
“帮我开通 Warded 服务。”
就这样。剩下的事 Agent 来处理。
Warded 是为那些希望 OpenClaw 部署得到妥善保护、但更想把时间花在真正使用 Agent 上的用户设计的。如果说的就是你，在 warded.me 加入候补名单，准备好了我会通知你。
你的 Agent，Warded。
继续之前，先做一个检查
在花时间去看 L1 之前，先确认你的 OpenClaw 端口确实暴露在公网：
1 | ss -tlnp | grep <你的-openclaw-端口> |
看到 0.0.0.0:<端口> 或 *:<端口> — 已暴露，前往 L1。
看到 127.0.0.1:<端口> — 仅本地监听，先搞清楚前面已经有什么在守着它，再决定是否继续。