sprinklz.io 在 Hacker News 帖子后遭遇 AI 机器人洪流：发生了什么以及开发者如何防御他们的网站

一篇关于小型 feed 阅读器项目的 Hacker News 帖子获得了大约 100 个赞，随后网站被机器人流量淹没，几乎所有请求中近一半来自一个 AI 新闻通讯爬虫。这一事件由网站作者记录，并被 174 位评论者讨论，表明在 HN 上的公开曝光现在可靠地会触发一波自动化流量，这波流量往往比伴随的人类受众还要大。

简版

Sammy Straus 将 sprinklz.io（一个可自定义的 feed 阅读器，可以降低 LLMs 等主题的优先级）发布到了 Hacker News。帖子获得了“大约一百个赞”。几天后，网站仍然很慢——而且越来越慢——尽管只有少数真正活跃的、已登录的用户。

“我的网站变慢了。真的，非常痛苦地慢。起初我把它归因于突然热门帖子的额外关注……但奇怪的是，慢的问题持续存在，甚至在我帖子发布几天后开始变得更糟，而我记录的指标也没有意义。”

原因不是 HN 的受众。是自动化流量，而且其中一个违规者占据了主导地位。

诊断线索：大多数请求从未运行 JavaScript

sprinklz.io 是一个单页应用，所以真实的页面浏览需要浏览器获取并执行 JavaScript。当作者为每个端点添加了顶级日志时，模式变得一目了然：大多数请求根本没有尝试获取新闻文章。

“大多数请求甚至没有运行渲染页面所需的 JavaScript (!)。”

这一信号将人类访客与爬虫区分开来。浏览器加载页面时会请求文档，然后是 CSS、JavaScript 和 favicon 资源。而只想要文本的爬虫往往只请求文档，其他什么都不请求。评论者 dhosek 描述了正是使用这种启发式方法：

“非常有用的是能够通过请求模式（例如，加载页面时不请求 CSS/JS/favicon）识别‘隐身’机器人流量。”

近一半流量来自一个 AI 新闻通讯爬虫

聚合 NGINX 日志以查找滥用者，作者发现近一半的流量来自单一来源：一项监控网站变化并将其总结为 AI 生成的新闻通讯的服务。它每分钟查询网站多次。作者屏蔽了它，但拒绝透露其名称。

评论者对这种克制提出了反对意见。Havoc 写道：

“这种行为值得点名批评。不体贴的劣质服务不配得到保护其名称的礼貌。”

andai 质疑了爬虫自身的逻辑：“听起来他们每秒进行多次请求，所以这不可能是他们”想要新鲜内容的原因。

命名爬虫和漏洞扫描器构成了剩余流量

剩余流量是已识别爬虫和攻击者的混合体。作者列出了 ClaudeBot、OpenAI 的机器人、Google 的搜索索引器，以及“其他几个”，还有探测诸如 /wp-content/phpinfo.php 路径的漏洞扫描器——而该网站并不是 WordPress。

drnick1 确认这种噪音是常规现象：“这很正常，我每天在日志中看到成百上千这样的请求。”

switz 描述了屏蔽整个云 ASN——AWS、Google Cloud、Azure、Alibaba Cloud、Oracle——并报告说两年前对 Alibaba Cloud 的禁令至今仍每天产生大约一百万次针对一个域的请求，所有这些请求都返回 4xx 响应。同一评论者指出，Apple“在过去几个月大幅增加了其爬取活动，但幸运的是他们确实尊重 robots.txt”，并且一些 AI 爬虫现在通过住宅 IP 僵尸网络路由以逃避检测。

作者应用的缓解措施

作者的反应结合了访问控制和性能工作：

• 添加了 robots.txt，阻止大多数 AI 扫描器，同时允许 Googlebot 和其他搜索相关流量。
• 添加了合理的速率限制。
• 使用 Claude 查询漏洞路径并模仿扫描器，以验证没有内容泄露。
• 开始了实质性的基础设施改进，以便网站能够处理高查询每秒负载。

“然而，最重要的教训是，是时候让我的网站更快了。我想成为那个能够处理 xxx QPS 真实流量的网站。”

即使没有点赞，HN 曝光也是机器人磁铁

多位评论者报告了从未上首页的帖子也遭到同样的洪流。Twiin 写道，一个“完全没有点赞和零评论”的提交仍然“遭到疯狂的机器人流量”，而 HN 是该链接唯一发布的地方。

Jaxan 直白地总结了触发条件：“哦，一旦你为子域添加了 TLS，机器人就来了。瞬间的事。” nubinetwork 报告称，在完全没有网页内容的域名上也收到了类似 LLM 的流量：“如今仅存在就会让你被扫描。”

