最近“25 万 OpenClaw 实例暴露”的消息在 AI 圈子里传得挺快很多人第一反应是“又一个数据库裸奔”但这次的主角不是存储而是 AI 智能体框架 OpenClaw。简单说就是一个能帮你操作电脑、调用网页、跑工具的开源 Agent 框架最近两年因为“可控 AI 助手”这个概念火起来被不少人拿来部署在个人电脑、云主机、甚至手机上。这次事件里最扎心的一句话是你可能压根不知道自己装了一个 OpenClaw更不知道它已经开着大门在公网裸奔了。我之所以想写这篇东西是因为这事对普通用户、对开发者都有实际参考价值。它不光是“某项目有漏洞”那么简单的新闻而是暴露了 AI Agent 类应用在部署习惯上的通病默认配置不收敛、认证缺失、密钥明文存储。不管你是用 Docker 一键起服务、在 Windows 上配 Companion、还是在 Termux 里折腾手机版这篇文章都能帮你把风险点捋清楚并且给出可以直接照抄的自查和加固步骤。内容不复杂也不需要安全专家的背景按着顺序走一遍就知道了。1. 先搞清楚OpenClaw 到底是什么为什么它能攒出这么多“实例”说实话标题里“25 万”这个数字虽然吓人但如果不懂 OpenClaw 是什么很容易把它想象成一种“服务器软件感染”。其实它更接近一个“AI 员工调度中心”。1.1 一个能替你干活的多 Agent 管理框架OpenClaw 的核心定位是管理并调度多个 AI Agent。你可以让它接入 Claude、GPT、本地开源模型这类大模型后端然后给 Agent 配置不同的“工作能力”比如读网页、操作鼠标键盘、执行 Shell 命令、调用第三方 API。它的架构里有两个特别有意思的组件主控端Core负责接收指令、规划任务、编排 Agent 流程。执行端Companion跑在具体设备上的轻量程序负责替主控端操作本机系统。比如你在手机上部署一个 Companion主控端就能让手机帮你发消息、查日程、执行自动化任务。这种“大脑”和“手”分离的设计决定了它天然需要开放网络端口才能工作。主控端会启动一个 WebSocket 或 HTTP 服务等待 Companion 或客户端连接。问题就出在这个“等待连接”上——如果监听地址是0.0.0.0那全世界都能连进来。1.2 为什么个人用户会扎堆部署 OpenClawOpenClaw 的流行不是偶然的。它是开源项目文档和社区教程极其丰富一条docker run或者npx openclaw就能跑起来。加上它允许接入本地模型比如通过 Ollama不强制付费订阅云端 API对开发者、AI 爱好者、折腾党来说这几乎是零成本入门 AI Agent 的最佳选择。更重要的是网上铺天盖地的“OpenClaw 教程”已经把门槛踩碎了。有教在 Windows 上装 Companion 的有教在安卓 Termux 里跑手机版的有教在云主机上部署当“个人秘书”的。教程多了是好事但坏处也很明显很多人是照抄命令、复制配置根本不理解每一行参数是什么意思。比如docker run -p 3000:3000这种最常见的命令把容器的 3000 端口直接暴露给宿主机所有网卡。如果这台机器有公网 IP或者路由器做了端口映射OpenClaw 就等于直接挂在了公网上。1.3 “实例多”和“暴露多”为什么能同时发生我得先说清楚一个逻辑实例数量大不代表暴露数量一定大两者之间隔着一层“是否有公网可达性”。OpenClaw 的下载量、部署基数确实在快速增长但真正让它变成事件的是两类人的叠加一类是“只想自己局域网用结果误开了公网”的普通用户另一类是“买了云服务器专门挂着跑任务但安全组规则全放行”的开发者。任何人都可以通过搜索引擎级的资产测绘工具在全网范围内扫描开放端口识别服务指纹从而找到这些 OpenClaw 实例。25 万这个数字不是凭空编出来的它来自对公网 IP 段的全量扫描。开发者基数大再加上配置不当的比例哪怕只有 1%绝对数量也足够吓人了。我们要做的不是恐慌而是确认自己的实例是否属于这 25 万里的一分子。2. 25 万 实例暴露问题到底出在哪儿既然数字已经出来了我们得知道这些实例是怎么“暴露”的。我把它拆成四个层面每个层面都能解释一批受害者的产生原因。2.1 最直接的原因服务默认监听所有网卡几乎所有 AI Agent 类框架都有一个“为了省事”的默认配置监听0.0.0.0。这样同一个局域网里的设备都能访问开发者自己调试时也方便。但对个人用户来说这往往意味着“只要你能连上我的电脑你就能连上我的 Agent”。你可以用一句命令确认自己中没中招。Linux 或 macOS 下执行ss -tnlp | grep -E LISTEN|openclaw|node|pythonWindows 下用 PowerShell 执行netstat -ano | findstr LISTENING重点看监听地址。如果某个端口的监听地址是0.0.0.0或[::]说明所有网卡上的外部连接都能直达。如果只是127.0.0.1那基本只允许本机访问风险小很多。2.2 比裸监听更危险的是没有认证如果你部署过 OpenClaw大概率见过它的配置文件一个 JSON 或 YAML 文件里面可能写了port、host、authToken之类的内容。这里的关键是很多快速启动教程默认把认证功能关掉或者根本没有引导用户设置密钥。服务本身甚至自带一个简洁的 Web 控制台或者 WebSocket 端点任何人都能连接。你可以把它理解成一间没有锁的门——不是不能锁而是安装时默认不配锁。攻击者扫描到端口后根本不需要什么复杂漏洞利用直接连上去就能向你的 Agent 下发指令。恢复感兴趣的话他们还能读取 Agent 的历史对话记录、已保存的任务配置甚至通过 Agent 的工具体帮你“跑个命令”“读个文件”。这时候 Agent 就从一个“个人助理”变成了黑客的“远程控制木马”。2.3 API 密钥硬编码进配置、环境变量、甚至日志里OpenClaw 需要调用大模型 API所以配置里几乎必然包含 API Key。有的教程让你写在.env文件里有的让你直接填进openclaw.json的llm字段中。问题在于很多实例的 API Key 是明文存储的而且日志系统还会把请求参数打出来。一旦实例暴露且未授权访问攻击者第一件事就是翻配置文件、翻环境变量、翻日志把 API Key 拖走。后果不只是“你的 Agent 被控制”还包括你的模型服务账户被拿去刷钱、被用于恶意任务。这不是危言耸听近几年 AI 相关的 API 密钥被滥用的案例多到数不清。2.4 资产测绘你的实例早就“实名登记”了技术上暴露实例能被统计出 25 万这个数字靠的是资产测绘引擎。它们每天扫描全网 IP 的常见端口通过 Banner 抓取、协议握手、HTTP 特征等指纹识别出正在运行的 OpenClaw。这个过程无法完全避免——只要你的服务在公网可达就一定会被探测到区别只是时间早晚。这也意味着“自查自己是否暴露”并不难你可以去资产测绘平台搜索自己的公网 IP 或域名看看有没有出现 OpenClaw 相关的端口和服务指纹。如果你从来没做过这类查询那我现在建议你去做一次。下面马上说具体怎么做。3. 自查三步走确认你的 OpenClaw 在不在名单里我不打算给你塞一堆检测脚本因为对大多数人来说三步操作已经足够覆盖 90% 的暴露场景了。3.1 第一步先看本机监听端口和进程不管是 Linux、macOS 还是 Windows第一步都是确认本机到底有什么服务在监听以及监听地址是什么。Linux / macOS 下可以依次跑ss -tnlp lsof -i -P -n | grep LISTEN如果你发现某个进程node、python、openclaw 相关监听在0.0.0.0:3000或*:3000那这一步就已经“中招”了。Windows 下运行netstat -ano | findstr :3000 tasklist | findstr PID如果你能看到0.0.0.0:3000或[::]:3000同样说明服务对所有网卡开放了。3.2 第二步检查配置文件和密钥状态找到 OpenClaw 的配置目录。不同部署方式路径不太一样常见的是Docker 部署在容器内/root/.openclaw/或宿主机挂载的目录npm/源码部署~/.openclaw/Windows CompanionC:\Users\用户名\.openclaw\打开openclaw.json或者.env文件重点看两个字段一个是host如果写的是0.0.0.0立刻改成127.0.0.1另一个是apiKey或OPENAI_API_KEY之类的内容。这里我想多提醒一句只要里面出现过明文密钥不管你是否确认暴露从安全角度都应该轮换掉因为你的配置文件可能已经被扫描器抓走了只是你还不知道。3.3 第三步验证公网可达性并检查访问日志本机检查完了再验证公网侧。如果你的机器有公网 IP或者你做过路由器端口映射、云服务器安全组放行那就用自己的手机流量不要连同一个 Wi-Fi访问一下http://你的公网IP:你的端口如果页面返回了控制台登录页、WebSocket 握手响应甚至直接是 OpenClaw 的界面那基本可以确认你已经“公开发布”了。如果访问没有任何反应也不代表绝对安全因为还有防火墙可能拦截了部分来源。最后再翻一下 OpenClaw 的日志文件通常在~/.openclaw/logs/下。直接搜索有没有不认识的 IP 地址访问记录grep -E ([0-9]{1,3}\.){3}[0-9]{1,3} ~/.openclaw/logs/*.log看到陌生 IP 也不要马上紧张——先确认是不是你自己云主机公网 IP、家里的动态公网 IP 都算。4. 应急加固从暴露名单上把自己摘下来如果你按照上面的步骤发现自己的实例确实暴露了别慌。现在的重点是抢时间把攻击路径封死。4.1 立刻止血停服务、改监听地址、关掉入口“止血”这几个动作要按顺序做停掉 OpenClaw 服务。如果用的是 systemd执行systemctl stop openclaw如果用的 Docker执行docker compose down如果是纯手动的 node 进程直接杀掉对应进程。修改配置中的host为127.0.0.1。这个字段决定了服务绑定的网卡只回环后外部就无法直接访问了。在云服务商控制台检查安全组入方向规则删掉针对 OpenClaw 端口的0.0.0.0/0放行规则如果是物理机检查系统防火墙例如ufw deny 3000/tcp或firewall-cmd --remove-port3000/tcp。如果你在路由器上做了端口映射或 DMZ立刻关掉。这样做之后你的服务仍然可以在本机使用但不会再暴露到公网。4.2 如果你真的需要远程访问加一层“认证网关”完全禁掉公网访问对有些人不现实。比如你把 OpenClaw 部署在云主机上人不在服务器旁边还想远程控制。这时候正确的姿势不是直接开端口而是把 OpenClaw 藏在带认证的反向代理后面。下面我用 Caddy 给你一个可以直接抄的配置{ admin off } openclaw.example.com { tls internal basicauth { your_username $2a$14$... } reverse_proxy 127.0.0.1:3000 }先用caddy hash-password生成密码哈希替换掉$2a$14$...那一段。Caddy 可以自动申请和续期 TLS 证书tls internal是本地测试用的公网部署建议去掉这一行让它自动签发证书并且强制在网关这一层要求用户名密码。这样即使 OpenClaw 本身没有认证外部流量也过不了 Caddy 这一关。重点说一下为什么“加反向代理”比“直接开端口”安全直接开端口相当于把入口平铺给全互联网扫描器而反代是唯一且受控的入口配合 TLS 加密和基本认证让攻击者连“看到真实能力”的机会都没有。你可以理解成前者是打开家门后者是开了一个只有拿钥匙的人才能进的门禁。4.3 轮换 API 密钥清理可能泄露的痕迹如果你的实例确实被未授权访问过甚至只是“可能”被扫描发现过API 密钥都建议全部重置。去模型服务商的控制台找到密钥管理页面吊销旧的生成新的并更新到 OpenClaw 配置里。这样做哪怕对方已经从你的配置里偷走了密钥也无法继续使用。另外很多人会忽略日志和对话记录的清理。OpenClaw 运行后会记录用户指令、Agent 的工作日志、可能还有访问过的网页内容。如果这些日志已经暴露给第三方里面可能存在敏感信息。你可以直接清空存放的日志目录同时在配置里关掉不必要的日志输出级别。不要觉得“我自己用没多大事”一个能读你邮件、看点网页、执行命令的 Agent它的历史日志几乎等同于“你到底有什么秘密”的索引。4.4 把加固变成部署流程的一部分应对这次暴露事件咱们不能只修一次更要养成习惯。我建议你把下面几条写进自己的部署检查清单每次部署完先ss -tnlp看监听地址再决定要不要调整。访问密钥一律放环境变量不要硬编码在配置或代码里。云安全组入方向默认拒绝只放行确实需要的端口。如果用 systemd 运行顺便加上最小权限配置下面这个模板可以直接用[Service] Useropenclaw NoNewPrivilegesyes PrivateTmpyes ProtectSystemstrict ReadWritePaths/home/openclaw/.openclaw这些选项的意义是让进程只能写到自己的目录不能随便碰系统文件。不能解决所有问题但能明显拉高攻击成本。5. 不同部署姿势下的避坑重点最后这部分我把这次热词里最常被问到的几个场景单独拿出来聊。它们不算安全事故本身的高发区但部署细节决定了你是否会变成“下一批名单”。5.1 Termux 手机版玩归玩别把端口怼到公网“在 Termux 安装 OpenClaw 手机版”确实很吸引人毕竟等于把 AI 助理装进口袋。网上很多教程会让你用proot-distro install ubuntu装 Linux 环境然后继续按 Linux 的方式跑。Termux 本身在 Android 上运行时服务默认监听手机的局域网地址很多时候不会直接暴露公网。但如果你的手机开了热点、又配合了某种公网映射工具比如家庭宽带上的动态域名情况就变了。我的建议是手机版只允许回环访问也就是配置里的host: 127.0.0.1。这样你只能在 Termux 内部或者通过 SSH 连进去操作。毕竟手机的算力、电池和网络环境都不适合当长期公开服务真需要公网访问不如部署在正经服务器上再套上反代。5.2 Windows Companion你的“手”要看住本地端口Windows 上配置 Companion 是很多人最容易忽略安全问题的环节。Companion 的作用是让主控 Agent 能够操作 Windows 系统所以它会启动一个本地服务等待主控连接。如果这个服务也监听了0.0.0.0而且 Windows 防火墙放行了那别人扫到你的电脑后等同于拿到一个能执行命令的入口。配置时请务必确认绑定地址是127.0.0.1。Windows 下可以查看端口和 PID 来判断Get-NetTCPConnection -LocalPort 你配置的端口 | Select-Object LocalAddress,State,OwningProcess看到LocalAddress是127.0.0.1就没问题如果是0.0.0.0或者具体的局域网 IP赶紧改配置。我更建议Companion 不要暴露在公网主控端与 Companion 之间如果有远程需求同样走加密通道而不是直接映射端口。5.3 关于算力OpenClaw 不是只能用云端 API热词里有个问题很有代表性“openclaw 只能用接入 api 的方式使用算力吗” 完全不是。OpenClaw 支持接入本地推理引擎最常见的是 Ollama。你可以用 Ollama 跑 Qwen 这类开源模型把大模型的推理能力和 Agent 框架结合起来不需要任何云端 API Key。不过我得说实话本地模型和云端模型在工具调用、网页理解、指令遵循这些方面差距还挺明显的。OpenClaw 这类 Agent 框架的“算力消耗”不只是推理本身还包括任务拆解、工具链调用、上下文管理等开销。你想省钱省事本地模型够用想要稳定的智能体体验云端 API 依然是主流选择。两者的核心区别和建议配置我用一个表格给你总结对比项本地推理Ollama 开源模型云端 APIGPT、Claude 等成本一次性硬件投入无按量付费按 Tokens 计费用量大费用高隐私数据不出本机隐私最好请求内容上云需要信任服务商智能体能力工具调用能力偏弱复杂任务容易崩指令理解、工具选择更稳部署门槛需要本地显存或内存模型体积大只需配置良好上手简单安全风险密钥风险低但暴露端口风险仍在API Key 一旦泄露会被刷额度我不建议“为了避开 API 就盲目上本地大模型”。先评估你的 Agent 到底要干什么再定用哪种算力接入。但无论哪种前面几章说的“监听地址收敛 认证”依然适用。5.4 Skills 扩展功能越强越要管住边界OpenClaw 支持通过“Skills”给 Agent 增加新能力比如控制浏览器、读取文档、操作办公软件、发微信等等。社区里也兴起了各种各样的 Skill 包。这里我给的避坑原则很简单不装来源不明的 Skill不把 Skill 的权限扩大到你实际需要的范围之外。如果你用一个 Skill 只为了“读取某文件夹的文档”那就别让它拥有整机文件系统的读权限。如果被攻击者拿到一个带“终端执行”能力的 Agent 控制权那已经不是简单的信息泄露了相当于你的电脑直接被人发起远端指令。你可以在配置里给技能做白名单目录限制或者定期审查运行中的 Skill 列表。功能越强大越要给它装上缰绳。我个人这几年的习惯是任何服务部署完之后第一件事不是写文档而是检查“它监听在哪、谁能访问、有没有认证”。这 30 秒的检查几乎能堵住 80% 的暴露类事故。OpenClaw 这类 AI Agent 框架确实有意思但越有意思的东西越值得在上线前多花几分钟把门锁好。这次 25 万 的事件不是终点还会有类似的事情反复发生。安全这事从来不应该靠别人提醒应该靠你自己的部署清单。