使用 Smart AI Proxy 构建搜索引擎工具查询、路由、解析、循环往复

抓取少量搜索结果页面轻而易举。但每小时抓取数千个页面、持续运行而不被封锁，则是完全不同的问题。搜索引擎是为真实用户设计的，因此自动化流量很容易被识别：来自单一地址的请求很快就会遭遇 CAPTCHA、空页面或直接封禁，而且根据请求的来源地，返回的结果也会有所不同。任何搜索引擎工具最难的部分从来都不是解析，而是随着请求量增长，如何维持对源页面的稳定访问。

本指南将向你展示如何构建一个搜索引擎工具，通过将每个出站请求路由到 Crawlbase Smart AI Proxy，使其在规模化场景下保持稳定可靠。你将标准 HTTP 客户端指向一个端点，代理便会为你处理 IP 轮换、地理定向和反爬机制。你的代码负责查询逻辑和产品功能，Crawlbase 负责网络层面的可靠性。本文将首先介绍技术约束，然后构建一个完整可运行的 Python 工具，它能够查询搜索引擎、解析结果并返回结构化记录。

为什么大规模爬取搜索结果如此困难

明确说明哪里会出问题是有意义的，因为每种失败模式都指向你本来需要自行构建和维护的基础设施。

IP 封锁与封禁

当大量请求来自同一地址时，它们就会看起来很可疑。一旦超过某个阈值，响应就会变成报错、空页面或验证提示。一个云端实例在测试阶段可能运行良好，但一旦真实流量到来就会立刻崩溃，因为演示时适宜的请求量，正好触发了限制阈值。

地理限制与本地化结果

搜索结果并非放之四海而皆准。从伦敦发出的查询可能与从纽约或柏林发出的同一查询返回截然不同的排名和本地列表。如果你的产品依赖于特定地区的数据，你的请求就必须看起来像是从那些地区发出的，这意味着你需要控制每个请求的出口位置。

CAPTCHA 与反爬机制

现代搜索平台的防御是层层叠加的。即使某个请求在技术上以 200 成功响应，你得到的页面也可能是一个验证挑战，而非真实结果。要可靠地处理这一点，需要能随着检测系统更新而自适应的基础设施，而非一次性的修补。

速率限制与流量整形

来自可识别来源的高频流量会被限速或封锁。如果不将请求分散到多条路由，无论你的代码多么高效，吞吐量最终都会降为零。自行构建所有这些，意味着要运维代理池、监控失败、轮换地址并应对检测变化。对大多数团队来说，这是一种运维负担，而不是功能特性。

为什么代理轮换是正确的解决方案

Smart AI Proxy 位于你的应用与搜索引擎之间。你像配置普通代理一样配置它，正常发送请求，并像直接连接一样收到响应。区别在于每个请求都通过专为自动化数据采集构建的基础设施路由，因此上述失败模式不再是你需要操心的问题。

对于搜索工具来说，以下特性至关重要：

• 请求被分散到一个庞大的 IP 池，而非单一地址。
• 流量模式经过调优，以避免触发爬虫常见的封锁机制。
• 当你需要区域化结果时，可以按请求应用位置定向。
• 无需特殊客户端库，任何支持 HTTP 的语言均可使用。

可选行为通过请求头 CrawlbaseAPI-Parameters 控制。例如，就是通过这种方式为 Google 开启结构化解析，而无需更改你的请求逻辑。你需要的连接信息很简洁：

• HTTPS（推荐）：https://smartproxy.crawlbase.com:8013
• HTTP：http://smartproxy.crawlbase.com:8012
• 认证：将你的 Crawlbase token 作为代理用户名。

这个工具实际上做什么

一个搜索引擎工具由多个部分组成，但其中只有一个部分需要与外部搜索引擎通信。Smart AI Proxy 作为出站数据采集层位于该边界，使系统其余部分与封锁问题相互隔离。整个流程很简洁：

