网络数据采集中的反爬对抗演进史

为什么这件事值得重提

写这篇的契机是 2025 年底在某次内部分享中，一个刚毕业的同学问：「都说现在反爬越来越强，那到底强在哪里？我用 requests 一个循环就能跑出不少数据。」这是个特别好的问题。我那时候才意识到，「爬」与「反爬」之间发生的事情远不止看到的代码那么浅薄。

十年前会写个 UA、改个 Referer 基本就能拿到 80% 的数据。今天同样的脚本出门就被盾拦。我们来认真看看这些年到底发生了什么。

L1 — 头部特征阶段（2010 前）

最初的 WAF（Web 应用防火墙）只检查 HTTP 头部：

• UA 黑白名单：拒绝明显属于爬虫的 UA，例如 python-requests、scrapy、Java/1.6。
• Referer 校验：直接访问的请求没有 Referer，拒。
• Cookie 与 Session：未带 Cookie 直接访问的请求，拒。

对抗手段也非常直接——伪造 UA、加 Referer、维持 Cookie。这一代的攻防比拼的更多是「谁记得更多字段」。

L2 — 行为统计阶段（2011–2015）

统计上的「反常行为」开始被识别，比如：

• 同 IP 在 1 秒内请求 20 次；
• 整个站点的请求图谱毫无分支（永远从首页直接跳详情）；
• 两次请求之间间隔总是稳定的 50ms（人手做不到那么精准）。

这阶段引入 IP 限速、行为分析、验证码（最初还是简单的图形验证码）。采集端开始用 IP 池、动态延时、随机 UA。

L3 — 浏览器指纹阶段（2015–2020）

风控开始在前端注入 JavaScript，采集浏览器指纹。常见字段包括：

维度	采集点	示例
Canvas	2D 渲染指纹	不同 GPU / 字体组合下唯一
WebGL	渲染器 + 厂商	"ANGLE (NVIDIA, ...)"
Audio	AudioContext 哈希	采样率差异
字体	已安装字体枚举	"SimSun, Microsoft YaHei"
时区 / 语言	navigator / Intl	"zh-CN, GMT+8"

这阶段攻防进入「高维空间对抗」。一个真实用户和一个 Puppeteer 自动化实例之间会有几十个维度的偏差。常见应对：用 stealth 插件、生成 canvas 噪声、模拟真实输入法事件。

// 一些常见的指纹注入示例
Object.defineProperty(navigator, 'webdriver', { get: () => undefined });
Object.defineProperty(navigator, 'plugins', {
  get: () => [{ name: 'Chrome PDF Plugin' }, { name: 'Chrome PDF Viewer' }]
});

L4 — 行为序列阶段（2020 后）

近年来风控的上限被「行为序列模型」抬高了。背后的假设是：用户真实浏览是「不规则」的，爬虫往往是「均匀」的。模型会对滑动轨迹、按键节奏、滚动模式做小波分析。单纯的 Puppeteer 不带行为模拟基本无法通过。

爬虫工程师开始意识到：对抗的下一战场是「生成更自然的轨迹」，而不是「掩盖更多字段」。

这里开始出现几何仿真、运动轨迹随机化、设备方向变化模拟等高级技术。本质上是「让机器人更像人」——某种意义上，是对真实用户的「仿生」。

L5 — 模型协同与攻击成本错配（2024+）

最新的对抗其实不是更复杂的规则，而是「更聪明的策略组合」：

• 把一个站的指纹聚类训练成「群体画像」，单点对抗失效；
• 对异常请求下发「温柔验证码」——通过分析用户是否尝试正确解决判断真伪；
• 在敏感接口采用「二次挑战」，首次响应中夹带一次性 token；
• 把大量低风险路径放行，专心做高风险路径的深度识别。

这意味着采集端的「性价比」问题被放到核心：哪些页真值得用最强对抗方式去采集、哪些页用普通手段就够了。

合规采集的几个底线

在写技术的同时，我也想强调合规。原因不是法律课，而是：合规与工程化结合得好的团队，存活率更高。这里有几个习惯：

1. 先看 robots.txt，尊重站点的 User-agent: * Disallow: /secret/。
2. 控制频率，不要超过目标站点明示的速率阈值。
3. 公开数据 vs. 用户数据，永远把这两类隔离开。
4. 关键字段避免落库原值，加密或哈希后再处理。

这几个动作不比一份 docstring 多花时间，但能让你规避掉大多数麻烦。

自建采集栈的几个取舍

2026 年的今天，云厂商提供了大量「数据采集服务」「浏览器代理」「智能反反爬套件」。要不要自建？我的看法是：

能力	建议
简单 HTTP 请求	自建（够用）
IP 池 / 代理治理	半自建（云为主）
浏览器自动化	按规模决策
JS 渲染管线	云或自托管
AI 验证码识别	第三方

一个核心原则是「复杂度匹配的收益递减」。当你为了提高 5% 的成功率要写 6 个月代码时，多数情况这不是好生意。

给采集工程师的几个建议

• 把风控当作「业务」，而不只是技术挑战。要理解为什么风控要加强，是为了防止被竞争对手拖垮。
• 保留「第一手」观察。每开一个新项目，都要亲手跑一次目标网站，看它的提示、限速、错误码，是工程师最重要的事。
• 做可被复用的采集框架。把 UA、Cookie、Proxy、Retry、Budget 这些通用能力抽出来。

采集与反爬会长期共存。这件事最有意思的一面是，它始终在提醒工程师：互联网并不是一个无摩擦的世界。