Skip to main content

​
网页爬取发生了什么变化？

脚本仍然有效，直到它们突然失效。然后你在凌晨2点进行调试，因为某个网站改变了一个CSS类，整个管道就沉默了。 五年前，爬取是一个脚本问题。你编写一个解析器，将其指向一个URL，然后收集数据。今天，爬取是一个基础设施问题。仅Cloudflare就保护了超过2400万个活跃网站，2025年7月开始在其整个网络范围内默认阻止AI爬虫。由Wappalyzer跟踪的网络安全服务数量在2022年至2024年间从36个增长到60个，几乎翻倍。网络变得更难爬取，而且速度很快。 本文探讨了为什么格局发生了变化，生产级爬取系统现在是什么样的，以及团队如何调整架构以在规模上可靠运行。

​
经济学发生了变化

大多数团队跟踪的主要指标是每千兆字节代理流量的成本。在过去五年中，这个数字已经大幅下降。但这是错误的指标。 真正重要的是每个成功载荷的成本：总支出（代理、计算、API费用）除以你提取的可用记录数。这个数字一直在上升，因为提取数据所需的技术变得更加昂贵，尽管单个输入成本下降了。 原因如下：
  • 曾经用数据中心代理简单HTTP请求回应的网站现在需要住宅代理（成本大约是10倍）或完整的浏览器渲染（计算的另一个5-10倍乘数）
  • 根据AImultiple的网页爬取挑战研究，阻止现在是开发人员面临的主要挑战，静态IP阻止已被持续的行为信任评分取代
  • 需要重量级提取方法（住宅IP、无头浏览器或两者）的请求份额大幅增长，由反机器人服务的广泛采用驱动
这造成了你可能称之为爬取冲击的情况：数据在技术上仍然可到达，但以之前的成本水平提取变得经济上很痛苦。
爬取中的竞争优势已从”谁能爬取最多”转向”谁能最高效地爬取”。每个成功载荷的成本现在是重要的指标。

​
驱动变化的三股力量

​
1. 反机器人系统变得更智能，速度更快

2024年9月，Cloudflare推出了一键式AI机器人阻止。超过100万客户激活了它。到2025年7月，Cloudflare开始在其整个网络范围内默认阻止AI爬虫。 检测已超越IP信誉和Cookie验证。现代反机器人系统现在分析：
  • TLS指纹。 Python的Requests库的TLS签名与Chrome不同，使该库本身可识别。
  • 浏览器指纹。 屏幕分辨率、WebGL渲染器、画布指纹、已安装字体、音频上下文和GPU计时。
  • 行为信号。 鼠标移动模式、滚动速度、点击计时和击键节奏。
  • 标头一致性。 真实浏览器根据请求类型发送不同的标头；机器人每次都发送相同的标头。
流行的puppeteer-stealth库在2025年2月被弃用，因为它无法再绕过当前的Cloudflare版本。正如开发人员在爬取社区中频繁报告的那样：原生Selenium和Puppeteer到处泄露自动化信号，今天有效的技术下个月就会停止工作。

​
2. 平台有意锁定

这不仅仅是技术升级。这是战略性的。平台将其数据视为竞争资产，特别是与AI公司竞争时。
  • Reddit在2025年10月对多个数据收集公司和Perplexity AI提起诉讼，指控其规避安全措施。
  • X/Twitter在2024年10月实施了IP信誉评分，在2025年1月将访客令牌绑定到浏览器指纹，并永久禁止数据中心IP。
  • **Cloudflare的”AI迷宫”**创建蜜罐陷阱，迫使AI代理在虚假内容上浪费计算资源。
这些不是孤立的事件。它们代表了一个协调的转变，平台将不受限制的数据访问视为对其商业模式的威胁。

​
3. AI爬虫改变了对所有人的游戏规则

GPTBot的AI爬虫流量在2024年7月至2025年7月间增长了147%。Meta-ExternalAgent流量增长了843%。这些爬虫每天共产生约500亿个请求，根据Cloudflare的说法，约占所有网络流量的1%。 这股AI流量的激增引发了防御性反应，影响了所有爬虫，而不仅仅是AI爬虫。从未费力使用反机器人保护的网站现在都有了。附带损害影响了每个运行数据管道的团队。
AI爬虫在404页面和重定向链上花费大量的获取操作。这种低效是促使网站实施全面阻止而不是选择性过滤的部分原因。

