スクラプリング、ボタサウルス、ノードライバーのプロキシ設定

クラウドフレア、DataDome、PerimeterXレベルのアンチボットシステムに対して、従来のSeleniumとPuppeteerの組み合わせはますます障害に直面しています。それに代わって、新しいフレームワークであるScrapling、Botasaurus、nodriverが登場しました。これらは最初から検出回避に重点を置いて設計されています。しかし、最も進んだフレームワークでも、正しく設定されたプロキシがなければ無意味です。この記事では、3つのツールそれぞれでプロキシを接続する方法、効果を損なうエラー、特定のスクレイピングタスクに適したIPの選び方を解説します。

Scrapling、Botasaurus、nodriverはSeleniumと何が違うのか

これらの3つのフレームワークは、Seleniumや通常のPuppeteerがあまりにも簡単に検出されるようになったことへの回答として登場しました。アンチボットシステムは、CDPプロトコル、navigator.webdriver、canvasのレンダリング、イベントのタイミングなど、数十のパラメータをチェックします。そして、従来のドライバーはほぼすべてのパラメータに特徴的な痕跡を残します。

Scraplingは、StealthyFetcherを介してブラウザをエミュレートするHTMLの適応型パースを組み合わせたPythonライブラリです。これは、リソース消費を最小限に抑えつつ迅速なパースが必要なタスクに適していますが、サイトの保護がTLSフィンガープリントを積極的にチェックしている場合に特に有効です。

Botasaurusは、改良されたChromium（undetected-chromedriverが内部で動作）をベースにしたフレームワークで、大規模な並列スクレイピングに特化しており、ブラウザのプロファイルを自動的に管理し、外部サービスを介してCAPTCHAを解決する機能を内蔵しています。

nodriverは、同じ著者によるundetected-chromedriverの後継で、Selenium WebDriverを完全に放棄し、CDP（Chrome DevTools Protocol）を介して直接動作します。これにより、検出可能な自動化のアーティファクトの大部分が除去されます。

これら3つの共通点は、ブラウザーフィンガープリントレベルでの検出を減少させることですが、IPの評判の問題を解決するわけではありません。もしリクエストがすでにDataDomeやCloudflareのブラックリストに載っているデータセンターのIPから行われる場合、ブラウザのパッチではCAPTCHAや403エラーからは守れません。

Scraplingでのプロキシ設定

Scraplingは、迅速なHTTPモード（Fetcher）とブラウザーモード（StealthyFetcher）の両方でプロキシをサポートしています。 JSレンダリングなしで静的にパースする場合、プロキシはリクエストパラメータに直接渡されます：

from scrapling.fetchers import Fetcher

response = Fetcher.get(
    "https://example.com",
    proxy="http://user:[email protected]:9000"
)
print(response.status)

完全なブラウザーモード（Camoufox上のStealthyFetcher）では、プロキシはサーバー、ユーザー名、パスワードの個別のフィールドを持つ辞書を介して渡されます。これは重要で、Camoufoxは通常のChromiumとは異なる方法でプロキシの認証を処理します：

from scrapling.fetchers import StealthyFetcher

response = StealthyFetcher.fetch(
    "https://example.com",
    proxy={
        "server": "gate.proxycove.com:9000",
        "username": "user",
        "password": "pass"
    },
    headless=True
)
print(response.status)

よくあるエラーは、ブラウザーモードでプロキシを全体として渡すことです。Camoufoxはこの場合、認証を無視するか、プロキシサーバーへの接続時にタイムアウトします。 ERR_NO_SUPPORTED_PROXIESエラーが表示された場合は、必ず辞書形式の個別フィールドのフォーマットを確認してください。

Botasaurusでのプロキシ設定

Botasaurusは、ドライバーの設定に@browserデコレーターを使用し、プロキシはこのデコレーターのパラメータとして、または起動関数に直接渡されます：