1. 用户提交查询。
2. 你的应用构建对应的搜索 URL。
3. 请求通过 Smart AI Proxy 发出。
4. 从搜索引擎取回结果。
5. 数据经过规范化后存储或展示。

由于所有出站请求都通过代理，扩容主要影响成本和处理容量，而不是可靠性。脆弱的部分（维持对源站的访问）在该边界处被一次性解决，之后随着业务增长不再发生变化。

配置环境

你需要 Python 3.8 或更高版本，以及一个第三方依赖。确认你的版本，创建虚拟环境以隔离安装，然后添加 requests。

python --version

python -m venv serp_env
source serp_env/bin/activate

pip install requests

在 Windows 上，用 serp_env\Scripts\activate 替换 source 那行来激活环境。你还需要 Crawlbase token，它同时作为代理认证密钥。注册后从控制台获取，并通过读取环境变量的方式使用，避免将其提交到版本控制。

export CRAWLBASE_TOKEN=your_crawlbase_token_here

第一步：接收并规范化查询

搜索引擎期望经过正确编码的参数。像 best coffee shops Paris 这样的原始用户输入，在进入 URL 之前必须变成合法的查询字符串。空格、特殊字符和非 ASCII 文本如果原样传入都会导致请求失败，因此要先对其编码。在 Python 中，这就是 quote_plus，它将原始字符串转换为 best+coffee+shops+Paris。将这一逻辑集中在一处是值得的，因为你后续支持的每个搜索引擎都需要这个步骤。

第二步：构建目标 SERP URL

以编程方式构建 URL，而不是在调用处手动拼接字符串。对于基本的 Google 查询，只需要 q 参数，但生产系统通常需要支持分页、语言标志、安全搜索设置、设备类型和区域定向。将 URL 构建集中在一处意味着，以后添加任何这些功能只需修改一个函数，而不用在整个代码库中逐一查找。

第三步：通过 Smart AI Proxy 路由请求

直接向搜索引擎发请求在高负载下很快就会失败，因此你需要将 HTTP 客户端配置为使用 Smart AI Proxy 作为出站网关。所需的组件包括：代理端点、使用 Crawlbase token 进行认证，以及你的 HTTP 库已经支持的标准代理配置。从应用的角度来看，这与任何企业代理的行为相同。区别在于请求会被透明地路由到为爬取工作负载调优的基础设施，从而在直接请求无法到达的地方畅通无阻。

第四步：请求结构化结果

Smart AI Proxy 可以帮你解析 HTML。在 CrawlbaseAPI-Parameters 请求头中传入 autoparse=true，响应就会以 JSON 而非原始 HTML 返回。对于 Google，该 JSON 包含自然搜索结果、广告、本地信息包和相关问题，以及状态字段。在大多数情况下，这完全省去了手动解析 HTML 的工作，这也是当搜索引擎调整布局时少一个脆弱点。

第五步：在使用前验证响应

生产代码应在接触响应数据之前确认请求成功。通常的检查包括：HTTP 状态码、代理状态指示器、预期字段是否存在，以及针对瞬时故障的重试逻辑。下面的示例用 raise_for_status() 做了基本版本的处理，它将失败的 HTTP 响应转换为你可以捕获的异常，而不是在下游产生静默的错误解析。

第六步：构建端到端的抓取器

以下是一个最简的 Google SERP 抓取器，它将 Smart AI Proxy 作为访问 Google 的唯一通道。它用你的 token 配置代理，向 Google 搜索 URL 发送 GET 请求，并传入 autoparse=true，使响应为结构化 JSON。你会得到 original_status、pc_status、请求的 url，以及包含解析结果的正文。我们省略了国家参数，使这段代码无需任何地理定向即可在标准套餐上运行。

import json
import os
import requests
from urllib.parse import quote_plus
from urllib3.exceptions import InsecureRequestWarning

requests.packages.urllib3.disable_warnings(category=InsecureRequestWarning)