firefoxd 描述了相反的效果——公开撰写关于机器人防御技术（zipbombs）使问题变得更糟：“它在网上超级传播，我后悔了。我的服务器完全被机器人流量淹没。”

机器人流量产生真实账单和宕机

几位评论者量化了成本。QueensGambit 报告称，单月 Google Cloud 账单为 10,000 美元，归因于 ClaudeBot，推测用户试图用编码代理和浏览器插件复制他们的软件。pampas 表示，一款维基百科镜像游戏 redactle.net 产生了大额云出口账单，因为机器人击穿了每个页面并降低了缓存命中率。trinsic2 说他们的网站“因为流量关闭了一段时间。”

layerv-ai 指出了复合风险：在 HN 和 Twitter 上营销项目可能使 Vercel 账单“因机器人把网站抓碎而飙升，即使有 CF 的机器人保护也是如此。”

开发者实际运行的防御措施

评论者描述了各种对策，但没有共识赢家：

• 挑战页面。 8by3 构建了一个名为 Sphinx 的 Elixir 版 Anubis，并报告称“超过 80% 的流量是未能通过挑战的机器人，即使白名单了合法爬虫。” paaloeye 建议使用 Cloudflare Turnstile。
• 蜜罐。 robotmay 构建了一个自定义 L7 代理，它以客户端愿意接受数据包的速度尽可能慢地提供请求，在两台小型 Hetzner VM 上困住了约 3,000 个并发爬虫。“当我只是拒绝请求时，他们反过来更加猛烈地攻击我的服务器。”
• 封锁列表。 pmlnr 推荐了 abuseipdb blocklist。minimaxa 说他们的团队屏蔽整个 IP 范围，并发布了一个名为 Vorwatch 的免费工具。
• 基本认证。 goodthink 锁定了除首页之外的所有内容，并将凭据放在那里，从而停止了资源抓取。
• 限流优先于屏蔽。 mboyd1 说他们只硬屏蔽了 Lightpanda 用户代理，否则更倾向于限流，因为代理流量可以转化为高级 API 升级销售。
• 放弃并优化。 timpera 尝试了 Cloudflare、Anubis 和 fail2ban，然后得出结论：“你根本无法赢得这场军备竞赛。所以我转而改善服务器性能，并服务每一个请求。”

并非所有机器人流量都无价值

讨论中包括了与全面封锁相反的明确观点。beybol 区分了索引爬虫和用户触发的抓取：

“OAI-SearchBot/GPTBot/ClaudeBot 只是索引，但 ChatGPT-User/Claude-User 等可能是由用户与 LLM 对话产生的有价值流量。所以值得选择屏蔽哪些，而不是全部屏蔽。”

mboyd1 从商业角度提出了同样的论点，更希望代理“将我的应用视为有用的资源，并为希望更大速率限制的代理开发者驱动潜在的高级 API 升级销售。”

架构教训：SPA 和可缓存性

重复最多的技术批评针对的是网站架构而非机器人。est 简单写道：“我的网站是单页应用。就这样。放弃它。让你们的页面尽可能可缓存。” mediumsmart 指出，Google Lighthouse 和 PageSpeed Insights 是得出同样结论的起点。

静态、可缓存的页面吸收机器人洪流的成本远低于必须每次请求执行 JavaScript 的 SPA。作者自己的结论——网站需要处理高 QPS——是从另一个方向看到的同一修复方案。

实用要点

1. 记录每个端点的请求数。 此次事件中最有用的信号是大多数请求从未获取真实用户会获取的内容。
2. 检查客户端是否请求 CSS、JavaScript 和 favicon。 跳过这些的爬虫几乎肯定不是浏览器。
3. 在假设流量激增是人类之前，按来源聚合日志。 该网站近一半的负载来自一项服务。
4. 在屏蔽之前，将索引爬虫与用户触发的抓取区分开。 搜索机器人和代表用户请求的代理具有不同的价值。
5. 即使零互动，也要预期公开链接带来的流量。 多位评论者报告了没有点赞的帖子也遭到洪流。
6. 为出口流量和计算预算，而不仅仅是带宽。 机器人洪流已为小型项目产生了四位数和五位数的云账单。
7. 优先考虑可缓存、静态提供的页面。 抵御爬虫洪流最便宜的防御是几乎没有服务成本的页面。

总结：

在关于 sprinklz.io 的 Hacker News 帖子获得大约 100 个赞后，该网站变得极其缓慢，因为近一半流量来自一个 AI 新闻通讯爬虫，以及命名爬虫和漏洞扫描器——开发者表示，这种模式现在会打击任何公开链接的网站，即使是零点赞的帖子。

标题：

sprinklz.io 在 Hacker News 帖子后遭遇 AI 机器人洪流：发生了什么以及开发者如何防御他们的网站