> ## Documentation Index
> Fetch the complete documentation index at: https://docs.brightdata.com/llms.txt
> Use this file to discover all available pages before exploring further.
# 现代网络爬取操作
> 为什么网页抓取从脚本问题演变为基础设施学科，以及2026年生产级抓取系统的样貌。
# 网页爬取发生了什么变化？
脚本仍然有效，直到它们突然失效。然后你在凌晨2点进行调试，因为某个网站改变了一个CSS类，整个管道就沉默了。
五年前，爬取是一个脚本问题。你编写一个解析器，将其指向一个URL，然后收集数据。今天，爬取是一个基础设施问题。仅Cloudflare就保护了[超过2400万个活跃网站](https://www.cloudflare.com/network/)，2025年7月开始在其整个网络范围内[默认阻止AI爬虫](https://blog.cloudflare.com/declaring-your-aindependence-block-ai-bots-scrapers-and-crawlers-with-a-single-click/)。由[Wappalyzer](https://www.wappalyzer.com/technologies/security/)跟踪的网络安全服务数量在2022年至2024年间从36个增长到60个，几乎翻倍。网络变得更难爬取，而且速度很快。
本文探讨了为什么格局发生了变化，生产级爬取系统现在是什么样的，以及团队如何调整架构以在规模上可靠运行。
## 经济学发生了变化
大多数团队跟踪的主要指标是每千兆字节代理流量的成本。在过去五年中，这个数字已经大幅下降。但这是错误的指标。
真正重要的是**每个成功载荷的成本**：总支出（代理、计算、API费用）除以你提取的可用记录数。这个数字一直在上升，因为提取数据所需的技术变得更加昂贵，尽管单个输入成本下降了。
原因如下：
* 曾经用数据中心代理简单HTTP请求回应的网站现在需要住宅代理（成本大约是10倍）或完整的浏览器渲染（计算的另一个5-10倍乘数）
* 根据[AImultiple的网页爬取挑战研究](https://aimultiple.com/web-scraping-challenges)，阻止现在是开发人员面临的主要挑战，静态IP阻止已被持续的行为信任评分取代
* 需要重量级提取方法（住宅IP、无头浏览器或两者）的请求份额大幅增长，由反机器人服务的广泛采用驱动
这造成了你可能称之为**爬取冲击**的情况：数据在技术上仍然可到达，但以之前的成本水平提取变得经济上很痛苦。
爬取中的竞争优势已从"谁能爬取最多"转向"谁能最高效地爬取"。每个成功载荷的成本现在是重要的指标。
## 驱动变化的三股力量
### 1. 反机器人系统变得更智能，速度更快
2024年9月，Cloudflare推出了[一键式AI机器人阻止](https://blog.cloudflare.com/declaring-your-aindependence-block-ai-bots-scrapers-and-crawlers-with-a-single-click/)。超过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亿个请求](https://blog.cloudflare.com/declaring-your-aindependence-block-ai-bots-scrapers-and-crawlers-with-a-single-click/)，根据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响应时间，表示网站何时开始节流。
实施可观测性驱动爬虫重新设计的团队一致看到显著改进：更少的作业失败、更快的网站变化检测和减少的运营开销。
### 存储和交付层
干净、经过验证的数据流入存储和下游系统。此层很简单但对管道完整性很重要：
* **写入前去重。** 爬取同一产品页面两次不应该创建两条记录。
* **时间戳。** 每条记录都带有收集时间戳，以便下游消费者知道数据新鲜度。
* **模式演变。** 当网站改变其数据结构时，你的存储模式需要在转换期间同时容纳旧格式和新格式。
## 构建与购买决策
在某个时刻，每个爬取团队都会问：我们应该自己维护这个基础设施，还是使用托管服务？
盈亏平衡数学取决于规模和网站难度：
| 因素 | 构建（自托管） | 购买（托管服务） |
| ------------ | -------------------- | ----------- |
| **前期成本** | 低（开源工具） | 按请求定价 |
| **维护负担** | 高（代理轮换、浏览器更新、反机器人适配） | 低（供应商处理） |
| **控制** | 完全 | 受限于API参数 |
| **扩展限制** | 受基础设施团队限制 | 随支出扩展 |
| **反机器人适配速度** | 数周至数月 | 数小时至数天 |
| **盈亏平衡点** | 低于\~50万请求/月 | 高于\~50万请求/月 |
自托管浏览器基础设施成本为每月200-800美元加上持续的工程时间。在规模上，工程时间占主导地位：季度选择器修复、代理池管理和反机器人适配是不会随着自动化而缩小的重复成本。
实际模式是混合方法：
* **自托管**针对简单HTTP请求有效且数据格式稳定的网站。
* **使用托管API**针对具有重型反机器人保护、频繁布局变化或JavaScript密集渲染的网站。
Bright Data的产品套件映射到此分层模型。[Web Unlocker](/products/web-unlocker/introduction)处理HTTP请求的反机器人层。[Scraping Browser](/products/scraping-browser/introduction)提供托管无头浏览器而不需要RAM和扩展麻烦。[Web Scraper API](/products/scrapers/overview)处理受支持网站的完整提取管道，直接返回结构化数据。
决策不是二元的。大多数生产团队使用自托管和托管组件的混合，根据