def fetch_google_serp(token, query):
    proxy = f"https://{token}:@smartproxy.crawlbase.com:8013"
    proxies = {"http": proxy, "https": proxy}
    url = f"https://www.google.com/search?q={quote_plus(query)}"
    headers = {"CrawlbaseAPI-Parameters": "autoparse=true"}
    response = requests.get(url, headers=headers, proxies=proxies, verify=False, timeout=30)
    response.raise_for_status()
    return json.loads(response.text)

if __name__ == "__main__":
    token = os.environ.get("CRAWLBASE_TOKEN", "YOUR_CRAWLBASE_TOKEN")
    data = fetch_google_serp(token, "best coffee shops Paris")
    print(f"Returned keys: {list(data.keys())}")

这个函数是整个系统的数据采集核心。它可以运行在 API 端点后面、工作队列中，或按计划执行，每次都返回相同的结构化数据。其中 quote_plus 调用对应第一步的规范化，URL 对应第二步的构建，proxies 字典对应第三步的路由，请求头对应第四步的结构化解析，而 raise_for_status 对应第五步的验证。六个步骤，一个函数。

第七步：将 JSON 转换为结构化记录

自动解析的负载内容丰富，但你的产品很少需要其中的全部内容。下一步是提取正文并将其重塑为你的存储和排序代码所期望的精简记录。下面的函数将自然搜索结果提取为包含排名、标题、URL 和摘要的可预期字典列表，当字段缺失时优雅地回退，以避免一条异常结果拖垮整批数据。

def to_records(serp, query):
    body = serp.get("body", {})
    results = body.get("searchResults", [])
    records = []
    for rank, item in enumerate(results, start=1):
        records.append({
            "query": query,
            "rank": rank,
            "title": item.get("title", ""),
            "url": item.get("url", ""),
            "snippet": item.get("description", ""),
        })
    return records

if __name__ == "__main__":
    token = os.environ.get("CRAWLBASE_TOKEN", "YOUR_CRAWLBASE_TOKEN")
    query = "best coffee shops Paris"
    serp = fetch_google_serp(token, query)
    rows = to_records(serp, query)
    print(json.dumps(rows[:3], indent=2))

输出是一个干净、一致的结构，你可以直接写入数据库、送入排序步骤，或从你自己的 API 返回。在早期就规范化为这样的结构，使你以后切换或新增搜索引擎时，无需重写下游的所有逻辑。

[
  {
    "query": "best coffee shops Paris",
    "rank": 1,
    "title": "The 10 Best Coffee Shops in Paris",
    "url": "https://example.com/paris-coffee",
    "snippet": "Our guide to the best specialty coffee in the city..."
  }
]

第八步：接入你的应用

有了抓取器和规范化器，数据就可以流向你正在构建的任何产品：自定义搜索界面、竞争分析工具、SEO 监控仪表板、市场调研数据集，或用于训练模型的数据。大多数系统会在存储前将数据规范化为一致的结构（正是第七步所产生的），使分析和排序有一个稳定的格式可依。关键在于，你的应用其余部分永远不必处理代理、CAPTCHA 或布局变化，它只处理记录。

在不破坏工具的前提下扩展

扩展一个 SERP 工具是一个在四个维度上协调的问题，而代理层使每个维度都变得可控。

并发。 运行一个任务队列，让多个 worker 都通过同一个代理端点发出请求。轮换将流量分散到独立路由，因此并发提升的是吞吐量，而不是封锁率。更详细的内容见如何轮换代理以爬取 Google 搜索结果。

地理和设备差异。 当你需要区域化数据时，在请求之间改变位置参数。相同的查询根据来源地的不同可能返回截然不同的结果，这是一个可以善加利用的特性，而非需要绕开的问题。

速率与成本控制。 即使有了代理层，无节制的流量也会制造不必要的失败或产生额外费用。简单的客户端侧节流通常能解决这个问题，让你在合理的限制范围内运行，而无需复杂的协调机制。

