複数のプロキシプロバイダー間で負荷を分散する方法：アービトラージとスクレイピングのための戦略

Facebook Adsで数十のアカウントを運営したり、SMMエージェンシーを運営したり、マーケットプレイスをスクレイピングしたりする場合、単一のプロキシプロバイダーへの依存は重大なリスクとなります。技術的な障害、サブネットのブロック、または制限の超過は、全作業を麻痺させる可能性があります。この記事では、複数のプロバイダー間での負荷分散の実践的な戦略を検討し、安定性を確保し、リスクを最小限に抑える方法を紹介します。

異なるタスクに対する具体的なバランススキームを示します: 広告アカウントのファーミングから大規模なスクレイピングまで。プロバイダーを正しく組み合わせ、自動ローテーションを設定し、各プロキシソースの作業品質を追跡する方法を学びます。

なぜ複数のプロキシプロバイダーを使用するのか

単一のプロキシプロバイダーで作業することは、ビジネスにとっていくつかの重大なリスクを生み出します。状況を想像してみてください: あなたは30の広告キャンペーンをFacebook Adsで立ち上げ、各アカウントは1つのプロバイダーのプロキシを通じて運営されています。突然、プロバイダーがIPアドレスのサブネット全体をブロックされてしまい、すべてのアカウントが同時に危険にさらされます。

ここでは、アービトラージャーやSMM専門家が単一のプロバイダーで直面する実際の問題を紹介します:

• サブネットの大規模なブロック: FacebookやGoogleは、知られたデータセンターからのIP範囲全体を定期的に禁止します。すべてのアカウントが同じサブネットのプロキシを使用している場合、1つのアカウントの禁止は他のアカウントのチェックを引き起こす可能性があります。
• 技術的な障害: どのプロバイダーでも作業の中断が発生することがあります。この時点でアクティブなキャンペーンが実行中または重要なスクレイピングが行われている場合、ダウンタイムは大きなコストをもたらす可能性があります。
• 制限の超過: レジデンシャルまたはモバイルプロキシを使用する場合、トラフィックはしばしば制限されています。唯一のプロバイダーで月間制限を超えた場合、作業は停止します。
• 地理的制限: 1つのプロバイダーが必要なすべての地域をカバーしていない場合があります。異なる地域で作業するためには、追加のソースを接続する必要があります。
• タスクによる異なる品質: Instagramに適しているプロキシがWildberriesのスクレイピングには不向きである場合があります。

経験豊富なアービトラージャーは、同時に最低2〜3のプロバイダーを使用します。例えば、主要なアカウントプールはプロバイダーAを通じて運営され（70%の負荷）、予備プールはプロバイダーBを通じて運営され（20%）、新しいバンドルのテストにはプロバイダーCが使用されます（10%）。このスキームは、1つのプロバイダーに問題が発生しても作業の継続性を確保します。

負荷分散戦略

プロキシプロバイダー間での負荷分散には、いくつかの実績のある戦略があります。選択は、あなたのタスク、予算、作業の継続性の重要性によって異なります。具体的な適用例を交えて、各戦略を見ていきましょう。

戦略1: 主要プロバイダー + 予備プロバイダー (80/20)

これは初心者にとって最も簡単で人気のあるスキームです。1つの主要プロバイダーを選択し、80%の負荷を処理し、残りの20%を予備プロバイダーに割り当てます。予備プロバイダーは、主要プロバイダーに問題が発生した場合の保険として機能します。

使用するタイミング: 10〜30の広告アカウントを持つアービトラージャーや、50のソーシャルメディアプロファイルを運営するSMM専門家に適しています。予算は限られていますが、障害からの基本的な保護が必要です。

Facebook Adsの設定例: 25の広告アカウントがあります。20のアカウントは主要プロバイダーのレジデンシャルプロキシを通じて運営され、5のアカウントは予備プロバイダーを通じて運営されます。Dolphin Antyのアンチデテクトブラウザで、異なるプロキシを使用した2つのテンプレートプロファイルを作成し、設定を複製します。主要プロバイダーが利用できない場合、迅速にプロファイルを予備プロキシに切り替えます。

