吐槽：记录一次站点被Meta爬虫刷掉400G流量的排查过程

最近几天频繁收到云服务商的流量报警。一开始以为是服务器被爆破或者遭遇了恶意 CC 攻击，登进服务器排查了一圈，发现事情并没有那么复杂，甚至有点无语。

简单记录一下排查过程。

1. 定位异常进程

连上 SSH 后，首先用 nethogs 看了下网卡的实时流量，发现有一个 unknown TCP 的接收流量异常高，大概占了 2MB/s。

因为服务器上用 1Panel 跑了不少 Docker 容器，这种显示往往意味着是某个容器在大量消耗网络资源。接着直接用 docker stats 挨个查看容器状态。

果然揪出了真凶：跑 WordPress 的 php7 容器，网络 I/O 的接收量直接飙到了 400 多 G，而其他容器只有几十 MB。

2. 分析访问日志

定位到容器后，去看了眼对应网站 Nginx 的 access.log。发现满屏都是来自 57.141.14.xxx 这个爱尔兰 IP 段的高并发请求。

看了一下请求头里的 User-Agent：

搞半天不是黑客，而是 Facebook (Meta) 官方的网络爬虫。

3. 原因排查：经典的“蜘蛛陷阱”

按理说正规大厂的爬虫会有抓取频率限制，不至于把流量刷到这份上。仔细分析了日志里请求的 URL，发现全都是类似这样的链接：

熟悉 WordPress 的朋友应该知道，这是 WP 评论回复自带的动态链接。因为它的参数可以无限组合，在站长圈里属于经典的“蜘蛛陷阱”。普通的搜索引擎（像 Google、百度）遇到这种特征通常会自动跳过，但 Meta 这个爬虫显然没有做这种优化，顺着链接一路往下爬，陷入了死循环。

最致命的是，这种带参数的动态请求是不走静态缓存的。它每请求一次，PHP 就要被迫去查询 MySQL 并重新渲染一次网页。并发一高，不仅耗费 CPU，渲染出的大量 HTML 页面也把带宽彻底吃光了。

4. 解决方案

既然查明了原因，处理起来就很简单了，直接在 1Panel 的 WAF 规则里做拦截：

规则生效后，这些非正常的请求在 Nginx 层面就被直接丢弃了，只会返回一个只有几百字节的 403 页面，不再穿透到后端的 PHP 和数据库。

观察了一会儿流量监控，曲线终于平稳了。

小结

现在各大科技公司都在疯狂抓取数据训练 AI，市面上各种无脑爬虫只会越来越多。各位维护个人博客或站点的朋友，如果遇到莫名其妙的流量飙升或 CPU 满载，不妨先看看 access 日志，说不定就是哪个大厂的爬虫在疯狂薅你的服务器资源。

PS：好你个扎克伯格，背地里净干这种事，我看你也不像好人！