我的个站被黑之后，我是如何一步步救回来的…

这不是什么专业安全专家的复盘报告，只是简单做一下真实记录。如果你的站也突然卡死、CPU爆表、后台进不去——这篇也许能帮你少走点弯路。

噩梦的开始：网站突然打不开了
那是再普通不过的下午，我像往常一样打开自己的小站，想看看今天的订单数据。结果浏览器转了半天，最后给我一个大白屏。想上宝塔看一下资源占用情况，结果连宝塔都进不去了。

我以为只是网络波动，刷新了几次——还是打不开。

前几日陆续有收到宝塔面板的资源告警，CPU占用超180%，我只当是有人在攻击没当回事，现在直接网站打不开，我都没往攻击 方面想，想着是不是有突发流量了。但是宝塔实在进不去，只能登上aliyun找我的ecs，咱也不费话，直接给它重启了。

重启之后趁请求还没上来，赶紧登上宝塔，上去一看心凉了半截：CPU 100%，负载也是飙到 100% 以上（我只有2核啊），内存几乎被吃光，Swap 都用了 1 个 G。整个服务器像老牛拉破车，SSH 敲个 top 都要等好几秒才能看到结果。

当时我的第一反应是：完了，是不是被 CC 攻击了？

第一轮排查：找到那个“祸害”
我赶紧连上 SSH，用 top -bn1 | head -10 看了一眼。果然，好几个 php-fpm 进程把 CPU 抢得死死的，单个进程能冲到 90% 以上。

再看进程列表，mysqld 也占了 30%+ 的 CPU。这不对劲——平时我的站访问量不大，数据库不可能这么高。

我翻了翻 PHP 慢日志，发现几个可疑的脚本：/user/cun/randsk.php、/order/admin.php，执行时间动不动就是 30 多秒。其中 randsk.php 卡在了 curl_exec() 上，像是在疯狂请求某个外部接口。

然后看 MySQL 慢查询，更是触目惊心——一个简单的 SELECT 查 charge_record 表，每次要扫 3.5 万行，耗时 3~8 秒。三万多行的表，连个联合索引都没建，也难怪数据库撑不住。

我当时还在想：是不是代码写得烂，优化一下就好了？/user/cun/randsk.php这是个网盘项目的历史文件，找deepseek把bug调整了一下，/order/admin.php是另一个项目的管理员文件，页面里面用了all.main.css的样式，但是用的是cloudflare.com的资源，国内没有cdn，以及管理员的首页调用了几个查余额和查数据库的接口，于是把cloudflare.com的样式资源单独下载下来放到了阿里云上，把几个耗时的mysql查询操作也都做了索引和缓存，一通操作之后，感觉速度是好了一点，过了一会儿一看，好家伙资源又飙到100%去了，难道真是用户访问量大了？看百度统计上UV和PV变化也不明显，实在让我百思不得其解。

直到我无意中列了一下根目录的文件……

发现入侵：有人在我站里“安了家”
ls -la 一看，多了两个从没见过的目录：/ca044/ 和 /cb7ceb/。

点进去一看，里面全是加密混淆过的 PHP 代码。其中 /cb7ceb/index.php 打开后，竟然是一个完整的WebShell 管理界面，标题写着 “MARIJUANA”——界面里还有文件管理、上传下载、执行命令、改权限……整套工具齐活。

再往下翻，/wp-includes/br1c7873/ 里也藏了后门，还有个 03d 二进制文件，不知道是啥，但肯定不是什么好东西。

那一刻我才意识到——我的站早就被人攻破了，攻击者在我服务器上“安了家”，随时可以进进出出。

更大的打击是，wp-admin 和 wp-login.php 都打不开了，全返回 404。检查 .htaccess 才发现被篡改了，里面加了一大堆 Deny from all 规则，把后台入口全堵死了，只放行了攻击者自己需要的几个文件名。

整个人当时就头皮发麻。

紧急抢修：与时间赛跑
冷静下来后，我开始一步步收拾烂摊子。

第一步：恢复 .htaccess，拿回后台入口
我直接把 .htaccess 覆盖成 WordPress 默认的重写规则：

text
# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress
然后刷新后台，终于能看到登录页了——虽然 wp-login.php 文件已经被删了，还得从官方包重新上传一份。

第二步：扫除后门，清理战场
我像拆炸弹一样，把所有可疑目录直接删除：

text
rm -rf /ca044 /cb7ceb /wp-includes/br1c7873
rm -f /test.php /baker.php /tongyi/filetrans.php
rm -rf /wp-content/plugins/e6e0f4536ac4c7ca7605481aa5968173
然后进数据库，检查 wp_users 表，果然多了一堆不认识的管理员账号，足足有20个，直接顺手删掉。紧接着把所有密码（数据库、FTP、WordPress 管理员）全部更换。

