抓取 Google 时如何绕过 CAPTCHA避免触发验证挑战

当 Google 已经决定向你显示 CAPTCHA 时，你无法击败它。当"我不是机器人"复选框或图片网格出现时，检测已经完成：你的流量中的某些特征被判定为自动化，验证挑战是结果，而不是关卡。在抓取 Google 时绕过 CAPTCHA 的持久方法，是从一开始就不触发它。让你的请求看起来像一个普通人在搜索，挑战就根本不会出现。

本指南就是关于这种方法的。它涵盖了 Google 为何决定对爬虫发起挑战、哪些具体措施能让你的流量保持在阈值以下、第三方 CAPTCHA 解决服务的适用场景（以及为何依赖它们意味着你已经在上游的战斗中落败），以及一段简短的可工作代码路径，可以在不触发警报的情况下获取 Google 搜索结果页面。范围内的数据仅为公开搜索结果：标题、链接、摘要，即任何未登录访客都能看到的内容。

Google 为何向爬虫发起挑战

Google 不会随机显示 CAPTCHA。当一个请求看起来像是来自脚本而非真人时，它才会显示，而它是通过同时综合多个信号来做出这一判断的。知道你在哪个信号上失败，才能告诉你应该改变什么，因此有必要对每个信号精确分析。

• 来自同一 IP 的请求频率。在短时间内从单一地址发出一连串搜索，是最容易被识别的特征。人类会停下来阅读和重新表述；紧密的循环不会。这是大多数爬虫跨越的第一道门槛。
• IP 声誉。解析到托管服务提供商（数据中心 ASN）的地址比消费者连接更不被信任，因为几乎没有真实的搜索来自服务器机架。来自云服务器的干净脚本，在发出第一个查询之前就已经是可疑的了。
• 浏览器指纹和请求头。Google 读取你的 user-agent、请求头顺序、TLS 握手以及客户端 JavaScript 暴露的属性。请求头与其声称的浏览器不匹配，或者没有暴露真实浏览器应有的任何属性，这都会很显眼。更多内容见浏览器指纹识别。
• 缺少 JavaScript 和行为信号。真实会话会运行脚本、设置 cookie，并产生人类与页面交互的细微信号。裸 HTTP 获取不会产生任何这些，而这种缺失本身就是一个信号。
• 会话卫生。没有 cookie、没有连续性、每次访问都是全新的空白会话：这种模式看起来像自动化，因为真实的人会将状态从一次搜索延续到下一次。

这些都不是单一的开关。Google 综合评估它们，同时在两三个方面失败的请求才会收到 CAPTCHA。这也是好消息：修复关键信号，你就能保持在触发挑战的阈值以下。

实际上让你保持在阈值以下的措施

这里的每个杠杆都对应上面的某个信号。同时拉动它们，你的流量就会停止看起来像自动化，这就是全部的关键。

轮换 IP，并使用住宅 IP

最大的单一因素是你的请求从哪个地址发出。两件事很重要：IP 的可信程度，以及任何一个 IP 承载多少请求。

数据中心 IP 速度快且成本低，但它们解析到 Google 一眼就不信任的托管 ASN，因此会快速积累挑战。住宅代理从真实的消费者 ISP 连接发出，所以 Google 将其视为普通访客。这种信任差异就是返回结果的查询与返回复选框的查询之间的区别。完整的对比见数据中心代理与住宅代理的对比。

可信度是一半；分散负载是另一半。即使是完美的 IP，如果你将整个运行都通过它来处理，也会被限速。轮换住宅代理在大型 IP 池中交换出口地址，即使你的总量很高，每个 IP 的请求速率也保持在低位。一种干净的使用方式是 backconnect 网关，即一个在幕后（按请求或按会话粘性）更换 IP 的单一端点，在如何使用轮换代理以及针对搜索结果页面的如何轮换代理抓取 Google 搜索结果中都有介绍。

发送与你声称的浏览器相匹配的请求头

