发了一篇文章到HN，网站被AI爬虫淹了

一次意外走红引发的流量危机

Sammy Straus 花了几年时间开发了一款名为 sprinklz.io 的可定制订阅阅读器，核心功能之一是让用户降低特定话题在信息流中的优先级。一个月前，他把这个项目发到了 Hacker News，获得了约一百个 upvote——考虑到 HN 用户对 LLM 话题已经审美疲劳，这个工具恰好切中了痛点，反响不错。

然而，流量洪峰来得比预期猛烈得多。网站开始变得极其缓慢，而且在帖子热度消退几天后，负载不降反升。Sammy 记录的指标也很反常：登录活跃用户只有个位数，服务器却处于极高负载状态。

问题出在哪里？

他首先给每个端点加了顶层请求日志，结果发现一个令人震惊的事实：大部分请求根本没有尝试获取新闻内容。作为一个单页应用（SPA），这些请求连渲染页面所需的 JavaScript 都没有执行——它们只是反复地、机械地抓取同一个 URL。

进一步分析 NGINX 聚合日志后，真相浮出水面：

• 近一半流量来自同一个用户：Sammy 查到对方自称是一个「监听网站变更并生成 AI 新闻摘要」的服务，以每分钟多次的频率查询网站。
• 其余流量包含常见的已知爬虫：Claude bot、OpenAI bot、Google 搜索索引器等。
• 甚至还混进了几个漏洞扫描器，尝试访问 /wp-content/phpinfo.php（而他的网站根本不是 WordPress 架构）。

采取了哪些防护措施？

面对这波 AI 流量冲击，Sammy 做了以下应对：

1. 添加 robots.txt：阻止大部分 AI 爬虫，但保留 Google Bot 等搜索引擎的抓取权限。
2. 设置合理的速率限制：防止单个来源的过度请求拖垮服务器。
3. 主动验证安全性：他让 Claude 模拟扫描器尝试访问各种漏洞路径，确认网站没有泄露敏感信息。

最关键的教训：让网站更快

Sammy 认为，最核心的改进方向不是单纯地「挡流量」，而是提升基础设施的性能和扩展能力。他希望网站能够从容应对真实用户的并发请求，即使在重负载下也能保持稳定。过去几周他已经在底层架构上做了不少优化，预计会带来显著的性能提升。

对小站开发者的实用建议

这个案例给独立开发者和小团队带来几点值得参考的经验：

• 日志先行：给关键端点加上请求计数日志，能帮你快速定位异常流量来源，而不是盲目猜测。
• 区分真实用户和爬虫：SPA 架构下，真正的用户会执行 JavaScript 并发起后续 API 请求，而爬虫往往只重复请求同一个入口 URL——这是很好的区分信号。
• robots.txt 不是银弹：它能劝退守规矩的爬虫，但对恶意扫描器和无视规则的 AI 服务无效，必须配合速率限制。
• 主动测试安全边界：利用 AI 工具模拟攻击者视角，验证网站是否存在信息泄露风险，比被动等待安全报告更靠谱。
• 投资性能而非仅靠防御：与其把所有精力放在封锁流量上，不如让基础设施本身具备更强的抗压能力——这对真实用户体验同样重要。

Sammy 的 sprinklz.io 目前完全免费开放使用，感兴趣的开发者可以前往 sprinklz.io 体验。