戦略2: 均等分配 (50/50 または 33/33/33)

負荷は2つまたは3つのプロバイダー間で均等に分配されます。この戦略は、どのプロバイダーにも完全に信頼できない場合や、最大の多様化が重要な高リスクのニッチで作業する場合に適しています。

使用するタイミング: 大規模なアービトラージ作業（50以上のアカウント）、高負荷のマーケットプレイスのスクレイピング、または厳しい制限のある国で作業する場合に適しています。

Wildberriesのスクレイピングの例: 毎日100,000の商品カードをスクレイピングする必要があります。タスクを3つのプロバイダー間で分けます: プロバイダーAが「エレクトロニクス」カテゴリをスクレイピング（33,000カード）、プロバイダーBが「衣類」（34,000）、プロバイダーCが「家庭と庭」（33,000）を担当します。Wildberriesが1つのプロバイダーのサブネットをブロックした場合、失うデータは3分の1だけで、全てのスクレイピングを失うことはありません。

戦略3: タスクによる分割

各プロバイダーは特定のタイプのタスクを担当します。例えば、1つのプロバイダーはアカウントのファーミング専用、別のプロバイダーはアクティブな広告キャンペーンの開始専用、3つ目はスクレイピングと分析専用です。

使用するタイミング: 異なる要件を持つ多様なタスクがある場合。アカウントのファーミングには高いIPトラストが必要で、アクティブな広告には安定性が求められ、スクレイピングには速度とコストが重要です。

TikTok Adsのアービトラージの例: プロバイダーA（モバイルプロキシ）は新しいTikTokアカウントのウォームアップ用で、実際のアクティビティを模倣します。プロバイダーB（レジデンシャルプロキシ）はTikTok Ads Managerでの広告キャンペーンの開始用です。プロバイダーC（データセンタープロキシ）は競合のスクレイピングとクリエイティブの収集用です。各プロキシタイプはそのタスクに最適です。

戦略4: 地理的分配

プロバイダーは地理的地域に分配されます。1つのプロバイダーは米国とカナダをカバーし、別のプロバイダーはヨーロッパ、3つ目はアジアとラテンアメリカをカバーします。

使用するタイミング: 国際的なアービトラージやマルチリージョンSMMの場合。すべてのプロバイダーがすべての国を同じようにカバーするわけではありません。

Instagram SMMの例: あなたは異なる国のクライアントのアカウントを運営しています。プロバイダーAは米国に特化しており、ニューヨークやロサンゼルスの質の高いIPを提供します — それを米国のクライアントに使用します。プロバイダーBはヨーロッパに強く、ドイツ、フランス、スペインのクライアントに使用します。プロバイダーCはCISをカバーし、ロシア語のアカウントに使用します。各アカウントは自分の地域のプロキシを受け取り、ブロックのリスクを減少させます。

異なるプロバイダーのプロキシタイプを組み合わせる方法

プロバイダー間の分配に加えて、プロキシのタイプを正しく組み合わせることも重要です。レジデンシャル、モバイル、データセンタープロキシは異なる特性を持ち、それらの適切な組み合わせは作業の効率を高めます。

Facebook Adsのアービトラージ用の組み合わせ

ファーミングと広告キャンペーンの開始のためのクラシックなスキームには、異なるプロバイダーからの2〜3種類のプロキシが含まれます:

• モバイルプロキシ（プロバイダーA）: Facebookアカウントの初期登録と7〜14日間のウォームアップに使用されます。モバイルIPは最大のトラストを持ち、Facebookはそれらを通常のスマートフォンユーザーとして認識します。この段階でプロフィールを埋め、友達を追加し、いいねをします。
• レジデンシャルプロキシ（プロバイダーB）: ウォームアップ後、アカウントは広告キャンペーンを開始するためにレジデンシャルプロキシに切り替えられます。レジデンシャルIPはモバイルよりも安定しており（10〜15分ごとに変わらない）、長期間のキャンペーンにおいてコストが重要です。
• データセンタープロキシ（プロバイダーC、オプション）: 競合のオーディエンスのスクレイピングやターゲティングデータの収集などの補助的なタスクに使用されます。これらのタスクには高いトラストは必要なく、速度と低価格が重要です。

