网站被 AI 爬虫淹没：一个小站主的排查记录

帖子上了一百来个赞，服务器开始变慢。真正让人不安的不是慢，而是热度退去几天后，它还在继续变慢。

一、发生了什么

Sammy Straus 在 2026 年 10 月 12 日写了一篇复盘，讲他的项目 sprinklz.io——一个可以自定义规则的新闻聚合阅读器，能把某个话题（比如大模型相关的内容）从信息流里降权。大约一个月前，他把这个项目发到了 Hacker News（帖子编号 49660482），拿到一百来个 upvote。

之后站点变慢，慢到「非常难受」的程度。反常之处在于：日志里只有少数真正活跃的登录用户，服务器负载却高得离谱。他给每个 URL 路径都加了一层统计，才发现大部分请求根本没在取文章。这站是单页应用，没取文章意味着这些请求连渲染页面要用的 JavaScript 都没执行过——不是人在看。

再聚合 nginx 日志：接近一半的总流量来自同一个来源。那是一个自称「监听网站变化、把变化总结成 AI 新闻简报」的服务，实际行为是每分钟发起大量查询。他封掉了它。其余抓取者倒是规规矩矩地报了身份：Claude 的爬虫、OpenAI 的爬虫、Google 的搜索索引，还有几个别的。顺带还抓到几个漏洞扫描器，在试 /wp-content/phpinfo.php 这类路径——这站根本不是 WordPress。

他的处理是四件事：封掉最大滥用者；用 robots.txt 挡住大部分 AI 扫描器，但放行 Google 和搜索相关流量；加限流；用几周时间改底层架构，目标是能扛住真实流量。他还让 Claude 把漏洞路径挨个走了一遍、模仿扫描器的行为，确认没有信息泄露。他自己总结的教训很朴素：该让站点快起来了。

二、跟你有什么关系

有个人博客或小站、一个人维护的人。 你后台看到的「访问量」里，人的比例可能远低于直觉。这类流量最坑的地方是它不像攻击：没有洪峰、没有异常状态码，只有一个持续偏高又说不清来源的负载。等反应过来，已经慢了一个月。

做内容站的人。 被 AI 爬虫抓取不产生读者，只产生账单。它不会点广告，不会订阅，但会吃 CPU 和带宽。

依赖第三方统计工具的人。 前端统计脚本靠 JS 执行上报，恰恰漏掉这类请求。真要看底账，得回到服务器访问日志。

三、怎么判断

1. 打开访问日志，按路径聚合一次。看有多少请求落在首页或接口上，而不是具体文章页。比例高得异常，基本就不是人在读。
2. 按 UA 分组统计。主动报名的（ClaudeBot、GPTBot、Googlebot 这类）和空 UA、伪造 UA 的分开算，后者才是要处理的。名单不用记全，看的是分布形状：一个 UA 占了两成以上，就该单独查。
3. 检查 robots.txt 的分组写法。AI 爬虫一组、搜索引擎一组，别混在一条规则里——你想挡的和你想留的，通常不是同一批。
4. 先限流再封禁。按单 IP、单 UA 设速率上限，观察一周。有些「滥用」其实是配置错误的监控或 RSS 服务，一封就误伤。
5. 把静态资源和文章页分开部署。真正压垮小机器的是重复请求，不是文章本身。静态部分交给 CDN，日志会干净很多。

四、三个别信的说法

「上了热搜，流量来了就该高兴。」 这站变慢的起点确实是热搜，但它在热度过去之后还在恶化。原因是人走了、机器留下了，而机器不会累。

「装个统计代码就知道谁在访问。」 单页应用的一切都靠 JS。不执行 JS 的请求在报表里不存在，但在 CPU 曲线和账单上都在。这就是为什么「访客不多」和「服务器很卡」能同时成立。

「robots.txt 写了就会生效。」 它是一份请求，不是防火墙。守规矩的爬虫会看，最凶的那个恰恰不看。真正挡住它的是限流和封禁；robots.txt 的作用是让讲规矩的那部分别撞上来，顺带把「我不同意」这件事留个记录。

五、一句话结论

先分清人和机器，再看流量数字，否则你优化的对象根本不存在。

信息来源

• Sammy Straus, "I posted to HN, and then my website was flooded with AI BOT traffic", sammystraus.com, 2026 年 10 月 12 日：https://www.sammystraus.com/

功能与价格以官方公告为准。本文写于 2026 年 10 月 17 日。