用代理爬取 Google 搜尋結果（SERP，2026）

Google 是主流目標中最難爬取的一個，理由很簡單：它看到的流量比任何人都多，因此它對「一個真實搜尋者長什麼樣子」擁有最豐富的模型。在任何流量規模下從機房 IP 命中它，你都會拿到 429、一個「sorry/index」頁面，或是一種軟封鎖 — 結果會悄悄變得稀疏。本指南涵蓋真正觸發 Google 封鎖的因素，以及在 2026 年讓一個 SERP 爬蟲存活的代理與限速策略。

什麼會觸發 Google 封鎖

Google 不倚賴單一訊號 — 它疊加多個訊號，當綜合分數越過某條線時便封鎖：

• IP/ASN 信譽 — 機房 IP 段（AWS、GCP、Hetzner、OVH）會被立刻評定為自動化。這是 SERP 爬取最關鍵的單一因素。
• 每個 IP 的請求速率 — 從一個 exit 太快發出太多查詢，是經典的觸發點。Google 容忍人類的節奏，而非迴圈的節奏。
• 查詢指紋 — 相同的參數、沒有 cookie、沒有 referer、以機器速度循序分頁。
• 無 JS / headless 破綻 — Google 越來越常提供需經 JS 處理的版面；純 HTML 抓取可能看起來陳舊，或觸發一道同意/挑戰牆。

在這裡住宅 IP 沒得商量

對多數目標而言，在公開資料上你可以靠機房 IP 矇混過去。Google 是例外：它的 ASN 信譽評分激進到足以讓機房代理幾乎立刻被節流。住宅 exit — 真實的消費者 ASN — 才是讓一個 SERP 爬蟲撐住流量的關鍵。把機房 IP 留給其他一切，把住宅預算花在真正能起作用的地方。

輪換，但要對每個 exit 限速

輪換能分散負載，讓任何單一 IP 都不像機器人，但讓你存活下來的紀律是每個 exit的速率，而不只是 pool 的大小。即使有一千個代理，只要你把它們全速火力全開，照樣會被封。把每個 exit 都調成像一個真人的步調：

import time, random, itertools
from curl_cffi import requests   # browser TLS fingerprint, see notes below

PROXIES = [
    "socks5h://USERNAME:[email protected]:913",
    "socks5h://USERNAME:[email protected]:913",
]
pool = itertools.cycle(PROXIES)

def serp(query, page=0):
    proxy = next(pool)
    params = {"q": query, "start": page * 10, "hl": "en"}
    r = requests.get("https://www.google.com/search", params=params,
                     impersonate="chrome",
                     proxies={"http": proxy, "https": proxy}, timeout=30)
    if r.status_code == 429 or "/sorry/" in r.url:
        raise RuntimeError("rate-limited - back off and rotate")
    return r.text

for q in queries:
    html = serp(q)
    parse(html)
    time.sleep(random.uniform(2.0, 5.0))   # human-paced gap between queries

那個隨機化的延遲是在做實事：一個固定的 sleep(3) 本身就是一種指紋。讓它有變化，並把查詢分散到各個 exit，使每一個都維持在 Google 的每個 IP 門檻之下。

sticky 工作階段與地理位置

在地化結果（排名、語言、貨幣）取決於 exit 的所在地，所以要挑選你想要衡量的地理區裡的代理，並對一個多頁查詢維持一個 sticky 工作階段，讓一次搜尋的所有分頁都來自同一個地方。在查詢途中混用 exit，會給你一份由不同地區拼湊而成的結果 — 對排名追蹤毫無用處。

別忘了指紋

Google 也會讀你的 TLS 交握。一個樸素的 requests 呼叫送出的 JA3 大喊著 Python，這會加重 IP 評分。用 curl_cffi（如上所用）或一個真實瀏覽器送出真實的瀏覽器指紋 — 參見 用 curl_cffi 繞過 TLS 指紋偵測。如果 Google 開始用一道 JS 同意牆來把關，就升級到一個真實的瀏覽器引擎，如 Turnstile 指南所述 — 同樣的「需要一個 JS 執行環境」邏輯也適用。

優雅地處理封鎖

• 429 / /sorry/ — 停止命中那個 exit，輪換，並以指數方式退避。猛敲一個被標記的 IP 會延長封鎖。
• 結果變稀疏 — 一種軟封鎖。在它變成硬封鎖之前先放慢。
• 同意牆 — 處理那個 cookie/同意重新導向，或切換到一個瀏覽器引擎。

檢查清單

• 使用住宅 exit — 機房 IP 在 Google 上幾乎立刻被節流。
• 對每個 exit限速，而不只是對 pool；隨機化查詢之間的間隔。
• 送出瀏覽器的 TLS 指紋；別讓一個 Python JA3 疊加到 IP 評分上。
• 讓 exit 地理區與你所衡量的地區相符；對多頁查詢使用 sticky 工作階段。
• 遇到 429 / /sorry/ 就大力退避，而不是重試進一段更長的封鎖。
• 具備 sticky 工作階段的乾淨住宅 exit：jibaoproxy.com，住宅 $2/GB，500M免費流量可在你自己的查詢上測試。