このスキームはコストを最適化します: 高価なモバイルプロキシは登録とウォームアップの重要な段階（1〜2週間）でのみ使用され、主な作業はより手頃なレジデンシャルプロキシを通じて行われます。

大規模SMM（Instagram、TikTok）の組み合わせ

数十のクライアントアカウントを運営するSMMエージェンシーは、しばしばハイブリッドスキームを使用します:

• レジデンシャルプロキシ（プロバイダーA） — 60%のアカウント: クライアントアカウントの主要プールはレジデンシャルプロキシを通じて運営されます。トラストとコストのバランスを提供します。定期的な投稿、ストーリー、フォロワーとのインタラクションに適しています。
• モバイルプロキシ（プロバイダーB） — 30%のアカウント: VIPクライアントやブロックのリスクが高いアカウント（例えば、攻撃的なマスライクやマスフォロー）用です。モバイルIPはアクティブなアクション時の禁止の可能性を減少させます。
• データセンタープロキシ（プロバイダーC） — 10%のアカウント: エージェンシーの内部テストアカウント用で、ブロックが致命的ではありません。新しい従業員のトレーニングや新しい戦略のテストに使用されます。

マーケットプレイスのスクレイピング用の組み合わせ

Wildberries、Ozon、またはAvitoをスクレイピングする際は、速度とリクエストのボリュームが重要です。ここでは別の論理が働きます:

• データセンタープロキシ（プロバイダーA） — 70%のリクエスト: 主な負荷は高速で安価なデータセンタープロキシを通じて行われます。これにより、最小限のコストで毎分数千のリクエストを行うことができます。公開データ（価格、名前、説明）のスクレイピングに適しています。
• レジデンシャルプロキシ（プロバイダーB） — 30%のリクエスト: よりデリケートなタスク（レビューのスクレイピング、販売者データ、隠れたカテゴリのスクレイピング）用です。マーケットプレイスは、これらのデータへのアクセス時にデータセンターに対して厳しいため、レジデンシャルIPは通過しやすいです。

重要な点: プロバイダーを組み合わせる際は、IPアドレスがサブネットで重複しないように注意してください。2つのプロバイダーが同じデータセンターからIPを借りている場合、分散化の意味がなくなります — サブネットのブロックは両方に影響を及ぼします。

アンチデテクトブラウザでのバランス設定

アンチデテクトブラウザは、複数のプロキシを使用するための主要なツールです。Dolphin Anty、AdsPower、Multilogin、GoLoginは、各アカウントに対して個別のプロキシを持つ独立したプロファイルを作成することを可能にします。人気のあるソリューションでのプロバイダー間の負荷分散を設定する方法を見てみましょう。

Dolphin Antyでの設定

Dolphin Antyは、プロファイル管理が便利で、組み込みの自動化機能があるため、アービトラージャーに人気の選択肢です。3つのプロバイダーでの作業を設定する方法は次のとおりです:

1. プロファイルグループを作成: Dolphinの左メニューで、3つのフォルダを作成します: "プロバイダーA（主要）", "プロバイダーB（予備）", "プロバイダーC（テスト）"。これにより、視覚的な分割が簡単になります。
2. 各プロバイダーのプロキシを追加: "プロキシ" → "プロキシを追加"のセクションに移動します。最初のプロバイダーのプロキシリストをIP:PORT:LOGIN:PASS形式で貼り付けます。グループ名を"Provider_A"とします。他のプロバイダーについても繰り返します。
3. プロキシグループにバインドされたプロファイルを作成: 新しいプロファイルを作成する際に、"プロキシ"セクションで"リストから使用"を選択し、必要なグループを選択します。Dolphinは自動的にそのグループから空いているプロキシを割り当てます。
4. ローテーションを設定: プロバイダーが時間またはリクエストごとのローテーションをサポートしている場合、プロキシ設定でそれを指定します。例えば、モバイルプロキシの場合、特別なIP変更URLを介して10分ごとにローテーションを設定します。
5. 動作を確認: 異なるグループからいくつかのプロファイルを起動し、whoer.netまたは2ip.ruサービスを介してIPを確認します。各プロファイルがそのプロバイダーのプロキシを使用していることを確認します。

