抓取 Google 搜索结果失败的原因很具体:Google 将来自单个 IP 的连续请求流视为它本来的样子, 机器人,并在几十次查询内开始返回 CAPTCHA 和 429。解决方案不是耍聪明的请求头或更长的延迟,而是每次从一个看起来像真实用户的不同 IP 发送请求,这正是代理轮换所做的。把轮换模型和 IP 类型选对,SERP 抓取就会变成例行公事;选错了,你就会把时间花在解决确认页面上,而不是解析搜索结果。
本文是实操版本:讲解 Google 为何以这种方式封锁、为何逐请求轮换比静态池更适合 SERP、哪种 IP 类型真正能撑住、一个可运行的 Python 示例,以及什么时候托管的 SERP 端点比自己维护轮换更省事。如果你想先了解代理基础,什么是代理服务器介绍了这里所有内容都建立在其上的那一层间接机制。
为什么 Google 对爬虫封锁如此积极
Google 的整个业务是服务于人类,因此其滥用防御系统被调校为识别任何非人类的行为。爬虫会同时触发其中多个信号。最明显的信号是单个地址的请求量:真实用户每小时发起几次搜索,而一个简单的爬虫每分钟从一个 IP 发起数百次请求。仅这个频率就足以触发 sorry/index 确认页面或 CAPTCHA。
IP 本身是第二个信号。Google 知道哪些地址段属于云和托管服务商,因此来自数据中心 IP 的流量在发出第一次查询之前就已经处于低信任状态。此外还有请求形态检查:缺失或机器人特征的请求头、与你的用户代理所声称的浏览器不符的 TLS 指纹、没有 Cookie,以及请求之间完全相同的间隔。轮换 IP 解决了前两个信号,但不能解决其余问题,这就是为什么轮换是必要条件但不是充分条件,这一点我们后面还会回来讨论。
为什么逐请求轮换是 SERP 的正确模型
轮换意味着切换出口 IP,使连续请求不会全部来自同一个地址。有两种交付模型,对 Google 来说区别很重要。
粘性会话在一段请求期间保持一个 IP,这是你在登录流程中需要的,因为突然的 IP 变化看起来可疑。逐请求轮换则在每次调用时切换 IP。Google 搜索没有登录,也没有需要保持的会话,因此固定一个 IP 没有任何好处,而将查询分散到许多不同 IP 上则有充分理由。逐请求轮换是适合 SERP 的模型:一千次查询分散在一千个地址上,每个看起来都像一个好奇的用户,而不是一台机器。关于在爬虫中构建轮换的机制,如何使用轮换代理有更深入的介绍,轮换 IP 地址则单独介绍了这个概念。
轮换背后的池大小是另一半。在高流量下跨十个 IP 轮换只不过是以更慢的速度对十个 IP 进行限速。大池子才是让任何单个地址保持在 Google 每 IP 雷达之下的关键,这就是为什么轮换和池大小实际上是同一个决策。
IP 类型决定轮换是否有效
只有当你轮换的 IP 是受信任的,轮换才有意义。循环使用一千个数据中心 IP,Google 会对同一 ASN 信号封锁全部一千个,只是分散在更多请求上。IP 类型是 SERP 抓取中最关键的选择。
| IP 类型 | Google 的处理方式 | 成本与速度 | 适合 SERP 吗 |
|---|---|---|---|
| 数据中心 | 通过 ASN 识别,低信任,封锁快速 | 最便宜,最快 | 单独使用效果差 |
| 住宅 | 读作真实家庭用户,能经受挑战 | 按带宽计费,较慢 | 强烈推荐的默认选择 |
| 移动 | 最难封锁(运营商级 NAT) | 最贵,最慢 | 对大多数 SERP 工作过于重量级 |
对于 Google 搜索,实际答案是住宅 IP:互联网服务提供商分配给真实家庭的 IP,这样轮换的查询就像普通访客,而不是服务器。数据中心 IP 对容忍度高的目标没问题,但在 SERP 上会很快被标记;移动 IP 的信任度(和成本)通常超过搜索结果的需求。完整的权衡分析请参见数据中心代理 vs 住宅代理,以及静态住宅的中间方案ISP 代理 vs 住宅代理。这里的数字描述的是典型情况;你的具体封锁率会随查询量、地区以及特定结果页面的防护强度而变化。
切换 IP 解决了每 IP 速率限制和数据中心 ASN 检查。但它对机器人特征的 TLS 指纹、缺失的 Cookie 或固定的请求间隔毫无作用。一个干净的住宅 IP 加上明显自动化的请求仍然会触发 CAPTCHA。把轮换当作一层,并将其与可信的请求头、多样化的间隔,以及在页面需要客户端渲染时的真实浏览器指纹配对使用。
在 Python 中设置代理轮换
最简洁的轮换方式是将你的客户端指向一个单一的轮换端点,让它按请求切换出口 IP,而不是自己维护和健康检查原始 IP 列表。对你的代码来说它就是一个代理:一个主机、一个端口,用你的 token 作为凭据。Crawlbase Smart AI Proxy 就是这样工作的,因此集成只需几行代码。
安装唯一的依赖:
pip install requests
然后通过轮换端点路由请求。以下示例搜索多个查询,随机化请求之间的延迟,并打印每个请求是否返回干净结果:
import requests import random import time from urllib.parse import quote_plus # One rotating endpoint swaps the exit IP per request. proxy_url = "http://[email protected]:8012" proxies = {"http": proxy_url, "https": proxy_url} headers = { "User-Agent": ( "Mozilla/5.0 (Windows NT 10.0; Win64; x64) " "AppleWebKit/537.36 (KHTML, like Gecko) " "Chrome/124.0 Safari/537.36" ), } queries = ["web scraping", "residential proxies", "serp api"] for query in queries: url = "https://www.google.com/search?q=" + quote_plus(query) resp = requests.get(url, proxies=proxies, headers=headers, verify=False) print(query, resp.status_code, "blocked" if "/sorry/" in resp.url else "ok") # Vary timing so requests do not arrive on a fixed clock. time.sleep(random.uniform(2, 5))
将 _USER_TOKEN_ 替换为你的 Crawlbase 账号 token。注意代码在轮换之外做了什么:它发送了真实的 User-Agent,随机化了请求之间的间隔,并检查了 Google 用于挑战页面的 /sorry/ 重定向。这些细节是有效轮换与安静地返回确认页面(然后你当作搜索结果解析)之间的区别。
让轮换持续有效的最佳实践
以下几个习惯能让轮换 SERP 爬虫长期保持健康,而不只是头一个小时有效。
- 按 IP 限速,而不只是总体限速。 大池子让你保持较高的总吞吐量,同时任何单个地址只看到涓涓细流。池子吸收流量,每 IP 速率保持人类水平。
-
随机化间隔和请求头。 固定延迟和一个静态
User-Agent就是一种指纹。两者都要多样化。在 IP 之外轮换用户代理的内容见如何在不被封锁的情况下抓取网站。 -
检测封锁,不要解析它们。 监控
/sorry/重定向、CAPTCHA 标记和空结果容器。将这些视为需要用新 IP 重试的失败,而不是要解析的数据。 - 受到挑战时退让。 如果封锁率上升,减慢速度并扩大池子,而不是加大力度。在被标记后继续强攻只会加深标记。
- 只在页面需要时使用浏览器。 普通 HTTP 更快更便宜;将无头渲染保留给客户端渲染的结果类型。用 Python 和 Selenium 进行网页抓取展示了这条路径。
如果你的目标特别是排名和关键词研究,SEO 代理涵盖了地理定向角度,因为 SERP 因国家而异,出口 IP 的位置决定了你看到的结果。
什么时候托管的 SERP 端点胜过自己搭建
上面所有内容都是可以自己构建的,对于低流量来说值得构建。成本在扩展时才会显现。单靠轮换,你还需要自己处理其余的问题:维护池子健康状态、匹配 TLS 指纹、解决或绕过 CAPTCHA、渲染客户端加载的结果页面,以及在每次遭遇挑战时重试。这是 SERP 抓取栈的大部分工作,而轮换只是其中第一层。
托管端点将这些工作压缩进一次请求。你发送一个 URL 或查询;它选择一个受信任的住宅 IP,发送可信的指纹,在页面需要浏览器时渲染,服务端重试封锁情况,并返回完整结果。Crawling API 正是为此而生:在原始轮换代理给你一个干净的 IP 然后退场的地方,该 API 吸收封锁并将成功交给你。两者之间的权衡分析在反向连接代理 vs 抓取 API中。
跳过从头构建轮换的麻烦。Smart AI Proxy 是一个端点,背后是大型住宅、数据中心和移动 IP 池,按请求轮换并在遭遇封锁时重试,让正确的 IP 类型与 Google 匹配,而无需你自己维护列表健康状态。当结果页面需要浏览器,或者你宁愿不自己处理反爬层时,Crawling API 将渲染和重试包裹在同一个池子之上。先用真实查询在免费套餐上测试。
核心要点
- Google 首先按流量和 IP 声誉封锁。 单个地址发起大量查询(尤其是来自数据中心地址段)是你必须克服的信号。
- 逐请求轮换适合 SERP。 搜索没有需要保持的会话,因此将每次查询分散到大池子中,而不是固定在一个 IP 上。
- IP 类型决定结果。 住宅是 Google 的强烈推荐默认选择;轮换数据中心 IP 只是以更慢的速度被封锁。
- 轮换是必要条件,不是充分条件。 配合真实请求头、多样化间隔、封锁检测,以及只在页面需要时渲染。
- 规模上来时选择托管路径。 SERP 或抓取 API 处理了指纹、CAPTCHA、渲染和重试,这些都是单靠轮换留给你的问题。
常见问题
Google 为什么对爬虫封锁如此迅速?
Google 将其滥用防御调校为识别任何非人类浏览的行为。单个 IP 每分钟发起大量搜索会触发每 IP 速率限制,来自已知数据中心地址段的流量在第一次查询之前就处于低信任状态。再加上机器人特征的请求头、没有 Cookie 和相同的间隔,结果就是在几十次请求内触发 CAPTCHA 或 /sorry/ 确认页面。
可靠地抓取 Google 需要多少代理?
足以让任何单个 IP 在你的目标流量下都不超过看起来像人类的请求频率。没有固定数字:它随你每分钟运行的查询数量扩展。在高流量下跨十个 IP 轮换只不过是以更慢的速度对十个 IP 进行限速,因此大型轮换池而非少量静态地址才是让每个 IP 保持在 Google 雷达之下的方法。
抓取 Google 搜索结果最好使用哪种代理类型?
住宅代理。它们从 ISP 分配给真实家庭的 IP 出口,因此轮换的查询读起来像普通访客而非服务器。数据中心 IP 通过 ASN 识别,在 SERP 上封锁很快,移动 IP 通常比搜索结果所需的信任度(和成本)更高。先从住宅开始,只有当特定结果页面仍然对你发起挑战时才升级。
SERP 应该用粘性会话还是逐请求轮换?
逐请求轮换。粘性会话的目的是在登录流程中保持一个身份,而 Google 搜索没有登录或需要保持的会话。每次请求切换出口 IP,将你的查询分散到池子中,这样每个地址看起来像一个随意的用户而不是一台机器。
轮换代理足以避免 Google CAPTCHA 吗?
单靠轮换是不够的。轮换解决了每 IP 速率限制和数据中心 ASN 检查,但对机器人特征的 TLS 指纹、缺失的 Cookie 或固定的请求间隔毫无作用。一个干净的住宅 IP 加上明显自动化的请求仍然会触发 CAPTCHA。将轮换与真实请求头、多样化延迟,以及在页面客户端渲染时的真实浏览器指纹配对使用。
什么时候 SERP 或抓取 API 比自己搭建轮换更好?
当流量超过几千次查询,或者结果页面在客户端渲染时。轮换只是第一层;你还需要自己处理池子健康、指纹、CAPTCHA 处理、渲染和重试。托管端点将这些全部压缩进一次请求:你发送查询,得到解析后的结果,轮换和反爬处理在服务端完成。
大规模爬取任何站点,无需与基础设施对抗。
Crawlbase 负责处理代理、指纹和 CAPTCHA,让你的团队专注于交付数据流水线,而非维护爬取管道。1,000 次请求免费,无需信用卡。
