メインコンテンツへスキップ
IPベースのブロックはもっとも古く、今でもよく使われるスクレイピング対策です。サイトはIPごとのリクエスト数を数え、reputation databaseと照合し、hosting range全体をブロックし、1つの送信元からの挙動が自動化に見えるとCAPTCHAを出します。 ローテーティングプロキシは、複数のIPにリクエストを分散します。適切に使えば1つのIPへの負荷を下げ、通常の閲覧に近い交通パターンを作れます。不適切に使うと、低品質で不整合なIPが大量に切り替わるだけになり、より強いbot signalになります。

プロキシが変えるもの

プロキシはスクレイパーと対象サイトの間に入ります。対象サイトからは、操作者の直接IPではなくproxyのIPが見えます。 役立つ場面:
  • rate limitの分散
  • blocked IPの除外
  • 地域限定コンテンツへのアクセス
  • 操作者のローカルIPを直接晒さない
  • クラウド並列実行でsubtaskごとに通信経路を分ける
ただし、プロキシは壊れたselector、誤ったページネーション、明らかなブラウザ自動化を直すものではありません。規模化stackの1レイヤーです。

プロキシの種類

データセンタープロキシ

hosting providerやcloud infrastructure由来のIPです。速く安く、大量に入手しやすい一方、保護の強いサイトではhosting rangeとしてまとめて低信頼に扱われることがあります。軽いサイトやvolume対策には有効です。

residential proxy

一般家庭向けISPに紐づくIPを使います。通常ユーザーに近く見えやすく、EC、検索、旅行、マーケットプレイスなどで成功率が上がることがあります。コストと調達倫理が重要です。IP poolがどのように集められているか説明できるproviderを選びます。

ISP proxy

データセンターの安定性とISP登録IPの見え方の中間です。sticky session、安定した地域、datacenterより良いreputationが必要な時に向いています。

mobile proxy

携帯キャリア網を経由します。carrier-grade NATにより多くの実ユーザーとIPを共有するため信頼されやすい場合がありますが、高価で過剰なことも多いです。mobile-firstの対象や、他のproxy typeが一貫して失敗する場合に限定して使います。

ローテーション戦略

常に「リクエストごとに新しいIP」が正解ではありません。

リクエスト単位

公開検索結果や単純な一覧ページのようなstatelessな対象では使えます。Cookie、cart、login、地域一貫性が必要なsessionでは危険です。

sticky session

一定時間または1セッション中は同じIPを保ちます。JavaScriptが重いサイト、ログイン後ページ、ページネーション、地域やCookieの継続性が必要なタスクに向いています。

タスク単位

カテゴリ、都市、keyword、URL batchなど、subtaskごとにproxy identityを割り当てます。クラウド実行のsubtask分割と相性が良く、失敗時の再試行もしやすくなります。

地域指定

米国価格を集めるなら米国IP、国別在庫を比較するなら国ごとに分割します。timezone、language、browser fingerprintもproxy地域と整合させます。

ユースケース別の選び方

用途proxy方針
公開静的ページproxyなし、またはdatacenter + 控えめなrate
大規模商品カタログ防御に応じてdatacenterまたはresidential
検索/マーケットプレイスresidential/ISP + sticky session
ログイン後ダッシュボードアカウントごとに安定IP、過度なrotationは避ける
地域別価格/在庫国/地域指定proxy
mobile-onlyコンテンツ必要な場合のみmobile proxy

よくある失敗

  • IPを頻繁に変えすぎる
  • 安いblocked IP poolを使う
  • IP地域とtimezone/languageが矛盾する
  • ログイン中にIPを変える
  • 対象サイトの負荷を考えずに並列化する
  • proxyを使えば規約や法的問題が消えると誤解する
Octoparseのような統合型ツールでは、proxy rotationをタスク設定の一部として扱えます。Octoparseはクラウド実行でのIP rotation、ローカル/クラウドで使える内蔵residential proxy、ローカル実行でのユーザー指定HTTP proxyをドキュメント化しています。重要なのは、proxy設定を実行戦略と切り離さず、subtask、スケジュール、browser session、network pathを同じ設計の中で扱うことです。 実務上のルールは単純です。効く範囲で最も弱いproxy戦略を使います。低リスク対象ではまず通常のペースで始め、volumeが問題ならdatacenter、reputationが問題ならresidential/ISP、継続性が必要ならsticky sessionを使います。