Dolphinの利点は、大量操作が可能なことです。20のプロファイルを選択し、主要プロバイダーが利用できない場合に別のプロキシグループに一度のクリックで再割り当てできます。

AdsPowerでの設定

AdsPowerは似たような論理を持っていますが、より高度な自動化機能があります:

1. CSV経由でプロキシをインポート: AdsPowerは、CSVファイルを介して数百のプロキシを一度にアップロードできます。IP、Port、Username、Password、Provider_Nameの列を持つファイルを作成します。"プロキシ管理"セクションからインポートします。
2. タグを使用してマークアップ: プロファイルを作成する際に、プロバイダー名のタグ（例: #ProviderA）を追加します。これにより、プロキシソースに基づいてプロファイルを迅速にフィルタリングできます。
3. エラー時の自動切り替えを設定: AdsPowerには"フォールバックプロキシ"機能があります — 主要プロキシが利用できない場合、プロファイルは自動的に予備プロキシに切り替わります。プロファイル設定で主要プロキシ（プロバイダーA）と予備プロキシ（プロバイダーB）を指定します。
4. 動的バランスのためにAPIを使用: AdsPowerは強力なAPIを持っています。プロバイダーの可用性を監視し、障害時に自動的にプロファイルを再分配する簡単なスクリプトを書くことができます。

MultiloginとGoLoginでの設定

MultiloginとGoLoginは、似た原則で動作します。両方のブラウザで、個別のプロファイルを作成し、各プロファイルに対して手動でプロキシを指定します。負荷分散のために命名システムを使用することをお勧めします:

• プロファイルを次のように命名します: FB_Account_01_ProvA, FB_Account_02_ProvB. これにより、どのプロファイルがどのプロバイダーを使用しているかを迅速に理解できます。
• プロファイル、プロキシ、プロバイダー、最終チェック日を対応させたExcelシートを作成します。これにより、アカウント数が増加した場合の管理が簡単になります。
• GoLoginでは、すべてのプロキシの動作を定期的にチェックするために"プロキシチェッカー"機能を使用します。動作しないものは自動的に赤でマークされます。

プロバイダー間のローテーションの自動化

障害時にプロバイダー間を手動で切り替えることは時間がかかり、ダウンタイムを引き起こす可能性があります。ローテーションの自動化により、システムは自動的に作業中のプロバイダーを選択し、問題が発生した場合に切り替えることができます。いくつかの実装方法を見てみましょう。

プロキシローテーターの使用

プロキシローテーターは、中間サービスで、あなたのリクエストを受け取り、複数のプロバイダー間で自動的に分配します。あなたはローテーターの1つのアドレスに接続し、内部でプロバイダー間を指定されたルールに従って切り替えます。

人気の解決策:

• Proxy-Cheap Rotator: 無料のツールで、異なるプロバイダーからのプロキシを1つのプールに統合します。ウェブインターフェースを介して設定され、接続用の単一のエンドポイントを生成します。
• ProxyMesh: 高度なバランス論理を持つ有料サービスです。プロバイダーの優先順位付け（主要 → 予備 → 緊急）や、自動的な可用性チェックをサポートします。
• HAProxyでの独自のローテーター: 技術的に熟練したユーザー向けです。HAProxyは無料のオープンソース負荷分散ツールで、VPSにインストールし、設定ファイルを介して設定します。

シンプルなローテーターの設定例: 3つのプロバイダーからのプロキシがあると仮定します。Proxy-Cheap Rotatorを自分のコンピュータまたはVPSにインストールし、すべてのプロキシをプロバイダーのタグとともに追加します。ルールを設定します: "プロバイダーAを70%のケースで使用し、Bを20%、Cを10%使用する"。ローテーターは、127.0.0.1:8888の形式の1つのアドレスを生成します。このアドレスをすべてのアンチデテクトブラウザのプロファイルに指定します。ローテーターは、指定された比率に従ってプロバイダー間でリクエストを自動的に分配します。

