五年零宕机记录遭终结！开发者怒吼：“疯狂的爬虫毁了我的周末”

编译 | 苏宓

出品 | CSDN（ID：CSDNnews）

爬虫的肆虐，时不时就能把一个个人博客“爬”到宕机。最近，这事儿就让 Bear Blog 的作者 Herman Martinus 亲身体验了一次。

这个以“极简、无广告、注重隐私”著称的博客平台——Bear，在 10 月 25 日经历了自上线五年以来的首次重大宕机。

具体原因是负责处理自定义域名的反向代理服务出了问题，导致所有自定义域名请求超时。更糟糕的是，监控工具没能及时报警，而那天偏偏是周六，Herman 直到过了好一阵才发现问题。

事后，他在博客上写下了一篇长文，既是复盘，也是反思。从根源来看，这次事故与一个老问题密切相关——互联网爬虫的疯狂增长。

三种“爬虫”横行

Herman 提到，今年早些时候他也写过一篇《The Great Scrape》（伟大的爬取行动）的博文，探讨时下互联网几乎被机器人流量占据的现实。如今的网络，公开资源正变得越来越“危险”，因为各种自动化爬虫正在无孔不入地抓取数据。

他将这些爬虫分成三类：

• AI 爬虫：用于抓取数据训练大语言模型（LLM）的机器人。

• 恶意爬虫：不断扫描网站漏洞、搜寻泄露文件的攻击型脚本。

• 未受控的自动化脚本：由普通用户随手生成的“玩具爬虫”，无意间造成大规模压力。

第一类大家已经听说得很多了——现在数据有了新的价值，因为它能用来训练大语言模型（LLM）。既然有经济利益驱动，那就一定会有人去爬。它们几乎已经“榨干”了互联网上所有人类创作的文字内容，如今正贪婪地寻找新的“内容水源”。对此，有人把这种现象比作寻找“低辐射钢”（low-background-radiation steel），这个比喻本身也挺有意思。

不过，这类爬虫其实是最容易应对的，因为它们通常会主动表明身份，比如标注自己是 ChatGPT、Anthropic 或 XAI 等来源。它们也常会说明访问目的，是用户发起的搜索请求（比如当你在 ChatGPT 中查询时，它为你检索网页），还是用于数据挖掘（也就是训练模型的数据采集）。

在 Bear Blog 配置上，Herman 允许前者，因为博客作者希望被搜索到；但他会拦截后者，因为他们通常不希望自己的文章被拿去训练下一个“大模型”。

相较之下，后两类爬虫就没那么温和了。恶意爬虫是一种会系统性地反复抓取网站的机器人——有时每隔几分钟就执行一次，专门在寻找各种漏洞，比如配置错误的 WordPress 实例、泄露的 .env 或 .aws 文件等等。

如今，自行托管（self-hosting）比以往任何时候都更危险，因为配置上的一个小失误就可能被发现并利用。Herman 称，在过去 24 小时里，自己在几百个博客上共拦截了近 200 万次恶意请求。

更离谱的是，这些爬虫在运行过程中会轮换使用上千个 IP 地址，这也让 Herman 怀疑它们其实是通过手机应用进行流量隧道转发的——因为它们的 ASN（自治系统号）大多来自蜂窝网络。

虽然这还只是猜测，但他认为某些应用开发者可能发现了新的“变现方式”：免费发布应用，但把设备的网络隧道访问权限卖给爬虫。

除了 AI 爬虫和恶意爬虫之外，还有一类让网站主们头疼的“隐形威胁”——未受控的自动化脚本（unchecked automations）。

Herman Martinus 把这类爬虫称作“Vibe 编程的产物”：任何人只要在 AI 工具里敲上一句提示语，就能生成一个能正常运行的爬虫脚本，然后放在家里的电脑上 24 小时抓取网页。听起来像小玩具，但数量一多，就成了灾难。

过去几个月里，这样的爬虫成千上万地冒出来，频繁“误伤”网站，导致轻度 DDoS（分布式拒绝服务）事件一波接一波。毕竟现在的家用电脑性能早已超过许多 VPS，一台设备就能在无意间造成不小的破坏。

为了应对这些“野生脚本”，Herman 采取了一系列措施：利用Cloudflare 的 WAF（Web 应用防火墙）规则和限速策略拦截异常请求，再加上他自己写的识别逻辑，通过行为模式自动隔离恶意爬虫。

他还尝试过一些更“创意”的防御手段。比如用（压缩炸弹）反击爬虫——虽然解气，但存在误伤正常用户的风险；或者让爬虫通过工作量证明（Proof of Work）验证，用算力成本来“劝退”它们；甚至直接给它们返回无穷无尽的垃圾数据，让机器人忙得停不下来。

最终他放弃了这些复杂方案，因为这两种方式虽有趣，但归根结底，它们的效果和直接封禁请求差不多，却让系统更复杂。

周六的一场 DDoS 攻击，让运行了 5 年的网站瞬时宕机

不过这些背景只是铺垫，真正压垮 Bear 博客平台的，是 10 月 25 日那场突如其来的DDoS 攻击。

过去，页面请求的主要瓶颈在 Web 服务器本身，因为它承担了最重的计算负载。系统会根据需要自动进行水平扩展，最多可扩展到 10 倍容量。但爬虫流量往往能暴增到远超这个量级的规模，因此需要强力的爬虫检测与防护机制，同时把高频请求的端点交给 CDN 来处理。

在周六早晨，数百个博客遭到了 DDoS 攻击——每分钟收到数以万计的页面请求（从日志上看，很难判断这些请求是恶意攻击还是过于激进的爬虫行为）。前面提到的防护措施总体运行正常，但问题出在反向代理——它位于大多数防护层的上游，最终因请求过载而“顶不住了”，自己直接“打了个盹”。

监控图上，那个巨大的蓝色峰值就是压垮服务器的那一下——它大到让整张图的其他波动看起来像一条直线。

要知道，这台服务器在此前已经连续稳定运行了整整五年了，从未宕机过，直到这次。

更让人哭笑不得的是，Herman 设置的在线监控工具竟然没发出任何警报。通知功能早就打开了，他甚至设了“关键警报”模式（那种半夜能把人吵醒的级别），可这次却毫无动静。

他事后多次排查，排除了配置错误，但始终没找到原因。

反爬虫措施升级！

在复盘这次事故后，Herman 制定了一整套改进方案：

• 监控冗余：新增第二套监控系统，一旦宕机，会通过电话、短信、邮件同时提醒。

• 更激进的限速与防护：在反向代理层提前过滤异常流量，服务器负载因此减少近一半。

• 扩大反向代理规模：处理能力提升到原来的五倍。“有点过头，但算力便宜——我已经秃了，不想更秃。”他打趣道。

• 自动重启机制：若带宽连续两分钟降为零，系统会自动重启。

• 上线状态页：新建 status.bearblog.dev，实时展示服务运行状态。

Herman 相信这些措施足以让 Bear 再度平稳运行。他也在文末邀请其他开发者交流防爬虫经验：“如今公共互联网的大部分流量都来自机器人，网络环境比以往更恶劣，但正因为如此，我们更需要守护那些让互联网值得停留的角落。”

最后，他留下一句意味深长的总结——

“这场军备竞赛，还远没有结束。”

那么，你做过哪些反爬虫的抵御措施？欢迎分享你的看法。

来源：https://herman.bearblog.dev/agressive-bots/