弹性。 偶发的瞬时错误是预料之中的。采用退避重试策略，并关注状态码，避免一次暂时的抖动级联成更大的故障。更广泛的反封锁手册在如何在不被封锁的情况下爬取网站中。

上线前值得了解的限制

这种方案是一个很好的默认选择，但并非万能。有几点需要记住。

自动解析覆盖常见引擎，但并非所有页面。 结构化解析对 Google 及类似 SERP 非常有效，但如果你爬取的是小众或不寻常的结果页面，可能仍需自行解析 HTML。这完全没问题，只需通过同一代理路由原始请求，然后在本地解析即可。

重度渲染需要浏览器。 如果目标在客户端渲染结果或有更严格的验证挑战，原始 HTML 就不够用了。这时就需要将该请求切换到 Crawling API 进行真实浏览器渲染，同时保持工具其余部分不变。

成本随请求量增长。 可靠性是恒定的，但请求不是免费的。节流、缓存重复查询，只保留你的产品实际需要的字段，避免为永远用不到的数据付费。关于 Google 上 CAPTCHA 的特殊边缘情况，爬取 Google 时绕过 CAPTCHA有更深入的讲解。

常见问题

构建一个不会被封锁的搜索引擎工具，最简单的方式是什么？

将所有出站请求通过轮换代理路由，而不是直接访问搜索引擎。Smart AI Proxy 以即插即用的端点形式提供这一能力：你将 HTTP 客户端配置为使用它，发送普通的 GET 请求，它就会将流量分散到多个 IP，同时吸收反爬机制。你的代码专注于查询逻辑和产品功能，而不是代理维护。

我需要自己解析 HTML 吗？

对于常见搜索引擎，通常不需要。在 CrawlbaseAPI-Parameters 请求头中传入 autoparse=true，Smart AI Proxy 就会返回包含自然搜索结果、广告、本地信息包和相关问题的结构化 JSON。只有对那些没有现成解析器的不寻常结果页面，才需要回退到手动解析，即便如此，你也是通过同一代理路由原始请求。

使用 Smart AI Proxy 时为什么要关闭 SSL 验证？

代理需要检查流量以应用路由逻辑和响应处理，因此目标站点的 SSL 验证通常会被关闭。在 Python 中，这意味着在请求时设置 verify=False。它仅适用于通过代理的流量，不会影响你应用的其他连接，而且 Python 打印的警告可以按示例所示的方式静默。

何时应该使用 Crawling API 而非 Smart AI Proxy？

默认情况下，使用 Smart AI Proxy 进行标准 HTTP 客户端的大批量 SERP 抓取。当目标在客户端渲染结果或有更严格的验证挑战时，改用 Crawling API，因为它在真实浏览器中渲染页面并返回完整的 HTML 或 Markdown。许多工具对大多数查询使用代理，对少数顽固目标使用 Crawling API。

如何获取特定地区的搜索结果？

搜索结果因地理位置而异，因此要获取区域化数据，需要在请求中改变位置定向。从不同地区发出的同一查询会返回不同的排名和本地列表，你可以有意识地将其用于本地化产品。地理定向是一项高级功能，因此基础示例省略了国家参数，以便在标准套餐上直接运行。

我可以使用 Python 以外的语言吗？

可以。Smart AI Proxy 适用于任何能发送标准 HTTP 请求的语言，因为它是一个普通的代理端点，不需要特定的客户端库。本文使用 Python 是因为它便于本地运行，但相同的模式（配置代理、发送请求、解析 JSON）同样适用于 Node.js、Go、Java、C# 等语言。

IK

Ian Kalvin

技术支持工程师 · Crawlbase

Crawlbase 技术支持工程师，从生产环境抓取与代理配置中真正出问题的第一线写作。

NZ

Neil Zamora

高级架构师 · Crawlbase

Crawlbase 高级架构师，专注大规模爬取背后的系统：代理轮换、反机器人韧性，以及隐藏这些复杂性的 API。