レジデンシャルプロキシは、作業中にリクエストごと、あるいは一定間隔ごとに異なるIPアドレスを提供します。1つのアドレスがすべてのトラフィックを担うのではなく、負荷をプール全体に分散させることで、単一のアドレスがサイトに気づかれるほどのリクエスト量を積み重ねることがなくなります。
この記事では、ローテーションが実際にどう機能するのか、backconnectとは何を意味するのか、そして両者をどう設定するのかを解説します。
ローテーションの仕組み
アドレスのリストを自分で管理する必要はありません。単一のゲートウェイエンドポイントに接続すれば、プロバイダがリクエストごとにプールからアドレスを割り当てます。スクレイパー側の視点では、リクエスト間で何も変わりません。ターゲット側の視点では、各リクエストが異なる訪問者から届いているように見えます。
ローテーションには2つのモードがあり、どちらを選ぶかが設定における主な判断事項になります。
リクエストごとのローテーションは、毎回新しいアドレスを発行します。分散は最大になりますが、継続性はありません。商品ページ、検索結果、ディレクトリ一覧、在庫確認といった、独立した取得作業に使います。リクエスト間で何も引き継がれないため、アドレスが変わっても何も壊れません。
スティッキーセッションは、1つのアドレスを一定の時間枠(通常1分から30分)保持します。カーソルによるページ送り、ログイン後のすべての処理、複数ステップのフォームやチェックアウトなど、リクエスト同士が依存関係を持つ場合に使います。
どちらを使うかは、コード内ではなく認証情報の中で選択します。プロバイダはセッションをユーザー名にエンコードするため、典型的な設定は次のようになります。
# per-request rotation: a new IP for every request
curl -x gate.shifter.io:8080 -U "customer-USER:PASS" https://example.com
# sticky session: same IP for the life of session id abc123
curl -x gate.shifter.io:8080 -U "customer-USER-session-abc123:PASS" https://example.com
# sticky, geo-targeted to Germany
curl -x gate.shifter.io:8080 -U "customer-USER-country-de-session-abc123:PASS" https://example.comセッションIDを変更すれば新しいアドレスが得られます。そのまま保持すれば、時間枠が終了するまでアドレスは維持されます。パラメータ名の正確な表記はプロバイダによって異なるため、利用するサービスのドキュメントを確認する必要がありますが、仕組み自体は共通しています。
ローテーション中にセッションはどうなるか
ここはほとんどの解説が省略している部分であり、ローテーション関連の失敗の大半の原因です。
ログイン済みのセッションとは、サイトが特定のアドレスにいるブラウザに対して発行したクッキーです。次のリクエストが同じクッキーを持って別の国から届けば、サイトはテレポートしたセッションを目にすることになります。サイトの警戒レベルによって、再認証を求められたり、セキュリティチャレンジが発生したり、セッションが完全に無効化されたりします。
ローテーションは、あなたがログイン中であることを知りませんし、気にもしません。セッションが必要とする間だけアドレスを保持することは、あなたの責任です。フローが4分かかるなら、5分のスティッキーウィンドウでカバーできます。処理が数時間にわたる場合、ローテーションは適切な手段ではなく、恒久的なアドレスを持つISPプロキシが正しい選択です。
Backconnectプロキシ
Backconnectは、ローテーションを可能にするゲートウェイのアーキテクチャです。管理すべきアドレスのリストを提供するのではなく、プロバイダはあなたに代わってプールへ逆方向に接続する単一のエンドポイントを提供します。
ここは正確に理解しておく価値があります。というのも、この記事の以前の版を含め、しばしば誤って説明されているからです。backconnectはresidentialの同義語ではありません。 Backconnectはアドレスがどのように届けられるかを表します。residentialはアドレスがどこから来るかを表します。両者は独立しており、backconnectゲートウェイはレジデンシャルプールと同様、データセンタープールやモバイルプールにも存在します。
Backconnectが実際にもたらすもの:
- 設定するエンドポイントが1つで済む。 プロジェクトが続く間、背後のプールがどう変化しても、スクレイパーは単一のホストとポートを指し続けます。
- 自動的な入れ替え。 停止したりブロックされたりしたアドレスは、コード側で気づくことなくローテーションから除外されます。
- パラメータによるターゲティング。 国、都市、ASNの選択は、別々のアドレスリストを維持するのではなく、認証情報の中で行われます。
- プール管理が不要。 プロキシリストを構築、テスト、更新する必要は一切ありません。
代替手段である個々のアドレスの静的リストでは、これらすべてを自分で処理する必要があります。そのため、backconnectはあらゆる規模のプールにおける標準的な提供方式となりました。
ローテーションが得意なこと
以下は、レジデンシャルIP全般の利点とは区別された、ローテーション特有の利点です。
- IPごとのレート制限を回避する。 1アドレスあたり時間60リクエストという制限は、大規模なプール全体では実質的に無制限になります。これはローテーションの最も明確な利点です。
- 大規模な収集作業を継続する。 1つのアドレスを消耗させるほどの量でも、数千に分割すれば目立ちません。
- 個別のブロックを乗り越える。 あるアドレスがブロックされても、次のリクエストは単に別のアドレスを使います。検知も修正も不要です。
- 多くの地域を安価にサンプリングする。 20カ国で価格や広告を確認するのに、国ごとの購入は不要で、リクエストごとにパラメータを変更するだけで済みます。
- パターンの兆候を減らす。 1つのアドレスが24時間10秒おきにリクエストを送っていれば、それは機械的だと分かります。同じトラフィックをプール全体に分散させれば、そうは見えません。
ローテーションがしないことは、信頼されていないアドレスを信頼されたものに変えることです。アドレスの所有者を分類するサイトに対してデータセンターIPをローテーションさせても、プール内のすべてのアドレスで失敗します。ローテーションは信頼を得るためではなく、量を分散させるためのものです。
ローテーションを使うべき時、使わないべき時
ローテーティングプロキシを使うべき場面: ウェブスクレイピングと価格モニタリング、SERPやランキング追跡、地域別の広告検証、在庫や入荷確認、AIの学習やグラウンディング用の大規模データ収集。
静的プロキシまたはISPプロキシを使うべき場面: アカウント管理、長期間ログインが必要な作業、広告プラットフォームへのアクセス、同一の訪問者として認識されることそのものが目的となる作業。
次に読むべき記事は、あなたがどちら側に該当するかによって変わります。完全な比較については、静的プロキシとローテーティングプロキシで詳細に取り上げています。ターゲットに応じたプロキシタイプの選び方については、ウェブスクレイピング用プロキシを参照してください。
まとめ
ローテーションは製品カテゴリーではなく、セッション単位の長さを決める設定です。リクエストごとのローテーションは独立したトラフィックをプール全体に分散させ、収集作業における適切な既定値です。スティッキーセッションは、フローが必要とする間だけアドレスを保持します。Backconnectは、両方を単一のエンドポイントから提供するゲートウェイです。
作業に合ったローテーション間隔を設定すれば、ブロックに関するほとんどの問題は解消します。どちらの方向にも設定を誤れば、セッションが壊れるか、トラフィックが集中して気づかれるかのどちらかになります。
Shifterのレジデンシャルプロキシは、国、都市、ASNのターゲティングとともに両方のモードをサポートしており、現在の料金は料金ページに掲載されています。