真实的 user-agent 只是最低门槛，而非上限。陷阱在于不一致：一个声称是 Chrome 但缺少 Chrome 实际发送的请求头，或者顺序和大小写不匹配的请求头集合，比完全没有 user-agent 更可疑，因为它看起来像一个假装的脚本。发送一致、最新的浏览器配置文件，或者让维护它的工具替你处理。

控制请求频率并随机化间隔

只有在你的量确实分散稀薄时，轮换才有帮助。在紧密循环中发出请求会集中负载，并产生没有任何人类会匹配的机器般完美节奏。在请求之间添加延迟，随机化间隔，并保持每个 IP 的速率在低位。更慢但能完成的流量胜过在第五十个请求时被挑战的快速流量。

渲染 JavaScript 并保持会话

Google 的一些检查依赖于客户端运行脚本并在请求之间携带 cookie。裸获取不能满足这些要求。使用浏览器渲染页面，并保持会话连续性而非每次从空白开始，消除了普通 HTTP 客户端无法避免发出的一类信号。通用攻略见如何在不被封锁的情况下抓取网站。

CAPTCHA 解决服务怎么样？

2Captcha 和 Anti-Captcha 等服务是存在的，它们也确实做到了它们所宣传的：当挑战出现时，它们返回一个已解决的 token，有时通过人工解决者，有时通过模型。与其假装它们不起作用，不如诚实地评估它们。

问题在于使用它们意味着什么。如果你在为解决挑战付费，你就已经被挑战了，这意味着你的流量在上游触发了检测。你现在要为每次挑战付费，在每次解决时增加延迟，并依赖一个会在挑战格式改变时失效的第三方。这些都不能优雅地规模化，也没有一个能解决根本原因。解决器是对你尚未修复的漏洞的临时补丁。

更好的工程实践是不被挑战。如果你已经调整了 IP 来源、轮换、请求头、频率和渲染，而挑战很少见，那么将解决器作为最后手段的备选是可以接受的。如果挑战频繁出现，而你在每次运行中都靠解决挑战来通过，那这就是修复输入而非购买更多解决次数的信号。关于挑战处理的更广泛视角，见如何在网页抓取中绕过 CAPTCHA。

不触发挑战的代码路径

手动将轮换、住宅 IP、匹配的请求头、频率控制和渲染整合在一起是一个真正的项目，而随着 Google 的调整不断维护它是持续性的工作。捷径是将整个请求交给一个已经完成所有这些工作的端点。Crawlbase Crawling API 接收目标 URL，在住宅 IP 池中轮换出口 IP，发送一致的浏览器配置文件，在需要时渲染 JavaScript，并返回结果，因此本来会触发 CAPTCHA 的信号永远不会同时出现。

下面是一个通过它获取 Google 搜索结果页面的简短可工作示例。首先安装依赖。

pip install requests

然后将你的 token 和编码后的 Google 搜索 URL 传递给 API。请求内置的 google-serp 解析器会返回结构化结果，而非原始 HTML，让你跳过自己解析页面的步骤。

import requests
from urllib.parse import quote_plus

TOKEN = "YOUR_CRAWLBASE_TOKEN"
KEYWORD = "best running shoes"

# Rotation, residential IPs, and JS rendering happen server-side.
target = f"https://www.google.com/search?q={quote_plus(KEYWORD)}"
resp = requests.get(
    "https://api.crawlbase.com/",
    params={
        "token": TOKEN,
        "url": target,
        "scraper": "google-serp",  # parsed SERP, not raw HTML
    },
)

data = resp.json()
for result in data.get("organic_results", []):
    print(result["position"], result["url"])

如果你更倾向于使用类型化客户端而非手动构建 URL，crawlbase SDK 封装了同一个端点。

from crawlbase import CrawlingAPI
from urllib.parse import quote_plus

api = CrawlingAPI({"token": "YOUR_CRAWLBASE_TOKEN"})

target = f"https://www.google.com/search?q={quote_plus('best running shoes')}"
resp = api.get(target, {"scraper": "google-serp"})