自動チェックと切り替えのスクリプト

アンチデテクトブラウザ（AdsPower、Dolphin Antyなど）のAPIを持つ場合、簡単な監視スクリプトを書くことができます。スクリプトは5〜10分ごとに各プロバイダーのプロキシの可用性をチェックし、障害時に作業中のプロバイダーにプロファイルを自動的に切り替えます。

スクリプトの動作論理:

1. スクリプトは各プロバイダーのプロキシリストを保持します。
2. 5分ごとに各プロバイダーのプロキシを介してテストリクエストを行います（例えば、google.comに対して）。
3. プロバイダーAが応答しない、またはエラーを返す場合、スクリプトはそれを「利用不可」とマークします。
4. アンチデテクトブラウザのAPIを介して、スクリプトはプロバイダーAのプロキシを使用しているすべてのプロファイルのリストを取得します。
5. これらのプロファイルをプロバイダーB（予備）に再割り当てします。
6. Telegramに通知を送信します: "プロバイダーAが利用不可、15のプロファイルがプロバイダーBに切り替えられました"。
7. 監視を続けます。プロバイダーAが再び利用可能になると、プロファイルを元に戻します。

このようなスクリプトは、KworkやFL.ruのフリーランサーに依頼して2000〜5000ルーブルで作成してもらうことができます。経験豊富なユーザーは、Pythonを使用して数時間で自分で作成することもできます。

プロバイダーの組み込み機能

一部のプロキシプロバイダーは、組み込みの負荷分散メカニズムを提供しています。例えば、2つのプロバイダーからプロキシを購入すると、彼らは自動的にサーバー間でローテーションする単一のエンドポイントを提供します。これは便利ですが、制限があります: 負荷分散は1つのプロバイダー内でのみ機能し、異なるプロバイダー間では切り替えられません。

より高度なオプションは、スティッキーセッション（粘着セッション）の使用です。プロバイダーは、あなたのセッションに「貼り付く」1つのIPアドレスを提供します（例えば、10分間）。これは、頻繁なIP変更が疑いを引き起こすソーシャルメディアでの作業に役立ちます。

品質の監視と障害時の切り替え

プロバイダー間の負荷分散は、一度の設定ではなく、継続的なプロセスです。プロキシの品質は変化する可能性があります: 今日、プロバイダーAは素晴らしく機能しているが、1か月後にはそのサブネットがブロックされるかもしれません。定期的な監視は、問題をタイムリーに特定し、分配を調整するのに役立ちます。

追跡するメトリクス

各プロバイダーについて、次の指標を追跡します:

各プロバイダーについて、これらの指標を毎週Googleスプレッドシートに記録してください。これにより、トレンドを把握できます: 例えば、プロバイダーBは過去2週間でブロックの増加を示している — もしかしたら、そのサブネットはFacebookのブラックリストに載ったのかもしれません。

監視ツール

監視を自動化するために、専門のサービスを使用してください:

• Proxy Checker Pro: Windows/Mac用の無料プログラムで、プロキシリストの動作、速度、匿名性をチェックします。最大1000のプロキシを一度にチェックすることをサポートします。
• Whoer.net API: プロキシのトラストスコアをチェックするための有料APIです。自分のスクリプトに統合し、各プロバイダーのIPの品質を自動的にチェックできます。
• UptimeRobot: 可用性の監視サービスです。各プロバイダーのプロキシの可用性を5分ごとにチェックするように設定します。利用できない場合は、メールまたはTelegramで通知を受け取ります。
• Google Sheetsのカスタムダッシュボード: 自動的に成功した/失敗したリクエストの割合を計算する数式を含むシートを作成します。これは、アンチデテクトブラウザのログに基づいています。

問題発生時の切り替えシナリオ

どの条件で1つのプロバイダーから別のプロバイダーに負荷を切り替えるかを事前に決定してください:

• シナリオ1 — 完全な障害: プロバイダーが30分以上利用できない。アクション: すべてのプロファイルを予備プロバイダーに自動的に切り替え、主要プロバイダーのサポートに通知します。
• シナリオ2 — ブロックの増加: 過去3日間で、プロバイダーAを通じてのアカウントの禁止率が2%から15%に増加しました。アクション: このプロバイダーを通じて新しいアカウントの作成を停止し、新しいアカウントをプロバイダーBに切り替え、プロバイダーAのIPの品質をテストします。
• シナリオ3 — 速度の低下: プロバイダーBを通じてのページの平均読み込み時間が2秒から8秒に増加しました。アクション: このプロバイダーへの負荷を30%から10%に減少させ、解放された負荷をプロバイダーAとBに再分配します。
• シナリオ4 — トラフィック制限の超過: レジデンシャルプロキシプロバイダーの月間トラフィック制限の5%しか残っておらず、月末までに10日があります。アクション: 制限のないトラフィックを持つプロバイダー（通常はデータセンタープロキシ）にタスクの一部を切り替えます。

これらのシナリオをチェックリストの形式で記録し、問題が発生した際に従ってください。これにより、パニック的な決定を防ぎ、アカウントを保護するのに役立ちます。

複数のプロバイダーでのコスト最適化

複数のプロキシプロバイダーを使用することはコストを増加させますが、正しいアプローチを取ることで、品質を損なうことなくコストを最適化できます。節約戦略を見てみましょう。

高価なプロキシと安価なプロキシの組み合わせ

すべてのタスクが高価なモバイルプロキシを必要とするわけではありません。「正しいタスクには正しいツールを使用する」原則を使用してください:

• モバイルプロキシ（$80-150/月/ IP）: 重要なタスクのみに使用 — Facebook/Instagramの新しいアカウントの登録とウォームアップ、SMMでのVIPクライアントとの作業。
• レジデンシャルプロキシ（$50-100/月/ IPまたは$7-15/GB）: 主な作業に使用 — アクティブな広告キャンペーンの運営、ソーシャルメディアでの投稿、高トラストでのスクレイピング。
• データセンタープロキシ（$1-5/月/ IP）: 補助的なタスクに使用 — 公開データのスクレイピング、競合の監視、テストアカウント。

アービトラージャーのための最適化の例: すべての30アカウントにモバイルプロキシを使用する代わりに（$2400-4500/月）、各アカウントの最初の14日間のウォームアップのみに使用します。ウォームアップ後、アカウントをレジデンシャルプロキシに切り替えます（$50/月）。節約額: $4500から$1500/月に品質を維持しながら。

トラフィック料金 vs 専用IPの使用

レジデンシャルプロキシプロバイダーは2つの料金体系を提供しています:

• トラフィックベース: 使用したデータのギガバイトに対して支払います（通常$7-15/GB）。少量のトラフィックを伴うタスクに適しています — ソーシャルメディアの運営、広告の開始。
• 専用IP: 月額固定価格（$50-100）、トラフィックは無制限です。大量のデータのスクレイピングに適しています。

月間トラフィックを計算し、最適なオプションを選択してください。40のInstagramアカウントを運営するSMMエージェンシー（アカウントあたり約2-3GBのトラフィック）にとって、トラフィック料金がより有利です: 40アカウント × 2.5GB × $10/GB = $1000/月対$2000-4000の40の専用IP。

プロバイダーとの割引交渉

複数のプロバイダーと取引することで、各プロバイダーにとって大口顧客になります。これを利用して割引を得てください:

• ボリューム割引を要求: "月に50GB使用する予定ですが、どのような割引を提供できますか？" 多くのプロバイダーは、大きなパッケージを購入する際に10-20%の割引を提供します。
• テスト期間を要求: "複数のプロバイダーをテストしていますので、品質を評価するために3-5日間無料または50%割引で提供してください"。
• 数ヶ月分を一括で支払う: 通常10-15%の割引が得られます。
• 紹介プログラムを利用: 他のユーザーを紹介し、自分の残高にボーナスを得ます。

非効率的なプロバイダーの排除

これで記事は終了です。必要に応じて、プロバイダーの選定や負荷分散戦略を見直し、最適な結果を得るための調整を行ってください。