​
生产级爬取现在是什么样的

“爬取在我的笔记本上有效”和”爬取在生产中有效”之间的差距从未如此之大。低代码工具和LLM有助于从0到1（使爬虫对单个页面有效）。但从1到100（在规模上可靠运行）需要系统思维。 爬取规模运营的现实是令人沮丧的：即使成功运行每天少于100万页面浏览的规模也需要管理视口大小匹配、用户代理轮换、每个容器多个VLAN和数据中心IP避免。 以下是生产爬取系统实际上的样子： 现代爬取运营架构 该架构有五层，每层解决不同的运营问题：

​
编排层

这是控制平面。它管理爬取什么、何时以及如何爬取。至少包括：
  • 作业调度程序。 根据数据新鲜度要求对爬取作业进行优先级排序和排队。
  • 请求路由器。 根据网站的难度配置，决定每个目标的提取方法（HTTP客户端、无头浏览器或托管API）。
  • 重试逻辑和退避。 处理瞬时故障而不会无情地锤击目标。
大多数团队在没有此层的情况下开始。他们将爬虫作为cron作业运行并手动处理路由。这对每天数百页有效。它在数十万页时会崩溃。

​
提取层

这是实际爬取发生的地方。关键见解是并非每个请求都需要相同的工具：
  • HTTP客户端以最小资源成本处理0.5-2秒的请求。它们适用于静态内容和没有大量JavaScript渲染的网站。
  • 无头浏览器处理JavaScript呈现的内容，但每个实例消费200-500 MB RAM并需要3-15秒的请求。这是5-10倍的基础设施乘数。
  • 托管爬取API将反机器人处理、代理轮换和浏览器管理转移到第三方。每请求成本更高，但你消除了基础设施维护。
生产模式是分层方法：首先尝试最便宜的方法，仅在失败时升级，并缓存结果以便后续对同一域的请求使用正确的方法。
每个Chrome实例需要200-500 MB RAM，后台脚本即使在页面看起来空闲时也继续运行。会话绑定到特定进程，使跨机器负载平衡变得复杂，并且在实例间共享Chrome用户数据目录很危险。

​
验证层

这是大多数团队跳过的层，也是在规模上造成最多损害的层。 在没有验证的情况下扩展意味着扩展错误。被阻止的爬虫不总是返回HTTP错误。它可能返回看起来有效但数据错误的HTML：验证码页面、软块或内容的特定区域版本。你的下游系统会无声地摄入它。 生产验证包括：
  • 模式验证在数据进入存储之前：预期字段、类型和值范围。
  • 内容指纹识别以检测响应何时与已知块页面模式匹配而不是真实内容。
  • 字段完整性检查，标记关键字段缺失或值异常一致的记录。
向爬取管道添加模式验证的团队一致报告在下游数据质量问题和ML模型错误中有显著减少。

​
可观测性层

将爬取视为生产服务。如果你运行没有监控的网络应用程序，你会很失职。爬取管道值得同样的纪律。 要追踪的关键指标：
  • 每个域的成功率。 返回有效、可用数据的请求百分比（不仅仅是HTTP 200）。
  • 每个成功载荷的成本。 总成本（代理+计算+API）除以提取的可用记录。
  • 选择器健康。 自动化检查，检测CSS选择器或XPath表达式何时停止匹配预期元素。
  • 延迟分布。 每个域的p50和p99响应时间，表示网站何时开始节流。
实施可观测性驱动爬虫重新设计的团队一致看到显著改进：更少的作业失败、更快的网站变化检测和减少的运营开销。

​
存储和交付层

干净、经过验证的数据流入存储和下游系统。此层很简单但对管道完整性很重要：
  • 写入前去重。 爬取同一产品页面两次不应该创建两条记录。
  • 时间戳。 每条记录都带有收集时间戳，以便下游消费者知道数据新鲜度。
  • 模式演变。 当网站改变其数据结构时，你的存储模式需要在转换期间同时容纳旧格式和新格式。

​
构建与购买决策

在某个时刻，每个爬取团队都会问：我们应该自己维护这个基础设施，还是使用托管服务？ 盈亏平衡数学取决于规模和网站难度： 构建与购买决策框架 自托管浏览器基础设施成本为每月200-800美元加上持续的工程时间。在规模上，工程时间占主导地位：季度选择器修复、代理池管理和反机器人适配是不会随着自动化而缩小的重复成本。 实际模式是混合方法：
  • 自托管针对简单HTTP请求有效且数据格式稳定的网站。
  • 使用托管API针对具有重型反机器人保护、频繁布局变化或JavaScript密集渲染的网站。
