あなたはパーサーを設定し、データ収集を開始しました。そして数分後、キャプチャが表示されたり、空の応答が返ってきたりします。おそらく、そのサイトはDataDomeによって保護されています。これは市場で最も攻撃的なアンチボットシステムの1つであり、通常のデータセンタープロキシでは役に立ちません。この記事では、DataDomeがどのようにボットを検出し、どのタイプのプロキシが効果を発揮するかを詳しく見ていきます。
DataDomeとは何か、どこで使用されているか
DataDomeは、世界中の大手オンラインストア、ニュースポータル、マーケットプレイス、予約サービスが使用する商業用のSaaSボット保護プラットフォームです。2015年に設立され、現在は数十億のリクエストを処理する数千のサイトを保護しています。
DataDomeのクライアントには、Reddit、Foot Locker、Rakuten、AngelListなどのプラットフォームが含まれています。競合の価格監視、商品カードのパーシング、海外マーケットプレイスからのデータ収集、ニュースの集約を行っている場合、このシステムに遭遇した可能性が高いです。
DataDomeによって保護されているサイトの特徴的な兆候は次のとおりです:
- 数回の連続リクエスト後にキャプチャページが表示される
- サーバーの応答に
x-datadome-cidヘッダーが含まれている geo.captcha-delivery.comドメインへのリダイレクト- 1つのIPからの頻繁なリクエストでHTTP応答が403または429
- 最初の訪問時にJavaScriptチャレンジ(「ブラウザチェック」ページ)
DataDomeはリアルタイムで動作します:各リクエストはミリ秒単位で分析されます。システムは、ユーザーを通過させるか、キャプチャを表示するか、またはブロックするかを決定します。これが、単純なIPブロックよりも回避が難しい理由です。
DataDomeはどのようにボットを識別するか:保護メカニズム
どのプロキシが機能するかを理解するためには、DataDomeが何を分析しているかを理解する必要があります。システムは多層的なアプローチを使用しており、どの要因もブロックの唯一の基準ではありません。決定は、信号の組み合わせに基づいて行われます。
1. IPアドレスの評判
DataDomeが最初に確認するのは、外部および内部のデータベースに基づくIPアドレスの評判です。システムは、IPがデータセンター(AWS、Google Cloud、Hetzner、DigitalOcean)に属しているか、VPNプロバイダーに属しているか、または実際の家庭用/モバイルアドレスであるかを瞬時に判断します。データセンターのIPは、行動分析の前に自動的に高い「疑わしさスコア」を取得します。
2. 行動分析
DataDomeは行動パターンを追跡します:リクエストの速度、ページ訪問の順序、クリック間の時間、マウスの動き(JavaScriptがある場合)。実際のユーザーは、間隔を置いて論理的なルートをたどり、時には戻ります。ボットは通常、一定の間隔でリクエストを行い、厳密に定義されたURLに従い、「ランダム」な逸脱がありません。
3. JavaScriptフィンガープリンティング
リクエストがブラウザ(またはPuppeteer/Playwrightのようなヘッドレスブラウザ)を介して行われる場合、DataDomeは環境の「フィンガープリント」を収集するJavaScriptスクリプトを実行します:ブラウザのバージョン、インストールされているフォント、画面の解像度、WebGLのサポート、キャンバスフィンガープリンティング、プラグインの有無。追加のマスキングなしのヘッドレスブラウザは、特有のパラメータで簡単に特定されます。
4. HTTPヘッダー
リクエストのヘッダーが分析されます:User-Agent、Accept-Language、Accept-Encoding、Referer、sec-ch-uaなど。宣言されたUser-Agentと実際のリクエストパラメータとの不一致は、ボットの強い信号です。
5. リアルタイムの機械学習
収集されたすべての信号は、実際のユーザーとボットに関する膨大なデータセットで訓練されたMLモデルによって処理されます。モデルは常に更新されており、1ヶ月前に機能していたものが、今日には機能しなくなることがあります。これが、静的な解決策がすぐに陳腐化する理由です。
なぜデータセンタープロキシはDataDomeに対して機能しないのか
これは、保護されたサイトで作業を始めたばかりの人々からの最も一般的な質問です。データセンタープロキシは安価で、高速で、高いアップタイムを持っています。一見、パーシングに最適な選択のように思えます。しかし、DataDomeに対してはほとんど役に立ちません。
理由は簡単です:DataDomeは、すべての主要なホスティングプロバイダーのASN(自律システム)データベースを管理し、使用しています。リクエストが例えばAmazon Web ServicesやOVHに属するサブネットから来ると、システムはすぐに「疑わしい」ステータスを付与します。たとえあなたのパーサーが人間の行動を完璧に模倣していても、データセンターのIPはあなたを危険にさらします。
⚠️ 重要な理解
データセンタープロキシは、保護が弱いか存在しないタスクに最適です:オープンデータのパーシング、アンチボットシステムなしのAPI作業、速度テストなど。しかし、DataDomeを持つサイトでは、最初の数十のリクエストで90%以上の確率でブロックされます。
もう一つの問題は「焼かれた」IPです。もし何千人ものユーザーがそのIPアドレスをボット活動に使用していた場合(安価なデータセンターのプールではこれが一般的です)、DataDomeはすでにそのアドレスに対してネガティブな履歴を持っています。そのようなIPからの最初のリクエストでもブロックされる可能性があります。
レジデンシャルプロキシ:バイパスのための主要なツール
レジデンシャルプロキシは、実際の家庭用インターネットユーザーに属するIPアドレスです。これらはインターネットサービスプロバイダー(ロステレコム、コムキャスト、ドイツテレコムなど)によって提供され、DataDomeの観点からは、コンピュータの前に座っている普通の人々のように見えます。
そのため、レジデンシャルプロキシはDataDomeを持つサイトのパーシングのための主要な作業ツールです。これらはIPの評判に関する初期チェックを通過し、今後の作業のための「信用」を提供します。
DataDome用のレジデンシャルプロキシを選ぶ際の考慮事項
| パラメータ | 重要な点 | なぜこれが重要か |
|---|---|---|
| ローテーションタイプ | 各リクエストごとのローテーションまたは5-30分のセッション | DataDomeはIPの履歴を追跡します — あまりにも頻繁な変更も疑わしいです |
| ジオロケーション | ターゲットサイトの国からのIP | 他の国からのリクエスト — 追加の疑わしさの信号 |
| プールのサイズ | 数百万のIP、数千ではない | 小さなプールはすぐに「焼かれ」ます — DataDomeはアクティブなアドレスを記憶します |
| スティッキーセッション | 1つのIPを10-30分保持する能力 | マルチページパーシングの場合、1つのセッションは1人のユーザーのように見える必要があります |
| 速度 | 接続あたり5-10 Mbps以上 | 遅いプロキシはリクエストの時間を増加させ、タイミングに影響を与えます |
重要な点:レジデンシャルプロキシは、単独でDataDomeを100%バイパスすることを保証しません。これらはIPの評判の問題を解決しますが、あなたのパーサーが1つのアドレスから1分間に100リクエストを行ったり、不正なヘッダーを送信したりすると、DataDomeは依然としてブロックします。IPは保護のレベルの1つに過ぎません。
モバイルプロキシ:最大の信頼が必要な場合
モバイルプロキシは、モバイルオペレーター(4G/5Gネットワーク)のIPアドレスです。これらは特別な特性を持っています:1つのモバイルオペレーターのIPアドレスは、NATを介して同時に数千の実際のユーザーによって使用される可能性があります。DataDomeはこれを知っており、そのためモバイルIPに対して最大の信頼を寄せています。
モバイルIPをブロックすることは、オペレーターの潜在的な数千の実際の顧客をブロックすることを意味します — どの正常なサイトもこれを行うことはありません。したがって、モバイルプロキシは、DataDomeを持つサイトへのリクエストの成功率が最も高くなります。
モバイルプロキシをレジデンシャルプロキシの代わりに選ぶべき場合:
- サイトが非常に攻撃的に保護されている — レジデンシャルプロキシは、リクエストの頻度が低くてもブロックされます
- モバイル版サイトをパーシングしている — モバイルIP + モバイルUser-Agentは自然に見えます
- アプリケーションとの作業が必要 — モバイルAPIをパーシングする場合、モバイルIPはリクエストに論理的に対応します
- 長期的なセッション — モバイルプロキシはIPを変更せずにセッションを保持します
モバイルプロキシの欠点は、レジデンシャルプロキシよりも高価で、通常はIPプールが小さいことです。数千のリクエストを処理する大規模なパーシングでは、これが制約になる可能性があります。このような場合、最適な戦略は、モバイルプロキシを「偵察」と複雑なページに使用し、レジデンシャルプロキシを大量のデータ収集に使用することです。
ローテーションと遅延の戦略:良いプロキシでもバレずに済む方法
レジデンシャルまたはモバイルプロキシを使用していても、リクエストの戦略を誤るとブロックされることがあります。DataDomeはセッションレベルでの行動を分析し、異常なパターンはIPの質に関係なく疑わしいと見なされます。
DataDomeを介した安全なパーシングのルール
✅ 安全なパーシングのチェックリスト
- リクエスト間の遅延:3〜15秒(ランダム、固定ではない)
- 1つのIPからのセッションあたりのリクエストは20〜30を超えない
- スティッキーセッション:1つの「ユーザーパス」に対して1つのIPを保持する
- 常にホームページから始め、次にターゲットURLに移動する
- 実際のナビゲーションを模倣する:ホーム → カテゴリ → 商品
- サイトの言語と一致するプロキシのジオロケーションを使用する
- 各セッションの後またはブロック後にIPを変更する
- 1つのIPから並行リクエストを開始しない
ローテーション:IPを変更するタイミング
ここには普遍的な答えはありません — すべては特定のサイトに依存します。しかし、一般的な論理は次のとおりです:DataDomeはIPのアクティビティをスライディングウィンドウで記憶します(通常は10〜60分)。その時間内に1つのアドレスから疑わしいほど多くのリクエストが来ると、IPは一時的なバンを受けます。
最適な戦略は、タイマーではなくリクエストの数に基づいてIPをローテーションすることです。例えば:15〜25リクエスト → IPを変更 → 30〜60秒の休止 → 新しいセッション。このアプローチは、異なるユーザーの行動を模倣し、それぞれが数ページを訪れて去ったかのように見えます。
ヘッダーとフィンガープリンティング:DataDomeがIP以外に何をチェックするか
良いプロキシは必要不可欠ですが、DataDomeをバイパスするための十分条件ではありません。システムはリクエスト全体を分析します。IPがレジデンシャルであっても、ヘッダーがボットを示す場合、ブロックは依然として発生します。
重要なヘッダー
DataDomeがHTTPヘッダーでチェックする内容と注意すべき点は次のとおりです:
| ヘッダー | チェックされる内容 | 典型的なエラー |
|---|---|---|
User-Agent |
最新のブラウザバージョン | 古いUAまたはPythonライブラリのUA |
Accept-Language |
言語がプロキシのジオと一致する | プロキシが米国にあり、言語がru-RU |
sec-ch-ua |
User-Agentに一致する | Chromeが宣言されているのにヘッダーがない |
Referer |
論理的な遷移のチェーン | Refererなしで深いページへの直接リクエスト |
Accept-Encoding |
標準的なブラウザセット | 欠如または非標準のセット |
Cookie |
DataDomeのセッションクッキーを保持する | DataDomeからのSet-Cookieを無視する |
特にDataDomeのクッキーに注意してください。最初のリクエストで、システムは自分のクッキー(通常はdatadomeと呼ばれます)を設定します。あなたのパーサーがこのクッキーを保存せず、後続のリクエストで送信しない場合、DataDomeは各リクエストを新しいユーザーの最初の訪問として認識し、高頻度であること自体が疑わしいと見なされます。
TLSフィンガープリンティング
DataDomeの高度な保護は、TLSフィンガープリンティングも分析します — SSL/TLSハンドシェイクの特性。異なるHTTPライブラリ(requests、curl、axios)は、ブラウザとは異なる特有のcipher suitesとTLS拡張を持っています。標準のPythonライブラリrequestsを使用している場合、そのTLSフィンガープリンティングは簡単に特定されます。解決策は、ブラウザのTLSを模倣するライブラリを使用することです(例えば、curl-impersonateや特化したソリューション)。
DataDomeサイトでの作業に役立つツール
パーシングのための適切なツールの選択は、プロキシの選択と同じくらい重要です。異なるタスクには異なるアプローチが必要です。DataDomeとの互換性の観点から、主要なオプションを見ていきましょう。
ブラウザ自動化(Puppeteer、Playwright)
ヘッドレスブラウザは理論的にはDataDomeと良好に機能するはずです。なぜなら、JavaScriptを実行し、「本物の」フィンガープリンティングを生成するからです。しかし、実際には標準のPuppeteerやPlaywrightは、特有のパラメータ(navigator.webdriver = true、プラグインの欠如、非標準のWebGL値)によって簡単に特定されます。回避するには、puppeteer-extra-plugin-stealthのようなプラグインを介して追加のマスキングが必要です。
アンチデテクトブラウザ
サイトとの完全な作業が必要なタスク(パーシングだけでなく、相互作用も含む)には、アンチデテクトブラウザが最適な選択です。Dolphin Anty、AdsPower、GoLogin、Multiloginは、リアルなフィンガープリンティングを持つ完全なブラウザプロファイルを作成します。レジデンシャルまたはモバイルプロキシと組み合わせることで、DataDomeをバイパスするための最大のレベルを提供します。
アンチデテクトブラウザでの接続の設定は標準的です:プロファイルを作成 → プロキシ設定でタイプ(HTTP/SOCKS5)、ホスト、ポート、プロキシサービスのログインとパスワードを指定 → プロファイルを起動します。各プロファイルは、ユニークなフィンガープリンティングを持つ隔離された環境で動作します。
専門のパーシングサービス
ScrapingBee、Apify、Bright Data Scraping Browserなどの既製のサービスがあり、これらは保護を回避するためのすべての作業を引き受けます — あなたは単にURLを渡し、HTMLを受け取ります。これらは独自のレジデンシャルプロキシプールを使用し、自動的にキャプチャを解決します。欠点は、大量の場合の高コストとプロセスに対する制御の低さです。
アプローチの比較
| ツール | DataDomeに対する効果 | 設定の難易度 | スケーラビリティ |
|---|---|---|---|
| HTTPパーサー + レジデンシャルプロキシ | 中程度 | 低い | 高い |
| Puppeteer/Playwright + ステルス + プロキシ | 高い | 中程度 | 中程度 |
| アンチデテクトブラウザ + モバイルプロキシ | 非常に高い | 低い | 低い |
| 既製のパーシングサービス | 高い | 非常に低い | 高い(高価) |
| データセンタープロキシ(任意のツール) | 非常に低い | — | — |
実践的シナリオ:保護されたサイトでの価格監視
例えば、あなたがDataDomeで保護された海外マーケットプレイスで競合の価格を監視しているとします。6時間ごとに5000商品のデータを収集する必要があります。最適なスキームは次のとおりです:
- ツール: ステルスプラグイン付きのPlaywright(自動的にJSチャレンジを解決)
- プロキシ: ローテーション付きのレジデンシャル、ジオロケーション — ターゲットサイトの国
- セッション: 15分のスティッキー、1つのIPあたり20リクエスト
- ヘッダー: 最新のChrome User-Agent、正しいAccept-Language
- クッキー: 1つのセッション内でDataDomeのクッキーを保存し、送信する
- 遅延: リクエスト間のランダムな遅延(4〜12秒)
- セッションの開始: 常にホームページから始め、次に商品に移動する
この設定でのリクエストの成功率は85〜95%であり、定期的な監視には十分です。残りの5〜15%は、別のIPからの再リクエストです。
結論と推奨事項
DataDomeは厳重な保護システムですが、克服できないわけではありません。DataDomeの保護下にあるサイトでの成功の鍵は、適切なプロキシタイプ、正しいヘッダー、現実的な行動、そして賢明なローテーション戦略を持つことです。
記事の主なポイント:
- データセンタープロキシはDataDomeに対して機能しません — IPの評判レベルでブロックされます
- レジデンシャルプロキシはほとんどのパーシングタスクの基本的なツールです
- モバイルプロキシは最大の信頼を提供し、攻撃的に保護されたサイトに適しています
- 良いプロキシは解決策の一部に過ぎません:ヘッダー、クッキー、行動も同様に重要です
- アンチデテクトブラウザと質の高いプロキシの組み合わせが最良の結果をもたらします
- ローテーションと遅延の戦略は非常に重要です — 攻撃的なパーシングではレジデンシャルプロキシでもバンを受ける可能性があります
価格監視、商品カードのパーシング、またはDataDomeで保護されたサイトからのデータ収集を行っている場合は、レジデンシャルプロキシから始めることをお勧めします — これは保護を回避する質とコストの最適なバランスを提供します。アンチボットシステムからの最大の信頼レベルが必要なタスクには、モバイルプロキシを検討する価値があります — 特にモバイル版サイトやモバイルアプリのAPIで作業する場合は特にそうです。