from botasaurus.browser import browser, Driver

@browser(
    proxy="http://user:[email protected]:9000"
)
def scrape_data(driver: Driver, data):
    driver.get("https://example.com")
    return driver.page_html

scrape_data()

各並列タスクに異なるプロキシを接続する必要がある場合（Botasaurusを使用した大規模なスクレイピングでは重要です）、プロキシはデコレーターにハードコーディングするのではなく、データリストを介して動的に渡す方が良いです：

from botasaurus.browser import browser, Driver

@browser
def scrape_with_proxy(driver: Driver, data):
    driver.config.proxy = data["proxy"]
    driver.get(data["url"])
    return driver.page_html

tasks = [
    {"url": "https://example.com/page1", "proxy": "http://user:pass@ip1:port"},
    {"url": "https://example.com/page2", "proxy": "http://user:pass@ip2:port"},
]
scrape_with_proxy(tasks)

Botasaurusはmultiprocessingを介してタスクを優れた並列処理を行うため、大規模なスクレイピングでは十分なIPプールを持つプロキシを使用することが重要です。さもなければ、複数のスレッドが同じアドレスにアクセスし、リクエストの頻度パターンによって自動化が即座に検出されます。

nodriverでのプロキシ設定

nodriverはSeleniumのレイヤーなしでCDPに直接接続するため、プロキシはブラウザの起動引数を介して設定され、別のAPIを介してではありません。認証なしのプロキシの場合は非常に簡単です：

import nodriver as uc
import asyncio

async def main():
    browser = await uc.start(
        browser_args=["--proxy-server=http://gate.proxycove.com:9000"]
    )
    page = await browser.get("https://example.com")
    await asyncio.sleep(3)
    browser.stop()

asyncio.run(main())

問題は、Chromiumが--proxy-serverを介してプロキシのログイン/パスワードを直接サポートしていないことです。 nodriverで認証されたプロキシを使用するには、認証なしのローカルプロキシトンネルを立てるか（例えば、pxや3proxyを介して）、CDPイベントFetch.authRequiredを処理する必要があります：

import nodriver as uc
import asyncio

async def main():
    browser = await uc.start(
        browser_args=["--proxy-server=http://gate.proxycove.com:9000"]
    )
    page = await browser.get("https://example.com")

    async def auth_handler(event):
        await page.send(uc.cdp.fetch.continue_with_auth(
            request_id=event.request_id,
            auth_challenge_response=uc.cdp.fetch.AuthChallengeResponse(
                response="ProvideCredentials",
                username="user",
                password="pass"
            )
        ))

    page.add_handler(uc.cdp.fetch.AuthRequired, auth_handler)
    await asyncio.sleep(5)
    browser.stop()

asyncio.run(main())

これは3つのフレームワークの中で最も明白でない点です。多くの開発者は、なぜ認証が単に機能しないのかを理解するのに何時間も費やしますが、CDPのFetchドメインについて知らないからです。

プロキシのローテーションとアンチボット対策

完璧に設定されたブラウザーフィンガープリントでも、1つのIPに対して保護されたドメインに50〜100件以上のリクエストがある場合は救われません。 DataDomeやCloudflareは、特定のアドレスからのリクエストの頻度とアクション間の時間パターンを分析します。あまりにも均一な間隔も疑わしいです。

すべての3つのフレームワークにおけるローテーションの作業スキームは同じように構築されます：

プロバイダーのレベルで自動IPローテーションを持つゲートウェイを使用します。リクエストごとにアドレスを変更するロジックを書く必要はありません。
セッションタスク（ログイン、多ページナビゲーション）の場合、接続文字列のstickyパラメータを介してセッションごとにIPを固定します。
静的ページの単純なパースの場合、リクエストごとまたは5〜10リクエストごとにIPをローテーションします。
リクエスト間にランダムな遅延を追加します（1〜4秒） — これにより、時間パターンによる検出が減少します。

