7.0
热点
AI SCORE
技术实践2025-04-15 07:33
LLM 爬虫导致的云服务成本激增分析
Hacker News · metacast.app#成本优化#Vercel#云服务
Editor brief · 编辑速览
分析 AI 模型训练爬虫对网站基础设施成本的冲击，揭示 Vercel 图片 API 的意外高额账单问题，对云部署开发者有警示和优化价值。
一次错误配置，可能让我们损失 7,000 美元
步骤 1：成本激增
步骤 2：Image Optimization API 使用量激增
步骤 3：LLM bot 发起数万次请求
步骤 1：先止血
步骤 2：禁用 Image Optimization
步骤 3：robots.txt
LLM bot 的 User Agent
搜索引擎爬虫的 User Agent
SEO bot 的 User Agent
LLM bot 的 User Agent
搜索引擎爬虫的 User Agent
SEO bot 的 User Agent
继续使用敏感的支出上限
应对规模的思维方式
做好防御准备
2025 年 2 月 7 日，星期五，我们托管在 Vercel 上的 Next.js Web 应用发生了一起事故。如果没有及时发现，这次事故可能会让我们损失 7,000 美元。
当时，来自 Amazonbot、Claudebot、Meta 和一个未知 bot 的 LLM bot 流量突然激增。它们在一天之内总共向我们的网站发送了 6.65 万次请求。bot 抓取了数千张使用 Vercel Image Optimization API 的图片，而这项服务每优化 1,000 张图片要收费 5 美元。
我们自身的错误配置，再叠加 bot 激进的抓取流量，让我们这家规模很小、完全依靠自身资金运营的创业公司陷入了巨大的经济风险。
Metacast 是一家播客技术创业公司。我们的主要产品是一款面向 iOS 和 Android 的播客应用。
平台上的每一期播客节目，在我们的 Web 应用中都有一个对应页面。平台大约收录了 140 万期节目，这意味着我们有 140 万个可被爬虫发现的网页。这些页面会在收到请求时通过服务端生成，之后再被缓存。
首先，我们收到了 Vercel 发来的成本告警，提示按用量计费的资源支出已经达到预算的 50%。
我们进一步调查后发现，成本主要来自 Image Optimization API，其使用量在 2 月 7 日达到峰值。
播客目录中的每个页面都有一张播客封面图片，源图片的尺寸为 3000×3000px。经过 Image Optimization 处理后，播客封面的大小会缩减至原来的十分之一，然后被缓存。Image Optimization 让 Web 应用的响应非常迅速，一直以来都很好用——直到我们发现，它的成本高得吓人。
Vercel 每优化 1,000 张图片收费 5 美元。随着数以千计的请求涌入，我们的成本以每 1,000 次图片请求 5 美元的速度不断累积。最坏的情况下，如果全部 140 万张图片都被爬取，那么理论上，我们将收到一张来自 Vercel 的 7,000 美元账单。
我们在 Vercel 的 Firewall 中检查了请求的 User Agent，发现了 Amazonbot、ClaudeBot、meta_externalagent，以及一个把自己伪装成浏览器的未知 bot。
我们无法断言具体是哪些 bot 下载了图片，因为我们使用的是 Vercel Pro 套餐，现在已经无法访问星期五的日志。我们唯一能确定的是，这些请求来自 bot 流量。
我们两人都曾在 AWS 工作，并在那里把事故恢复的黄金法则刻进了脑子：先止血，再做长期修复。
我们在 Vercel 中配置了 Firewall 规则，屏蔽来自 Amazon、Anthropic、OpenAI 和 Meta 的 bot。公平地说，OpenAI 并没有爬取我们的网站，但出于预防考虑，我们还是把它屏蔽了。
首先，我们在 Next.js 中为播客图片添加 unoptimized 属性，禁用了图像优化。我们的判断是，用户访问页面时会拿到最新版本，其中使用的是未优化的图片。
但我们没有考虑到：
bot 已经抓取了数千个页面，之后仍会使用它们从“旧版”HTML 中提取出的 URL，继续抓取经过优化的图片。
我们的网站对所有外部 host 都启用了图像优化。
后一点是整个故事中最令人尴尬的部分。我们漏掉了 Web 应用里一个显而易见的可利用漏洞。
要解释我们当初为什么这么做，就必须先补充一些有关播客的重要背景。
网站上展示的播客内容并不归我们所有。和 Apple、Spotify 等其他播客应用类似，我们从 RSS feed 中摄取播客信息，并将其展示在目录里。封面图片通常托管在 Transistor、Buzzsprout 等专业播客托管平台上，但播客也可能托管在任何地方，从 WordPress 网站到 S3 bucket 都有可能。要把所有可能的 host 全部加入 allowlist，实际上并不可行。
优化一张图片，意味着 Next.js 首先要从这些 host 中的某一个把图片下载到 Vercel，完成优化后，再将其提供给用户。如果想让网站保持快速响应，我们要么自行构建并维护一套图像优化 pipeline，要么使用内置能力。作为一家讲究快速行动的创业公司，而且 Web 应用对我们而言充其量只是次要产品，我们没想太多就选择了更快的方案。
现在回头看，我们当初应该先研究清楚它的工作原理。幸运的是，没有人开始把我们的网站当作图像优化 API 来使用。
为了彻底缓解这个问题，我们禁用了所有外部 URL 的图像优化。现在，图像优化只对托管在我们自有域名上的图片启用。播客封面的加载速度明显变慢了，我们最终还是需要解决这个问题。
我们当然知道 robots.txt。这个文件用于告诉爬虫，它们是否被允许抓取网站。
由于我们两个人都没有管理大型内容网站的经验——我们的背景是 backend、API，以及需要登录才能访问的 Web 应用——所以我们甚至没有想到 LLM bot。它压根不在我们的关注范围内。因此，我们的 robots.txt 非常简单：除少数被禁止访问的路径外，其他内容全部允许抓取。
我们的第一反应是禁用除 Google 以外的所有 bot 流量。但在意识到问题的根本原因是错误配置的图像优化后，我们决定继续向所有 LLM bot 和搜索引擎 bot 开放网站。提供文本内容并不会给我们带来太多成本，而如果我们的内容能作为数据来源出现在 LLM 中，我们或许还能从中受益，就像出现在搜索引擎结果页面（SERP）上一样。
我们在 Next.js 中使用 robots.ts，以编程方式生成 robots.txt。我们研究了这些 bot，并将它们的 User Agent 添加到了代码中。如果将来需要禁用其中任何一个 bot，现在都可以非常迅速地完成。趁着这次调整，我们还针对 Semrush、MJ12Bot 等 SEO bot 禁用了一些路径。
需要注意的是，robots.txt 只有在 bot 愿意遵守时才有效。它依赖的是一套荣誉机制，而外面仍然存在无视它，或者试图把自己伪装成普通用户的恶意 bot。
先从一件我们做对了的事情说起。
我们设置了一个非常敏感的支出上限告警。我们知道自己在 Vercel 上不应该花太多钱，所以把上限设得非常低。当告警触发时，我们立刻意识到出了问题。
这可能是对所有创业公司乃至大型企业最重要的教训：一定要为基础设施设置支出上限，否则账单可能会让你破产。你或许可以和 Vercel、AWS、GCP 等供应商协商，让他们降低甚至免除账单，但最好不要让自己陷入不得不开口求情的境地。
我们从中学到了很多，也希望自己已经对以下两点建立了足够的敏感度：
我们所处的规模：我们正在提供数百万个页面，必须做好应对同等规模用户流量的准备。这些 bot 让我们提前体验了一次应用突然爆红时可能面临的场面。
Web 爬虫的规模，无论好坏：我们必须做好被“anthropized”“openAIed”“amazoned”或“semrushed”的准备。这就是新时代的 Slashdot effect，只不过没有即时满足感带来的好处。
现在，我们对未来需要屏蔽 bot 时有哪些选择，已经有了更清晰的认识。我们可以把 Vercel Firewall 作为第一道防线；如果情况变得严重，也可以加入 Cloudflare 更高级的 WAF。
请参阅 Cloudflare 的这篇文章：宣布你的 AIndependence：一键屏蔽 AI bot、scraper 和 crawler
发现 bot 抓取网站的速度后，我们在 LinkedIn 上发了一个帖子。当时只是想实时分享正在发生的事情，没想到它一下子戳中了大家的痛点。帖子获得了将近 40 万次曝光、2,400 次点赞、270 多条评论和 120 多次转发。
我们看完了帖子下的全部评论，并回复了其中大部分。
很多人提出了 CloudFlare、middleware、rate limiting 等解决方案。还有人建议向 LLM bot 返回垃圾内容。
我们也了解到了一些 tarpit 工具，例如 iocaine 和 Nepenthes。
可以把它们引进 honeypot 吗？比如 nepenthes 或 locaine。如果你想给 AI 的数据源投毒的话。
有人一针见血地指出，云资源的无限扩展能力可能会让你直接破产。
这是我对云服务商最大的担忧。你犯了一个小错误——而每个人都会犯错——成本就可能在一夜之间飙升。
我们还发现，有些人并不知道 LLM bot 的抓取活动，更不了解它们的规模。他们感谢我们让更多人意识到这个问题。
天啊——感谢你们提醒我们。
有些人和我们一样，也曾被 bot 的流量打得措手不及。
我们也一样。一开始看到这么多新订阅，我还特别兴奋。后来我们用了 reCaptcha 和 Cloudflare，现在已经平静下来了。感谢分享，我还以为只有我们遇到了这种事。
另一些人则完全不意外，并且认为这是一个严重的问题。
太熟悉了，可惜不是什么好事。这些 bot——主要是 AI bot——从 2024 年 5 月或 6 月起，就开始明显冲击我们的平台。为了控制账单，我们浪费了大量时间和精力。我们还发现，并非所有 bot 都会遵守 Robots.txt，所以确实也需要 WAF。我可以——或者说无法——想象这对小企业来说会有多痛苦……
有些人责怪我们没有提前做好准备，还批评我们公开点名 AI 公司。也有人为我们辩护。爆红是一把双刃剑。
很大一部分评论认为数据抓取不道德、违法，等等。人们对此非常愤怒。这并不是我们的本意，但我们的帖子确实把这个问题带进了当天的公共议题中心。
我内心有一部分其实很庆幸这件事发生了。
我们在真正达到规模之前，提前体验了如何大规模运营 Web 应用。屏蔽 bot 很容易，但如果流量来自真实用户，我们就只能吞下这笔成本，或者降低用户体验。bot 就像煤矿里的金丝雀，提前发出了警报。
任何技术都会产生负外部性。
有些显而易见，有些则不然。在整件事发生的过程中，我很担心播客 host 会惩罚我们，因为 bot 每向我们的网站请求一张图片，我们就会以同样的频率访问它们的 endpoint。
在互联网上进行大规模运营，本质上是一场防御战。
我们可以随心所欲地抱怨 bot，但这就是我们身处的现实。所以，最好承认它，然后处理它。
P.S. 我们将在下一期《Metacast: Behind the scenes》播客中讨论这个话题。无论你平时在哪里收听播客，都可以关注我们，了解这个故事更完整、更细致的版本。
2025 年 2 月 18 日，也就是我们发布这篇博客文章几天后，Vercel 调整了图像优化的定价。按照新的定价方式，我们将不会再面临一笔巨额账单。
不过，这并没有解决我们的核心问题：我们仍然需要优化托管在自有域名之外的图片。最终，我们实现了自己的图像优化方案。