WildberriesとOzonのスクレイピングにおけるトラフィック制限：一晩で月間プロキシパッケージを無駄にしない方法

セラーは競合の価格をパースするためにパーサーを夜間に起動し、朝には通知を受け取ります: トラフィックが終了し、パッケージの90%が消費されました。聞き覚えのある状況ですか？多くの場合、問題の原因はパーサー自体ではなく、プロキシやスクリプトレベルでの制限がないことです。この記事では、トラフィックがどのように「漏れ」ているのか、そして月間のレジデンシャルまたはモバイルプロキシパッケージが計算期間の最後まで持つようにするための保護を設定する方法を見ていきます。

なぜトラフィックが一晩で終了するのか

Wildberries、Ozon、またはAvitoのパーシングは簡単な作業のように見えます: リクエストを送信し、価格のJSONを受け取ります。しかし実際には、トラフィックは有用なデータだけでなく、さまざまな要因によって消費されます。主な過剰消費の原因は以下の通りです:

• 画像やメディアの読み込み。 パーサーがブラウザを通じて商品ページ全体を開く場合（APIへの直接リクエストを行わない場合）、自動的に画像、動画、バナーを読み込みます — これは一つのカードにつき数十メガバイトになります。
• キャプチャやブロックによる再リクエスト。 マーケットプレイスはボットを認識し、キャプチャを表示したり、IPを一時的にブロックします。スクリプトは再リクエストを行い、トラフィックが無駄に消費され、データが得られません。
• リクエストのキャッシュがない。 「この時間内にすでにパースされた — 繰り返さない」というロジックがない場合、スクリプトは同じカードを何度も問い合わせることがあります。
• 制限なしの並列スレッド。 50-100のスレッドを同時に起動することは作業の加速のように見えますが、その結果、トラフィックは計画よりもはるかに早く消費され、一部のリクエストは単にブロックされます。
• プロキシのタイプの誤った選択。 レジデンシャルおよびモバイルプロキシは通常、トラフィックの量（GB）に基づいて課金されますが、データセンターのプロキシでは、IPの数やレンタル時間に基づいて課金されることが一般的です。プロキシプールが制御なしにレジデンシャルに設定されている場合、制限はすぐに消費されます。

これらの要因の組み合わせにより、月間の作業を想定したスクリプトが、一晩のパーシングセッションで10,000〜20,000の商品のパッケージトラフィックを消費することになります。

異なるタイプのプロキシでのトラフィックの計算方法

制限を設定する前に、何に対して支払っているのかを理解することが重要です。異なるタイプのプロキシはトラフィックの消費を異なる方法で計算し、これは節約戦略に直接影響します。

プロキシのタイプ	課金方式	過剰消費のリスク	いつ適用するか
レジデンシャルプロキシ	トラフィックの量（GB）	制限なしで高い	マーケットプレイスのアンチボット保護を回避するパーシング
モバイルプロキシ	トラフィックの量または時間	高い、トラフィックが高価	モバイル版のサイトのパーシング、厳しいブロックの回避
データセンターのプロキシ	IPの数 / レンタル時間	低い、トラフィックは通常無制限	厳しいアンチボット保護なしでの大量パーシング

WildberriesやOzonをパースする場合、ボットからの保護が積極的に機能しているため、レジデンシャルまたはモバイルIPがほぼ常に必要です — データセンターのアドレスはすぐにブロックされます。しかし、トラフィックに基づく課金のため、ここでは事前に制限を設定することが特に重要です。

パーシングに実際に必要なトラフィック量

適切な制限を設定するためには、実際の数字に基づいて判断する必要があります。実際の消費量の例は以下の通りです:

• 商品カードへのAPIリクエスト（JSON、画像なし）: 1カードあたり5-30KB。10,000カードで約50-300MB。
• 画像付きのヘッドレスブラウザを介した商品ページの読み込み: 1カードあたり1-3MB。10,000カードで10-30GB。
• 1時間ごとの1000SKUの価格監視: 軽量リクエストの場合、1日あたり約1-5GB、ページを完全に読み込む場合は1日あたり50-100GB。

「軽い」パーシングと「重い」パーシングの違いは数十倍です。したがって、トラフィックを節約する最初のステップは、可能な限り画像、動画、外部スクリプトの読み込みをオフにし、マーケットプレイスのAPIまたはデスクトップ版よりも軽量なモバイル版サイトと直接やり取りすることです。

アンチデテクトブラウザとプロキシマネージャーでの制限

アンチデテクトブラウザ（例えば、Dolphin Anty、AdsPower、Multilogin、GoLogin、Octo Browser）や独自のプロキシマネージャーを使用している場合、消費を制限する最も簡単な方法は、プロキシプロバイダーのアカウントとプロファイルレベルで制限を設定することです。

1. プロキシプロバイダーの個人アカウントにログインし、サブユーザー/ポートのトラフィックまたは制限の管理セクションを見つけます。
2. パーシング用の別のサブアカウントまたはポートを作成します — InstagramやTikTokのアカウントファーミング用のプロキシプールを使用しないでください。タスクごとに分けることで、トラフィックの流れを明確にします。
3. このサブアカウントに対して日次または時間単位のトラフィック制限を設定します — 例えば、1セッションで月間パッケージ全体を消費するのではなく、1日あたり5GBにします。
4. アンチデテクトブラウザで画像の自動読み込みをオフにします — データ収集のためだけに使用されるプロファイルでは、ページの視覚的表示のためではありません。
5. プロファイルの起動スケジュールを設定し、パーシングが長いセッションではなく短い間隔で行われるようにします — これにより、ブロックのリスクが低減し、起動間のトラフィック消費を追跡する時間が得られます。