if resp["status_code"] == 200:
    print(resp["body"])

重点不在于具体的字段名；重点在于请求返回了结果而非挑战，因为轮换、受信任的 IP、匹配的请求头和渲染都已经为你处理好了。这与上面章节中描述的相同修复集合，只是通过一次调用来管理，而非你自己维护五个活动部件。

当挑战仍然出现时

即使经过调整的流量也会偶尔遇到挑战，尤其是在高流量或针对限制严格的地区时。将其视为反馈，而非失败。开始返回挑战或 429 错误的运行在告诉你，当前的 IP 层级或请求速率已经不够了：放慢速度，扩大 IP 池，或升级到更高的代理层级。像对待代理状态错误码一样，将你的状态码当作信号来读取。所有这些背后的数字（每个 IP 在挑战前的请求数、给定层级的成功率）都是随目标和服务商而变化的范围，因此要根据你自己的流量来调整，而不是依赖公开发布的基准。

这是被允许的吗？

只要你保持在合理范围内，抓取公开的 Google 搜索结果处于可辩护的位置。坚持公开数据（任何未登录访客都能看到的标题、链接和摘要）。遵守 Google 的服务条款和其 robots.txt 背后的速率预期，并相应地控制你的流量，而不是对它进行轰炸。不要收集个人数据，也不要尝试访问登录后的任何内容。保持工作清洁的界限与保持工作可持续的界限是一致的：公开结果、合理速率、无个人信息。

常见问题

抓取 Google 时如何绕过 CAPTCHA？

通过不触发它来绕过。Google 在你的流量看起来像自动化时显示 CAPTCHA，因此修复方案是看起来像一个普通访客：轮换住宅 IP 以防止任何单一地址被限速，发送与真实浏览器匹配的请求头，控制并随机化你的请求，并渲染 JavaScript。做好这些，挑战就根本不会出现。

当我抓取搜索结果时 Google 为何显示 CAPTCHA？

因为某些东西将你的流量标记为自动化。常见原因是来自同一 IP 的请求过多、声誉差的数据中心 IP、与声称的浏览器不匹配的请求头、没有 JavaScript 执行，或者没有会话连续性。Google 综合评估这些因素，同时在几个方面失败的请求会被挑战。

2Captcha 等 CAPTCHA 解决服务值得使用吗？

它们有效，但需要它们意味着你已经在上游的战斗中落败了。如果你在为解决挑战付费，你的流量已经触发了检测，你现在在每个请求上都在增加成本、延迟和一个脆弱的依赖。只有在你已经调整了 IP 来源、轮换、请求头、频率和渲染之后，将解决器作为罕见的最后手段才是合理的，而不应将其作为你的主要策略。

抓取 Google 时哪种代理类型最好？

轮换住宅代理。它们从 Google 视为普通访客的真实消费者 ISP 连接发出，轮换确保任何单一 IP 不会承载足够多的请求而被限速。数据中心 IP 更便宜，但解析到 Google 不信任的托管 ASN，因此会快速积累挑战，是一个糟糕的主要选择。

抓取 Google 搜索结果合法吗？

如果你只收集公开数据，遵守 Google 的服务条款和其 robots.txt 背后的速率预期，并避免收集个人数据或登录后的任何内容，抓取公开搜索结果通常是可以辩护的。当你忽视速率限制或收集个人信息时，风险会上升。将范围限制在公开的搜索结果数据上，并控制你的流量。

Crawlbase Crawling API 能在不遇到 CAPTCHA 的情况下抓取 Google 吗？

它被设计为防止挑战触发。Crawling API 轮换住宅 IP，发送一致的浏览器配置文件，渲染 JavaScript，并在服务器端管理请求，这与你本来需要手动组合在一起的修复集合相同。你发送一个带有 token 的 URL，得到的是结果而非挑战页面。

HR

Hassan Rehan

软件工程师 · Crawlbase

Crawlbase 软件工程师，撰写关于轮换代理、抓取，以及把代理接入真实代码的实战细节的实操指南。