接続文字列におけるstickyセッションの例で、session-idが10分間同じ外向きIPを保持します：

proxy = "http://user-session-abc123:[email protected]:9000"

Botasaurusにとって、このスキームは特に有用です。なぜなら、並列スクレイピング中に各プロセスが独自のsession-idを取得でき、アドレスリストを手動で管理することなく、さまざまなIPの安定したプールを得ることができるからです。

各フレームワークに適したプロキシの種類

プロキシの種類は、フレームワークの選択と同じくらいパースの成功に影響を与えます。以下はタスクごとの比較です：

タスク	推奨プロキシタイプ	理由
Cloudflare/DataDomeを使用したサイトのパース	居住用プロキシ	実際の家庭ユーザーのIPは、アンチボットのブラックリストに載ることはほとんどありません。
厳しい保護がない大規模なパース	データセンターのプロキシ	リクエストの大規模なボリュームに対して、速度が高く、コストが低いです。
モバイルサイトでの実際のユーザーのエミュレーション	モバイルプロキシ	通信事業者のCGNATアドレスは、アンチボットに対して最大の信頼レベルを持っています。

ScraplingのStealthyFetcherモードでは、居住用プロキシが最も効果的です。なぜなら、Camoufoxがブラウザのフィンガープリントの問題をすでに解決しているからです。 Botasaurusでは、大規模な並列スクレイピングの場合、ターゲットサイトがDataDomeレベルの高度な保護を使用していない限り、データセンターのプロキシが速度と価格のバランスで最適です。

プロキシとブラウザ自動化の組み合わせにおける典型的なエラー

実際には、ほとんどのパースの失敗はフレームワーク自体ではなく、プロキシの不適切な設定に関連しています。以下は最も一般的なエラーのリストです：

Botasaurusのすべての並列スレッドに同じIPを使用する。 アンチボットは、1つのアドレスから20の同時セッションを検出し、数分でブロックします。
Scraplingのブラウザーモードでプロキシを文字列として渡す。 Camoufoxは分割されたフィールドを持つ辞書を要求します — そうでなければ認証は通りません。
nodriverでCDP Fetchドメインを無視する。 authRequiredハンドラーがないと、認証されたプロキシは接続できず、ブラウザは読み込み中にハングします。
セッションアクションでのローテーションの欠如。 認証されたセッションの途中でIPを変更すると、自動化が即座に検出されます — stickyセッションを使用してください。
プロキシのジオロケーションとブラウザのロケールが一致しない。 ドイツのIPがAccept-Language: ruヘッダーを持つ場合 — これは詐欺スコアリングシステムにとって典型的なボットの兆候です。
ローテーションがあってもリクエストの頻度があまりにも攻撃的である。 IPのローテーションは、リクエスト間に休止を取る必要を取り消すものではありません — 行動パターンも分析されます。

ブラウザーモードでプロキシを使用する際には、DNSリークを別途確認する必要があります。時々、ブラウザはシステムDNSを介してドメインを解決し、プロキシトンネルを介してではなく、リクエストのIPと解決のIPの間に不整合を生じさせます。これは保護システムによって簡単に検出されます。

結論

Scrapling、Botasaurus、nodriverは、ブラウザーフィンガープリントレベルでの検出問題を従来のSeleniumよりもはるかに良く解決しますが、どれも質の高いプロキシの重要性を無視するものではありません。正しい認証設定（特にnodriverでのCDPを介して）、適切なIPローテーション、特定のアンチボットシステムに適したプロキシタイプの選択 — これら3つの要素が、長期的なパースの安定性を決定します。

CloudflareやDataDomeのような高度な保護を持つサイトをパースする場合は、居住用プロキシから始めてください — これらはIPの評判によって成功リクエストの割合が最も高いです。厳しい保護がない大規模なタスクの場合、データセンターのプロキシは、速度とコストのバランスで最適な選択肢です。