このアプローチは、複数のマーケットプレイスを同時にパースしているエージェンシーやフリーランサーにとって特に重要です: サブアカウントで分けないと、どのプロジェクトがトラフィックを「消費」しているのかを理解するのが難しいです。

スクリプトとAPIレベルでのトラフィック制限

PythonやNode.jsで自作したパーサーの場合、制限をコードに組み込むことができ、プロキシプロバイダーのインターフェース設定よりも正確な制御が可能です。

requestsを使用したPythonのシンプルなトラフィックカウンターの例:

import requests

MAX_BYTES_PER_DAY = 5 * 1024 * 1024 * 1024  # 1日あたりの制限5GB
used_bytes = 0

proxies = {
    "http": "http://user:pass@proxy_host:port",
    "https": "http://user:pass@proxy_host:port",
}

def safe_get(url):
    global used_bytes
    if used_bytes >= MAX_BYTES_PER_DAY:
        raise RuntimeError("1日のトラフィック制限に達しました。パーシングを停止します。")

    response = requests.get(url, proxies=proxies, timeout=10)
    used_bytes += len(response.content)
    return response

# 呼び出しの例
resp = safe_get("https://card.wb.ru/cards/detail?nm=123456")
print("使用したトラフィック:", round(used_bytes / 1024 / 1024, 2), "MB")

ロジックはシンプルです: スクリプトは各レスポンスのサイズをバイト単位で計算し、指定された制限に達すると停止します。これにより、ループ内のエラーや無限リクエストの繰り返しによって、スクリプトが数時間で月間トラフィックパッケージを「消費」する状況を防ぎます。

さらに追加すべき点は:

• エラー時の指数的遅延（バックオフ付きのリトライ） — キャプチャやブロック時に即座にリクエストを繰り返すのではなく、スクリプトは増加する間隔（5秒、15秒、60秒）を待つことで、無駄なリクエストの数を減らします。
• 並列スレッドの数を制限 — 例えば、プロキシプールを介して同時に10-20の接続を超えないようにして、ブロックを引き起こさず、トラフィックを無駄に消費しないようにします。
• ヘッドレスブラウザでのリソースの読み込みをオフにする — SeleniumやPuppeteerを介してパーシングを行う場合、ブラウザの設定で画像、フォント、CSSの読み込みをブロックし、HTML/JSONレスポンスのみを残すことができます。

リアルタイムでの消費監視

監視なしの制限は効果が薄く、スクリプトが停止した後に問題を知ることになります。消費をリアルタイムで監視するために:

• プロキシプロバイダーの個人アカウントで、月間トラフィックパッケージの50%、80%、100%に達した際の通知を有効にします — ほとんどのサービスは、メールやTelegramでのアラートをサポートしています。
• スクリプト内でシンプルなログを維持します: トラフィックの量を時間ごとにファイルやデータベースに記録し、消費のピークを把握し、問題の原因を迅速に特定します。
• タスクごとにトラフィックを分けるために、サブアカウントやタグを使用します — Wildberries用、Ozon用、Avito用に分けます。これにより、どのプロジェクトが最も多くのトラフィックを消費しているかを分析しやすくなります。
• 消費量を予想されるデータ量と照らし合わせます: 10,000カードで300MBの計算に対し20GBが消費された場合、どこかで余分なリソースが読み込まれているか、再リクエストが行われていることを示しています。

トラフィック予算管理のチェックリスト

初心者のよくあるミス

実際には、消費されたトラフィックパッケージのほとんどは、いくつかの典型的なミスによって説明されます:

• 制限なしで「監視なしの夜間パーシング」を開始する。 スクリプトは8-10時間連続して動作し、どこかで再リクエストのループが発生すると、トラフィックが朝まで無限に消費されます。
• すべてのタスクに対して1つのプロキシプールを使用する。 Instagramのアカウントファーミング、Facebook広告のテスト、Ozonのパーシングが同じトラフィックを使用しているため、何が消費されているのかを理解することができません。
• キャプチャを無視する。 キャプチャの最初の兆候が現れたときにリクエストの頻度を下げる代わりに、スクリプトは同じ強度でサイトを攻撃し、エラーコードの無駄なレスポンスにトラフィックを消費します。
• データセンターのプロキシで十分なところにレジデンシャルプロキシを選択する。 マーケットプレイスがデータセンターのIPを厳しくブロックしない場合、レジデンシャルプールのトラフィックに対する過剰支払いは正当化されません — より保護されていない目的には、データセンターのプロキシが適しています。
• テスト実行を行わない。 数千のカードの完全なパーシングを開始する前に、50-100カードでスクリプトを実行し、実際のトラフィック消費を測定して、全体のボリュームに外挿することが重要です。

結論

パーシングのトラフィックはデータ量によって「消費」されるのではなく、制御の欠如によって消費されます: 不要な画像、ブロック時の再リクエスト、制限なしの並列スレッド、すべてのタスクに対する共通のプロキシプール。解決策は、プロジェクトごとにトラフィックを分け、プロキシアカウントレベルで日次制限を設定し、スクリプト自体に消費カウンターを組み込み、パッケージが本当に終了する前に通知付きの監視を設定することです。

WildberriesやOzonのようなボットからの保護が積極的なマーケットプレイスをパースする場合、レジデンシャルプロキシを使用してブロックを回避し、さらにモバイルIPを最も敏感なアンチボット保護シナリオに使用することをお勧めします — ただし、どちらの場合でも、月間パッケージが一晩のセッションで消費されないように、事前にトラフィック制限を設定してください。