你敢不敢把你的服务器交给 OpenClaw 管理?

人生如逆旅，我亦是行人。  —— 《临江仙·送钱穆父》 · 苏轼

上周末的时候腾讯云弹了条告警：一台轻量服务器 CPU 持续超 50%，已经持续俩小时了。

正常流程是我 SSH 上去，top、日志、配置挨个翻。但今天我直接把告警丢给了 OpenClaw，让它自己去查，因为之前已经把它 SSH 配置通了，所以这次直接用就行。

后面差不多一个小时，它自己排查、修复、加固，中间还踩了几个坑，我所做的就是在飞书上面跟它对话。

问题治理

OpenClaw 连上去扫了一圈，发现这台 4GB 的机器上同时跑着：裸装 MySQL（占 700MB 内存）、Docker 里又跑了一个 MySQL（CPU 一度 98%）、Apache 开了 10+worker 进程、还有一个 Java 服务。几个大户在抢资源。

顺带发现这台机器上的 WordPress 站点已经 500 了。它自动查 PHP 错误日志，找到根因是因为 Yoast SEO 插件三天前自动更新到了 v27.7，新代码调用了 wp_get_wp_version() 函数。但这个函数 WordPress 6.1 才引入，站点还停留在 5.9.3。函数不存在 → PHP Fatal Error → 全站挂掉。

样式修复

OpenClaw 直接禁用了 Yoast SEO，站点恢复了。但马上发现另一个问题——样式全没了。

页面能打开，但 CSS 全没加载。OpenClaw 一看 HTML，发现 CSS 链接全是 http://，而页面本身是 HTTPS。现代浏览器看到这种混合内容直接拦截。

修这个问题的时候，OpenClaw 走了不少弯路，主要还要因为之前服务器环境比较乱，也不能怪它🥹。

OpenClaw 一直在改 /etc/nginx/nginx.conf，加 X-Forwarded-Proto 头。改完重启，没效果。反复折腾了几轮才发现——服务器上实际跑的根本不是这个 Nginx。

这台机器上我之前装过两个 Nginx：yum 装了一个（没在运行），另一个是手动编译的放在 /usr/local/nginx/ 下面（实际在跑的）。OpenClaw 一直在改没在用的那个配置文件。

这个现象我是知道的，但是它不知道，直到我提醒了它，让它看一下服务器上 Nginx 的情况，它才发现。

发现这个问题后，OpenClaw 改了正确的配置文件，问题解决了。随后也让它把那个没在用的 yumNginx 卸载了，然后建了个软链统一入口。这样以后不管敲什么命令，都不会再搞错。

顺便 OpenClaw 也给 Docker 容器的日志加了大小限制，避免 MySQL 的兼容性警告无限膨胀。

修完服务器 1 之后，我又让它把另外两台服务器也巡检了一遍，整理出了完整的资产清单。结果发现几个之前没注意到的问题：

• 服务器 2：Docker 镜像占了 16.45GB，65% 可以回收，2GB 内存的机器 Swap 已经快满了
• 服务器 3：SSH 有 8396 次暴力登录失败记录，没有任何防护，firewalld 没开，fail2ban 也没装
• 服务器 1（今天修的这台）：10+ 个已停止的 Docker 容器一直没清理

最后 OpenClaw 给服务器 3 装上了 fail2ban，配置了 3 次失败封 24 小时的规则。

整个过程大概一个小时，如果是我自己做，时间肯定不止一个小时，有了 OpenClaw 快了很多！

几个感受

OpenClaw 做运维排查，最大的价值不是快，是不会漏。人看到 CPU 高了就去查 CPU，看到 500 就去查 PHP。但 OpenClaw 会顺手把端口、进程、容器、cron、systemd failed service 全扫一遍。很多隐患就是这么翻出来的。

另外 OpenClaw 不怕麻烦。像“清理已停止的 Docker 容器”这种活儿，人通常觉得太琐碎了懒得干。但 OpenClaw 会老老实实查出来列给你，等你拍板。而运维里往往就是这些没人干的小事，最后攒成大故障。

OpenClaw 也会踩坑——改错 Nginx 配置文件这种错误挺不应该的。但踩完之后 OpenClaw 自己把经验写进了文档，还总结了操作规范。下次碰到类似场景，不会重蹈覆辙。

当然不是什么都不需要人管了，有些决定还是得我来拍——比如要不要彻底关掉密码登录、哪些已停的容器可以删、要不要升级内核，OpenClaw 负责排查和执行，人负责决策，这个分工比较舒服。

总的来说，这次体验下来，用 OpenClaw 做日常运维治理是可行的。它不能替代人，但当一个“第一响应者”挺好——告警来了先让 OpenClaw 查，快速定位问题、执行修复、输出报告，关键节点你来做决定就行。