Bright Data的产品套件映射到此分层模型。Web Unlocker处理HTTP请求的反机器人层。Scraping Browser提供托管无头浏览器而不需要RAM和扩展麻烦。Web Scraper API处理受支持网站的完整提取管道，直接返回结构化数据。 决策不是二元的。大多数生产团队使用自托管和托管组件的混合，按域名根据难度、成本和数据新鲜度要求分别优化。

​
常见的架构错误

这些模式在规模化时举步维艰的爬取团队中反复出现：
  • 没有校验层。 最常见的失败。团队在不校验输出的情况下扩大提取规模，几周后才发现一半的数据是被当作正常记录存下来的验证码页面。
  • 默认使用浏览器。 无头浏览器的成本是 HTTP 客户端的 5 到 10 倍。把每个请求都经由 Puppeteer 或 Playwright 的团队，是在为那些用配置得当的 HTTP 请求就能正常响应的网站白白烧钱。
  • 硬编码选择器且不做监控。 网站更改 DOM 时，静态的 XPath 和 CSS 选择器会悄无声息地失效。没有自动化的选择器健康检查，数据质量会在不触发任何告警的情况下下降。
  • 把爬取当脚本而不是服务。 没有健康检查的 cron 任务、成功率下降时没有告警、没有按域名的成本跟踪。小规模时可行，到生产规模就会产生看不见的故障。
  • 忽视经济账。 网站升级防御时，爬取成本可能一夜之间上涨 5 到 10 倍。没有按有效载荷跟踪成本的团队，直到月度账单到来才会察觉。

​
未来的走向

三个趋势将塑造未来两年的爬取运营：
  1. 法律框架正在成形。 Reddit 的诉讼、欧盟《人工智能法案》的数据来源要求以及各平台的服务条款，正在形成一个爬取系统必须纳入考虑的合规层。把合规当作事后补救的团队将面临运营中断。
  2. AI 出现在对抗的双方。 网站用机器学习模型检测机器人，爬虫用大语言模型解析非结构化内容。规模化时，基于大语言模型的解析成本仍比传统方法高出几个数量级，但正在下降。弄清何时用 AI 解析、何时用传统选择器的团队将获得成本优势。
  3. 托管基础设施正在成为默认选择。 随着反机器人系统日益复杂，自托管的维护负担不断加重。趋势指向更多团队购买基础设施，把工程精力集中在数据质量和业务逻辑上。
蓬勃发展的爬取团队不会是写出最巧妙绕过脚本的团队，而是运营最有纪律的团队：清晰的成本跟踪、自动化的质量校验，以及无需人工干预就能适应对抗性网络的架构。

​
延伸阅读

爬取冲击指的是网页数据在技术上仍可访问，但已无法以过去的成本水平经济地提取的临界点。其驱动因素是更复杂的反机器人系统、强制的浏览器渲染和必需的住宅代理叠加在一起，即便每 GB 的代理价格已经下降。
一般的盈亏平衡点在每月 50 万到 100 万次请求左右，但因目标网站的难度差异很大。如果大多数目标网站用简单的 HTTP 请求和数据中心代理就能搞定，自托管在更高的量级上仍然划算。如果目标网站需要住宅代理和浏览器渲染，托管服务在更低的量级上就更经济。
过去五年，每 GB 的代理价格大幅下降。但需要住宅代理（比数据中心代理贵约 10 倍）和浏览器渲染（再乘以 5 到 10 倍）的请求占比显著增长。所需资源的变化远远抵消了单价的下降。
因实现方式而异，但没有校验层的团队通常会发现，10% 到 30% 的”成功”请求返回的是拦截页面、验证码或特定地区的内容，而不是预期的数据。这些失败返回 HTTP 200，因此能不被察觉地通过基础的成功/失败检查。
对合适的目标网站仍然可行。反机器人防护薄弱、DOM 结构稳定、内容静态的网站，用自托管工具爬取仍然划算。问题在于这类网站的数量在减少。混合方式（简单目标自托管，困难目标用托管服务）是最常见的生产模式。