同じプロキシポートは、Wildberriesのパース時に50の並行リクエストを問題なく処理できますが、Facebook Ads Managerでの同時セッションが3回を超えると「燃え尽きる」ことがあります。これはプロキシの質ではなく、異なるタイプのトラフィックがIPに異なる負荷をかけるためです。この記事では、あなたのタスクに対する実際のスレッド制限を計算し、単純な数学の誤りでアカウントやプロキシプールを燃やさない方法を解説します。
プロキシポートの「スレッド」とは
スレッドとは、特定の瞬間にプロキシを介して行われる1つの並行接続です。もしあなたがDolphin Antyのアンチデテクトブラウザで10のタブを開き、すべてが同時に同じプロキシポートを介してInstagramを読み込んでいる場合、それは10のスレッドです。Pythonのパーサーが1つのIPを介してWildberriesに50のリクエストを同時に送信する場合、それは50のスレッドです。
重要なのは、スレッド数はインターネットの速度ではなく、特定のIPアドレスからターゲットサイトが同時に見る「個人の数」を示しているということです。この数値は、Facebook、Instagram、TikTokのアンチフロードシステムやマーケットプレイスの保護が、IPをブロックするかトラフィックを通過させるかの判断に使用します。
仲裁者やSMM専門家にとって、スレッドは通常、1つのアカウントが同時に開いている状態を意味します。マーケットプレイスのセラーにとって、スレッドはパーサーや価格監視スクリプトの同時HTTPリクエストです。トラフィックの性質の違いが、1つのポートで安全に保持できるスレッド数を決定します。
スレッド制限は何に依存するか
「プロキシはNスレッドを保持できる」という普遍的な数字は存在しません — これはバンを引き起こす神話です。実際の制限は、以下の要因の組み合わせによって決まります：
- IPのタイプ。 レジデンシャル、モバイル、データセンターのプロキシは、アンチフロードシステムによって異なるように認識されます。モバイルIPは通常、1人の実際の人間であるため、異なるクッキーでの2-3の並行セッションは疑わしく見えます。
- ターゲットプラットフォーム。 FacebookとTikTokは、ほとんどのマーケットプレイスよりも行動パターンを厳しく分析します。WildberriesとOzonは、まずリクエストの頻度を見て、次に「個人の数」を見ます。
- リクエストのタイプ。 商品の価格を取得するための単純なGETリクエストは軽い負荷です。認証、メディアのアップロード、インターフェースとの対話を伴う完全なセッションは重いです。
- プロキシプロバイダー。 IPアドレスのプール、ローテーションの速度、技術的な帯域幅は、プロバイダーによって大きく異なります。
- トラフィックの目的。 マルチアカウントはIP上の「個人」のユニークさを要求し、パースは単にアイデンティティに依存しない帯域幅を要求します。
そのため、「プロキシのスレッド制限」ではなく、「特定のタスクに対する特定のプラットフォームのスレッド制限」と言う方が正確です。
マルチアカウント用の計算（SMMと仲裁）
マルチアカウントに関する黄金のルールはシンプルです：1つのアカウント — 1つのIP — 1つのセッション。つまり、理想的にはプロキシポートには正確に1つのアクティブなスレッドが必要です。これはFacebook Ads、TikTok Ads、またはInstagramアカウントに関する場合です。理由はプロキシの技術的制限ではなく、アンチフロードシステムがIP + デバイスフィンガープリンティング + 行動の組み合わせを追跡するからです。2つのアカウントが異なるアンチデテクトブラウザのタブで同時に同じIPに「座っている」場合、チェーンバンのリスクが急激に高まります — すべてのアカウントのブロックが一度に行われる可能性があります。
実際には、SMMエージェンシーや仲裁チームでは、次のような分配の論理が使用されます：
| タスク | 1ポートあたりのスレッド数 | コメント |
|---|---|---|
| Facebook Adsのアカウントファーミング | 1 | 1つの安定したIPに厳密に1アカウント、できれば固定された（スティッキーセッション） |
| クライアントのInstagramアカウントの管理 | 1 | 短時間の並行セッションでも異常として検出される |
| 進行中のTikTok Ads | 1 | TikTokは、1つのセッション内でのIPの急激な変更に特に敏感です |
| アカウントの大量チェック（アクションなし） | 2-3 | 主要な活動にリスクを伴わない軽いチェック操作には許容される |
このスキームではIPの安定性が重要です：プロキシがセッションの途中でアドレスを変更すると、アカウントと「個人」の関連付けが切れ、デバイスの置き換えのように見えます。したがって、マルチアカウント用には通常、レジデンシャルプロキシを使用し、長時間（10分から数時間）固定されたIPを保持できるようにし、特に敏感なプラットフォームにはモバイルプロキシを使用して、最大限に「人間らしい」トラフィックプロファイルを提供します。
Dolphin Anty、AdsPower、Multilogin、またはGoLoginのアンチデテクトブラウザでは、これを簡単に設定できます：各アカウントのプロファイルに個別のプロキシポートを指定し、ブラウザ全体の共通プールを使用しません。プロファイルの設定を開く → 「プロキシ」セクション → 各アカウントのために個別のデータ（IP、ポート、ログイン、パスワード）を入力 → 保存します。これにより、2つのアカウントが偶然にも同時に同じIPに存在する状況を物理的に排除できます。
マーケットプレイスのパース用の計算
Wildberries、Ozon、またはAvitoのパースでは、論理が逆になります。ここでは「個人」という概念はなく、「1つのIPからのリクエストの頻度」という概念があります。マーケットプレイスの保護は、並行スレッドの数そのものではなく、リクエストの速度と行動パターン（同じ間隔、休止の欠如、同一のヘッダー）に反応します。
実際の計算は次の式に基づいています：
実際には、ほとんどの大規模マーケットプレイスにおいて、安全な範囲は、1つのデータセンターIPあたり3-8の並行スレッドで、リクエスト間の間隔は1〜3秒です。この値を超えると、403や429のレスポンス（キャプチャ、一時的なリクエストブロック）の割合が増加します。
| プラットフォーム | 1 IPあたりの推奨スレッド数 | リクエスト間の遅延 |
|---|---|---|
| Wildberries（商品カード） | 3-6 | 1-2秒 |
| Ozon（価格監視） | 4-8 | 1-2秒 |
| Avito（広告のパース） | 2-4 | 2-4秒 |
| Yandex.Market | 3-5 | 1-3秒 |
もし目的が大量の商品を迅速に処理することであれば、1つのIPを制限を超えて「プル」するのではなく、IPアドレスのプールを増やし、負荷を分散させるのが正しい方法です。1000の商品があり、IPあたり5スレッドの制限があり、1.5秒の遅延がある場合、1つのIPは5分間に約200リクエストを処理します — 10のIPプールを使用すれば、同じことを約30秒で行えます。このようなタスクに対しては、速度/コストの比率が最適なデータセンターのプロキシが推奨されます — それらはレジデンシャルよりも速く、認証なしで公開ページをパースするのに十分です。
レジデンシャル vs モバイル vs データセンター：スレッドの表
以下は、プロキシのタイプとタスクの性質に応じて安全な並行スレッドの制限を迅速に推定するのに役立つ要約表です。数字は目安であり、特定のプラットフォームによって異なりますが、計画のための正しい規模を提供します。
| プロキシのタイプ | マルチアカウント（スレッド/ポート） | パース（スレッド/ポート） | 特徴 |
|---|---|---|---|
| レジデンシャルプロキシ | 1 | 3-5 | プラットフォームの信頼度が高く、柔軟なローテーション |
| モバイルプロキシ | 1 | 2-3 | 最大限の「人間らしさ」、しかし限られた帯域幅 |
| データセンターのプロキシ | ソーシャルメディアには推奨されない | 5-10 | 高速で低コストだが、ソーシャルメディアに検出されやすい |
注意：データセンターのプロキシは、技術的に複数のInstagramアカウントを開くことを禁止していませんが、そのようなIPはソーシャルメディアの検出データベースに「サーバー」として登録されることが多く、1つのスレッドでもバンのリスクが急増します。ソーシャルメディアや広告プラットフォームにとっては、スレッド数よりもIPのタイプと評判が重要です。
負荷計算時の典型的な誤り
実際には、ほとんどのバンやブロックは悪いプロキシに起因するのではなく、スレッドの不適切な分配に起因します。最も一般的な誤りは次のとおりです：
- 全体のプロキシプールをアンチデテクトブラウザ全体で使用する。 プロファイルの設定に各アカウントのための個別のポートが指定されていない場合、システムは偶然に2つのプロファイルを同じIPを介してルーティングする可能性があります。
- パーサーの遅延を無視する。 リクエスト間に間隔がないスクリプトは、たとえスレッドが形式的に1つであっても、自動化としてすぐに検出されるパターンを生成します。
- 1つのポートでタスクを混合する。 アカウントの加熱とフィードのパースのために同じプロキシを同時に使用することは、突然のブロックの一般的な原因です。
- アクティブなセッションの途中でIPをローテーションする。 マルチアカウントにとっては、スティッキーセッションが重要です：アカウント作業中のIPの変更は、アカウントの侵害のように見えます。
- スレッドを「目分量」で計算する。 プラットフォームの応答時間と実際の制限を考慮せずに、IPを過負荷にするか、プロキシプールを非効率的に使用することが容易です。
チェックリスト：必要なスレッド数を計算する方法
タスクを開始する前に — Facebook AdsのアカウントファーミングやWildberriesの価格監視であっても — 短いチェックリストを確認してください：
- トラフィックのタイプを特定します：マルチアカウント（1アカウント = 1スレッド = 1 IP）またはパース（1 IPに対して複数のリクエストが許可される）。
- プラットフォームに公開されたリクエスト制限（レートリミット）や文書化されたブロックの閾値があるか確認します。
- ソーシャルメディアや広告アカウントの場合、レジデンシャルまたはモバイルIPを選択し、ポートあたり1スレッドを厳密に固定します。
- パースの場合、「リクエスト制限 ÷ 応答時間」の式を計算し、負荷のスパイクに対して20-30%の余裕を追加します。
- リクエスト間の遅延を手動で設定します。たとえパーシングツールがデフォルトでそれを要求しなくても。
- スケールアップする前に小規模なIPプールでテストします — そうすれば、特定のプラットフォームのブロックの実際の閾値がわかります。
- エラーログ（403、429、キャプチャ）を記録します — これらのコードの増加は、現在のスレッド制限が超過していることを示します。
結論
「プロキシポートが保持できるスレッド数」という質問に対する普遍的な答えは存在しません — すべてはトラフィックのタイプに依存します。Facebook Ads、TikTok Ads、またはInstagramのマルチアカウントに関しては、ルールは1アカウント — 1 IP — 1スレッドであり、ここではIPの評判が帯域幅よりも重要です。Wildberries、Ozon、またはAvitoのパースの場合、リクエスト間の遅延が正しく設定されている場合、1つのIPで3-8の並行スレッドを安全に保持できます。
あなたのタスクが多くのアカウントをファーミングし、チェーンバンのリスクなしに管理することであれば、レジデンシャルプロキシを使用して固定セッションをサポートし、特に敏感なプラットフォームにはモバイルプロキシを使用してください。もし目的が迅速かつ大量の価格や商品カードのパースであり、速度が「人間らしさ」よりも重要であれば、複数のデータセンターのプロキシのプールに対する負荷を計算し、リクエストを均等に分配して、1つのアドレスあたりの安全なスレッドの閾値を超えないようにするのが賢明です。