あなたはプロキシを通じてパーサーを起動したりアカウントをウォームアップしたりして、ページのサイズに基づいて消費を計算しているのに、請求書が予想の2〜3倍になってしまいます。これはプロバイダーの詐欺ではありません：トラフィックには、実際にチャンネルを通過したすべてのものが含まれます—リクエストヘッダー、TLSハンドシェイク、接続の再試行、そして制御パケット。トラフィックの「チェック」がどのように構成されているか、そして品質を損なうことなく消費をどのように削減できるかを解説します。
プロバイダーが実際にトラフィックとしてカウントするもの
あなたが「目分量」で消費を評価するとき、通常はHTMLページのサイズに画像を加えた式が頭に浮かびます。しかし、プロキシプロバイダーは、チャンネルの両方向—送信（リクエスト）と受信（レスポンス）を通過したデータの総量をカウントします。この量には、ペイロードだけでなく、すべての制御トラフィックも含まれます：プロトコルヘッダー、TLSメタデータ、TCPのACKパケット、タイムアウト時の接続再試行。
通常のページへの1つのリクエストに対して、「有用なデータ」と「制御データ」の比率は80/20かもしれません。しかし、応答が小さいAPI（数キロバイトのJSON）を扱っている場合、ヘッダーやハンドシェイクが多いと、比率は簡単に逆転します。これが、広告APIやマーケットプレイスに対して数万の小さなリクエストを送信するアービトラージャーが請求書に驚く理由です：各リクエストは、ペイロードのサイズに関係なく固定の「税金」を負担します。
もう1つ重要な点は、プロバイダーがプロキシサーバーレベルでトラフィックをカウントすることです。つまり、実際にIPを通過したすべてのトラフィックが含まれます—失敗した試行、リダイレクト、ページ上のリソース（スタイル、スクリプト、トラッカー）の再読み込みを含め、スクリプトやブラウザが自動的にリクエストしたもので、テキストだけが必要だったとしてもです。
HTTP/HTTPSヘッダー：各リクエストの隠れた重さ
各HTTPリクエストと各レスポンスには、User-Agent、Cookie、Accept-Language、Referer、Content-Typeなどのヘッダーのセットが含まれています。現代のブラウザやアンチデテクトツール（Dolphin Anty、AdsPower、Multilogin）では、ヘッダーのセットは1つのリクエストあたり500バイトから2〜3KBを占めることがあります—特にクッキーにセッションが数十の値を蓄積している場合は。
例：もしあなたが1.5KBのセッションクッキーを持つマーケットプレイスのAPIに10,000リクエストを送信する場合、ヘッダーだけで約15MBのトラフィックが消費されます—これはレスポンスボディを考慮していません。複数のアカウントやプロファイルにスケールすると、この数字は線形に増加します。
| ヘッダータイプ | 平均サイズ | トラフィックへの影響 |
|---|---|---|
| User-Agent | 100-150バイト | 低いが、スケールで蓄積される |
| Cookie（セッション） | 500-2000バイト | 長いセッションで高い |
| Referer / Origin | 50-200バイト | 低い |
| Accept-* ヘッダー | 150-300バイト | 低い |
| サーバーレスポンスヘッダー | 300-800バイト | 中程度、あなたには依存しない |
実践的な結論：もしあなたがWildberriesやOzonの価格監視のためのスクリプトを書いているなら、未使用の値からクッキーをクリーンアップし、DevToolsブラウザから「万が一」のためにコピーした余分なヘッダーをリクエストに持ち込まないでください。
TLSハンドシェイク：暗号化が消費するトラフィックの量
現代のウェブのほとんどはHTTPSを通じて動作しており、したがって各新しい接続はTLSハンドシェイクから始まります—証明書、暗号化キー、プロトコルパラメータの交換です。1回の完全なTLSハンドシェイク（TLS 1.2または1.3）は、サイトの証明書のサイズや使用されるプロトコルの拡張によって4〜8KBの重さがあります。
各リクエストごとに新しい接続を開く場合（持続的接続を使用しない場合）、TLSハンドシェイクは毎回繰り返されます。接続を再利用せずに10,000リクエストを行うと、暗号化だけで追加の40〜80MBのトラフィックが発生します—これは実際のペイロードよりも多いかもしれません。
TLS 1.3は、ラウンドトリップの数が減少するため、TLS 1.2よりも少し軽いですが、大量の接続がある場合にのみその違いが感じられます。モバイルプロキシの場合、オペレーターのネットワークが自らのレイテンシーやセッションの再設定を追加するため、TLSオーバーヘッドが特に顕著に感じられます—これは、頻繁な短いリクエストのタスクに対して< a href="https://proxycove.com/ja/mobile-proxies/" style="color:#2563eb;">モバイルプロキシを選択する際に考慮すべきです。
リトライ：再試行が消費を倍増させる方法
リトライは、最も目立たず、最も高価なトラフィック消費の項目です。もしあなたのパーサーやスクリプトがタイムアウトやエラー429/503の際に自動的に再試行するように設定されている場合、各失敗したリクエストは接続の確立、TLSハンドシェイク、ヘッダーに対してトラフィックを消費しており、その後このプロセスが再度繰り返されます。
SMMの自動化やマーケットプレイスのパーシングにおける一般的な誤りは、指数的な遅延なしに攻撃的なリトライポリシーを持つことです：スクリプトはIPがブロックされる最初の兆候で1秒間隔で5回の試行を行います。その結果、1つの「有用な」レスポンスに対して、5回の失敗した試行と最終的な成功したリクエストのトラフィックが消費されます。
特に、Avitoや大規模なマーケットプレイスなどの攻撃的な保護を持つサイトでデータセンタープロキシを使用する場合、これは特に重要です。これらのサイトは「ホット」IPからのほとんどのリクエストに対してキャプチャやブロックを返す可能性があります。この場合、レジデンシャルプロキシを検討する価値があります—これらは最初のリクエストからブロックされることが少なく、リトライの数を減らし、したがって実際のトラフィック消費を減少させます。
キープアライブ vs 新しい接続
HTTPキープアライブは、複数のリクエストのために1つのTCP/TLS接続を再利用することを可能にし、再ハンドシェイクを回避します。これは、ほとんどのHTTPクライアントやアンチデテクトブラウザで利用可能な最も効果的なトラフィック最適化の1つです。
もしあなたが明示的に持続的接続のセッションを指定せずにパーシング用のライブラリ（requests、httpx、axios）を使用している場合、各リクエストはデフォルトで新しいTCP接続を開く可能性があります。プロキシと組み合わせると、これはプロキシサーバーへの新しい接続、ターゲットサイトへの新しいTLS接続を意味し、すべてのオーバーヘッドが各呼び出しで繰り返されます。
| 接続モード | 1000リクエストあたりのオーバーヘッド |
|---|---|
| 各リクエストごとに新しい接続 | 4-8MB（TLSのみ） |
| キープアライブ、1つのセッションで50リクエスト | 0.1-0.2MB（グループごとに1回のハンドシェイク） |
差は数倍—これは、リクエストのペイロードに変更を加えることなく、純粋なトラフィックの節約です。
異なるタイプのプロキシによるトラフィックのカウント方法
トラフィックの請求モデルはプロキシのタイプによって異なります。データセンタープロキシでは、トラフィックの量やIP/ポートの数に基づく課金が一般的です—インフラストラクチャはより高速で、ルーティングに最小限のオーバーヘッドを追加します。レジデンシャルやモバイルプロキシでは、トラフィックは通常より厳しく請求されます。なぜなら、ユーザーの実際のIPはより高価で制限されたリソースであり、オペレーターや家庭のプロバイダーを通るルートは追加のホップを加え、それに応じて少し多くの制御データを追加するからです。
モバイルプロキシは、この意味で最も「高価」なトラフィックです：携帯ネットワークは独自のセッション再設定、NAT変換、時にはオペレーターのレベルでのトラフィックの圧縮/解凍のメカニズムを追加し、固定ネットワークを通じて同じリクエストと比較して通過したデータのカウントを増加させます。
もしタスクが安定した高いリクエスト量を最小限のオーバーヘッドで行うことであれば（たとえば、WildberriesやOzonの価格を大量にパースする場合）、データセンタープロキシが最適です—これらはより速く、同様のタスクに対するトラフィック消費が予測可能です。
実践的なトラフィック消費の削減方法
パーサー、オートメーション、またはマルチアカウントの機能を失うことなく、実際のトラフィック消費を削減する具体的なステップを見ていきます。
1. 不要なリソースの読み込みをオフにします。 ページのテキストやAPIのJSONレスポンスだけが必要な場合は、アンチデテクトブラウザやヘッドレスツールの設定で画像、フォント、分析スクリプト、広告トラッカーの読み込みをオフにしてください。これは、パーシングタスクのトラフィック消費を60〜80％削減することがよくあります。
2. キープアライブと接続プールを使用します。 HTTPクライアントを設定して、同じホストへのリクエストグループのためにセッションを再利用するようにします—これによりTLSハンドシェイクの数が大幅に減少します。
3. 理にかなったリトライポリシーを設定します。 指数的な遅延（1秒→2秒→4秒）を持つ3回の試行に制限することで、攻撃的な5〜10回の連続試行による無駄なトラフィックを削減し、同時にIPの追加ブロックのリスクを減少させます。
4. セッションのクッキーとヘッダーをクリーンアップします。 定期的に、ターゲットサイトで使用されていないクッキーの蓄積された値を削除します—特にInstagramやTikTokのアカウントをウォームアップする長いセッションに対しては特に重要です。
5. 静的なレスポンスをキャッシュします。 データ（たとえば、商品カタログ）が毎分変わらない場合は、監視サイクルごとにプロキシを通じて再リクエストするのではなく、ローカルにレスポンスをキャッシュします。
6. 圧縮を使用します。 Accept-Encoding: gzipヘッダーが送信され、サーバーが実際に圧縮されたレスポンスを返すことを確認します—これは、大量のテキストやJSONを含むページでの受信トラフィックの量を削減します。
トラフィック監視のためのツール
トラフィックが実際にどこに消えているのかを理解するためには、プロバイダーのカウンターだけでなく、リクエストの詳細な内訳を見ることが役立ちます。以下のツールが適しています：
- Charles Proxy / Fiddler — 各リクエストとレスポンスのサイズを表示し、ヘッダーを含めて「重い」クッキーや余分なリソースを見つけるのに役立ちます。
- Wireshark — パケットレベルでのTCP/TLSオーバーヘッドの深い分析に使用し、ハンドシェイクの実際の重さを評価する必要がある場合に役立ちます。
- アンチデテクトブラウザの組み込みトラフィックカウンター（Dolphin Anty、AdsPower、GoLogin） — 多くは各プロファイルごとの消費を表示し、アカウント間の予算配分に便利です。
- HTTPクライアントレベルでのロギング — 自分のパーシングスクリプトを書く際に、各呼び出しのリクエスト/レスポンスのサイズをロギングすることが役立ち、異常を見つけることができます。
あなたのツールの測定値とプロキシプロバイダーのカウンターを比較することで、トラフィックがどこで失われているのか—リトライ、TLS、または余分なリソースの読み込み—を迅速に理解するのに役立ちます。
起動前の最適化チェックリスト
パーサーの大規模な起動、SMMの自動化、または広告アカウントのウォームアップの前に、短いリストを確認してください：
- 画像、フォント、分析が不要な場所での読み込みがオフになっている；
- 1つのホストへのリクエストシリーズのためにキープアライブ/セッションの再利用が設定されている；
- リトライポリシーが無限の再試行ではなく、遅延を持つ2〜3回の試行に制限されている；
- セッションのクッキーが定期的に未使用の値からクリーンアップされている；
- レスポンスの圧縮（gzip/deflate/br）が有効になっている；
- 繰り返しの静的リクエストのためにローカルキャッシュがある；
- タスクに応じたプロキシのタイプが選択されている：速度とボリュームのためのデータセンタープロキシ、ブロック回避のためのレジデンシャルプロキシ、ソーシャルメディアや広告プラットフォームのためのモバイルプロキシ。
結論
プロキシを通じたトラフィックの消費は、ページの有用なデータだけでなく、すべての制御オーバーヘッド—ヘッダー、TLSハンドシェイク、エラー時の再試行—を含みます。このメカニズムを理解することで、プロキシの予算をより正確に計画し、特にマーケットプレイスのパーシング、SMMの自動化、または広告アカウントのウォームアップのスケーリング時に不快なサプライズを避けることができます。
あなたのタスクが予測可能なトラフィック消費で安定したパーシングである場合、データセンタープロキシに注目してください。ソーシャルメディアや広告プラットフォームでの低いブロック頻度が重要な場合は、モバイルプロキシがより適しています。そして、サイトの保護を回避するために匿名性と安定性のバランスが必要な場合は、レジデンシャルプロキシを検討してください。これにより、ブロックが少なくなり、リトライの数が減少します。