第三步：重装 WordPress，但保留数据
虽然删了后门，但我还是不放心——谁知道还有没有藏得更深的？决定彻底重装 WordPress，但保留数据库和 uploads 目录。

过程很简单：备份数据库和主题、插件、上传文件 → 删除旧的 WordPress 文件 → 上传最新官方包 → 恢复数据库 → 重新安装主题和插件（全部从官方源下载，不用旧压缩包）。

折腾了大半天，站终于能打开了，后台也能进了——但新的问题来了。

重装后的新坑：固定链接全变 404
我满心欢喜点开一篇老文章，结果直接 404。

试了试默认的 ?p=123 格式能打开，但自定义的 /%category%/%post_id%.html 就不行。到后台“设置→固定链接”里点“保存更改”也没用。

后来才反应过来：我用的是 Nginx，它不认 .htaccess 啊！宝塔面板里的“伪静态”设置才是真正管用的地方。

我赶紧在宝塔的“伪静态”里填入：

text
location / {
try_files $uri $uri/ /index.php?$args;
}
rewrite /wp-admin$ $scheme://$host$uri/ permanent;
保存，重载 Nginx，再到后台点一次“保存更改”——文章终于能正常打开了。那一声“啪”的打开声，简直比音乐还好听。

亡羊补牢：给站上一道道锁
站是救回来了，但这么被整一次，心有余悸。我开始疯狂做安全加固，把能想到的防御手段全加上。

1. Nginx 层面先拦住一批
先在 Nginx 配置里把 /xmlrpc.php 直接禁用——这东西就是攻击者的最爱，暴力破解、DDoS 全走它。

text
location = /xmlrpc.php {
deny all;
}
然后把 uploads 目录执行 PHP 的权限也封死：

text
location ~* /(?:uploads|files)/.*\.php$ {
deny all;
}
再屏蔽掉 .git、.env、备份文件等敏感文件，免得被扫到。另外还加了速率限制，一个 IP 每秒最多 10 个请求，超了就等着吧。

2. 给后台登录加“第二道门”
我在宝塔里给 wp-login.php 加了个 BasicAuth 认证——也就是说，想进后台，先要输一个 HTTP 密码（和 WordPress 密码分开），相当于小区大门再配个门禁卡。这样就算攻击者知道了我的 WP 密码，也过不了这关。

3. 装上 Wordfence 这个“保镖”
Wordfence 这个插件确实是神器。我开启了它的 Web 防火墙、恶意扫描、登录限制，还在 “立即屏蔽访问这些 URL 的 IP” 里填了一串攻击者常扫的路径：

text
/xmlrpc.php
/wp-json/batch/v1
/products/*
/shopdetail/*
/.well-known/*
只要哪个 IP 敢碰这些路径，立马拉黑，连商量的余地都没有。

4. 自动封禁 + 备用防火墙
宝塔自带 Fail2ban，我也配置上了——谁在 10 分钟内触发 3 次 Nginx 的 403 错误，直接关小黑屋 24 小时。另外还装了宝塔的 Nginx 防火墙，CC 防护、SQL 注入防护全开，让攻击者连漏洞都摸不到。

5. WordPress 内部加固
把默认管理员 admin 改成了一串随机字母，删除旧账号；

修改数据库表前缀，从 wp_ 改成 xxx_；

在 wp-config.php 里加上 define('DISALLOW_FILE_EDIT', true);，防止攻击者进后台改主题文件；

给管理员账号绑定了 Google 身份验证器（2FA），现在登录要输手机上的动态码。

最后还做了每日自动备份，文件+数据库全量，存到远程 FTP，以防万一。

现在的状态：总算能睡个安稳觉了
折腾了大半天，站总算是稳住了。

现在看宝塔面板，CPU 长年在 10%~20%，负载不到 1，攻击请求全被 Nginx 或者 Wordfence 挡在外面。偶尔有新的扫描 IP 上来，Wordfence 或者 Fail2ban 也会自动收拾它。

所以别以为自己的站小就没人盯——自动化扫描工具满网都是，只要你的站有漏洞，迟早被扫到。

备份是命根子——这次要不是有数据库备份，真不知道要怎么恢复。

安全是叠加的——Nginx 拦截、WAF、插件、2FA、密码强度，每层都加一点，攻击成本就高一大截。

出了事别慌——按顺序来：先找后门、堵入口、恢复访问、再加固，一步步走，总能解决。

如果你也正在经历站点卡死、CPU 爆表、后台进不去……先深呼吸，别急着删文件。

登录 SSH 看看 top，翻翻 PHP 慢日志和 MySQL 慢查询，再检查一下有没有陌生的 PHP 文件。大概率能找到问题所在。

剩下的就是耐心——备份、清理、重装、加固，一个环节都别省。

没错，这个文章用了AI辅助完成，现在真的万物皆AI了，攻击者也全是AI上的狠活，这年头还有人写博客不稀奇，还有人攻击小站呢。