プロバイダーは「1000万以上のIP」を約束しますが、実際には数分ごとに同じアドレスを受け取ります。これはプロキシサービスのマーケティングにおける誇張された数字の典型的な状況です。実際のプールのサイズを確認する簡単で信頼できる方法があります。それは、一連のリクエストを行い、どれだけのユニークIPを取得したかを数えることです。この記事では、結果を歪めるエラーなしにこれを正しく行う方法を説明します。
プロキシプールのサイズを確認する理由
プールのサイズは、大量のリクエストを行った際にIPアドレスがどれだけ頻繁に繰り返されるかに直接影響します。もしあなたがアービトラージャーで、50のFacebook Adsアカウントを運用している場合、複数のプロファイルで繰り返されるIPは、アカウントのチェーンバンにつながる直接的な道です。もしあなたがSMMスペシャリストで、Dolphin Antyを通じて30のクライアントのInstagramアカウントを管理している場合、IPの繰り返しは、プラットフォームのアンチフロードシステムの目には異なるクライアントのアカウントを結びつけるリスクとなります。
WildberriesやOzonのセラーにとって、小さな実際のプールは、競合の価格を解析するパーサーがすぐにレート制限やキャプチャに引っかかることを意味します。サイトは同じアドレスからの数十のリクエストを見て、それをブロックします。広告のジオターゲティングをテストしているマーケティング担当者にとって、リクエストが異なるサブネットや都市から送信されているかどうかを理解することは重要です。そうでなければ、同じデータセンターの3つの繰り返しIPから送信されているかもしれません。
確認には10-15分かかりますが、その結果はアカウントの解除や「新しい」IPが古い知り合いである理由を解明するために数週間の作業を節約します。
プロバイダーが数字を誇張する理由
公表されたプールのサイズは、しばしばプロバイダーのネットワークで理論的に利用可能なアドレスの総数であり、長い間発行されていないIP、ターゲットプラットフォームによって禁止されたIP、またはレジデンシャルおよびモバイルプロキシの場合は非アクティブなデバイスに属するIPを含みます。リクエスト時点で実際に利用可能なサンプルは、数倍少ない場合があります。
もう一つの理由があります:多くのプロバイダーのIPローテーションは「セッションごとに新しいIP」の原則で動作しますが、ローテーションプールは特定のジオまたはISPのサブネットに制限される場合があります。もしあなたがアメリカのIPのみをリクエストしている場合、プロバイダーの全体のプールがすべての国を対象としている場合、実際に利用可能なアドレスの数は宣伝されているものとは大きく異なる可能性があります。
だからこそ、1000リクエストのテストは単なる偏執病ではなく、プロキシプロバイダーでビジネスプロセスを構築する前の必須のデューデリジェンスのステップなのです。アカウントや24/7で稼働するパーサーが何十もある場合は特に重要です。
確認方法:1000リクエストとユニークIPカウンター
方法の論理は簡単です:あなたは、現在の外部IPを返すサービスにNリクエストを行います(例えば、httpbin.org/ipやapi.ipify.orgなど)。各リクエストごとに、プロキシはあなたのローテーション設定に従ってIPを変更する必要があります。取得したすべてのアドレスは集合(set)に蓄積され、重複が自動的に除外されます。最後に、ユニークIPの数を総リクエスト数で割ります。これがプールの実際のユニーク性係数です。
正確なテストには、3つの条件が重要です:
- リクエストは、実際の使用シナリオに対応する間隔で行う必要があります。実際の作業で5分ごとにIPを変更する場合、3秒で1000リクエストを行う必要はありません。
- 各リクエストは新しいプロキシセッションを開始する必要があります(レジデンシャルおよびモバイルプロキシの場合、これは通常、新しいスティッキーセッショントークンまたは接続の完全な再作成を意味します)。
- テストするのは、実際に本番で使用する予定のジオとプロキシのタイプである必要があります。一般的なプールでのテストは、特定の国の実際の状況を示しません。
1000という数字は偶然ではありません。これは、結果の統計的有意性を確保するために十分なサンプルサイズであり、テストは合理的な時間内に実行され、プロバイダーに過剰な負荷をかけません。
テスト用のPythonスクリプト
以下は、プロキシを通じて1000リクエストを行い、ユニークIPをカウントする作業スクリプトです。PROXY_HOST、PROXY_PORT、PROXY_USER、PROXY_PASSの変数を、あなたのプロキシプロバイダーのアカウントからのデータに置き換えてください。
import requests
import time
from collections import Counter
PROXY_HOST = "proxy.example.com"
PROXY_PORT = "8000"
PROXY_USER = "login"
PROXY_PASS = "password"
proxy_url = f"http://{PROXY_USER}:{PROXY_PASS}@{PROXY_HOST}:{PROXY_PORT}"
proxies = {"http": proxy_url, "https": proxy_url}
TOTAL_REQUESTS = 1000
DELAY_SECONDS = 0.5 # リクエスト間の遅延
ip_counter = Counter()
errors = 0
for i in range(TOTAL_REQUESTS):
try:
response = requests.get(
"https://api.ipify.org?format=json",
proxies=proxies,
timeout=10
)
ip = response.json().get("ip")
ip_counter[ip] += 1
except Exception as e:
errors += 1
time.sleep(DELAY_SECONDS)
unique_ips = len(ip_counter)
success_requests = TOTAL_REQUESTS - errors
uniqueness_ratio = unique_ips / success_requests if success_requests else 0
print(f"成功したリクエスト数: {success_requests}")
print(f"エラー数: {errors}")
print(f"ユニークIP数: {unique_ips}")
print(f"ユニーク性係数: {uniqueness_ratio:.2%}")
print("最も繰り返されるIPトップ5:")
for ip, count in ip_counter.most_common(5):
print(f" {ip}: {count} 回")
スクリプトはまた、繰り返されるIPのトップを出力します。これは、異常に頻繁にプロバイダーによって提供される1つまたは2つのアドレスが「引っかかっている」かどうかを理解するのに役立ちます。そのようなアドレスがあり、それらの割合がすべてのリクエストの5-7%を超える場合、これはプロバイダー側のローテーションに問題があることを示す信号です。
コードなしでcURLを使った簡単な確認
スクリプトを書く気がない場合、ターミナルを通じて簡略化された確認を行うことができます。次のbashコマンドは50リクエストを行い、取得したすべてのIPをファイルに保存します。これにより、Pythonをインストールせずに迅速な評価が得られます:
for i in {1..50}; do
curl -s -x "http://login:[email protected]:8000" \
https://api.ipify.org >> ip_list.txt
echo "" >> ip_list.txt
sleep 0.5
done
sort ip_list.txt | uniq -c | sort -nr
コマンドsort | uniq -cは、各IPの繰り返し回数を示すユニークIPのリストを表示します。これは、Pythonスクリプトと同じ原則ですが、プログラムを書くことなく実行できます。迅速な確認には50-100リクエストで十分であり、明らかなローテーションの問題を見つけることができます。
テスト結果の解釈方法
ユニーク性係数はプロキシのタイプによって異なります。安価なデータセンターのプロキシから100%のユニーク性を期待するべきではなく、レジデンシャルプロキシが95%未満を示す場合でも驚くべきではありません。一部のプロバイダーは、物理的に無限の数の家庭用IPが存在できない制限されたジオのプールを使用しています。
| プロキシの種類 | 1000リクエストでの期待されるユニーク性 | 評価 |
|---|---|---|
| レジデンシャルプロキシ | 90-99% | 標準 |
| モバイルプロキシ | 70-95% | 標準(ジオのオペレーターの密度による) |
| データセンターのプロキシ | 50-90% | 標準ですが、特定のサブネットの公表されたプールによります |
| 任意のタイプ | 30%未満 | 問題 — プールが広告で大幅に膨れ上がっているか、ローテーションが壊れている |
全体の係数に加えて、分布にも注目してください。もし1000リクエストのうち900が異なるIPを返し、100リクエストが同じアドレスに集中している場合、これは同じ平均係数を持つ均等な分布よりも悪い結果です。均等性は、特にマルチアカウント作業のタスクにおいて、全体のユニーク性のパーセンテージよりも重要です。IPがプロファイルに再結びつけられることが重要です。
コードなしでDolphin AntyとAdsPowerでプールを確認する方法
スクリプトを使用したくない場合、アンチデテクトブラウザは、同様の確認のための組み込みツールを提供しますが、規模は小さくなります。Dolphin Antyでは、「プロキシ」セクションを開き、必要なプロキシを選択し、数分間隔でIP確認ボタンを何度も押して、結果を手動で表に記録します。AdsPowerでも同様に、プロキシ管理セクションに「Check」ボタンがあり、現在のIP、国、ネットワークプロバイダーを表示します。間隔を置いて繰り返し確認することで、アドレスが変更されるかどうかを確認できます。
この手動の方法は、大量のプロキシを購入する前の迅速なサンプリング確認に適していますが、1000リクエストの完全なテストの代わりにはなりません。プロセスを数十または数百のアカウントにスケールアップする予定がある場合は、上記のセクションからスクリプトを実行し、統計的に有意なデータを取得する方が良いです。
プールテストでのよくある間違い
最初の間違いは、あまりにも早くリクエストを行い、間隔をあけないことです。一部のプロバイダーは、短い時間枠内で同じIPを意図的に返します(スティッキーセッション)、そして間隔をあけずに迅速なテストを行うと、実際の使用間隔では問題がないにもかかわらず、歪んだ低いユニーク性が示されます。
2つ目の間違いは、IP確認サービスを介してテストすることです。このサービスは自ら応答をキャッシュしたり、実際のアドレスの代わりにジオロケーションを返したりします。ipify.orgやhttpbin.org/ipのような信頼できるサービスを使用してください。これらは自らの側でキャッシュなしでクリーンなJSONを返します。
3つ目の間違いは、タイムアウトや接続エラーを全体の統計に考慮しないことです。もし1000リクエストのうち200がエラーで終了した場合、あなたがユニーク性を1000からではなく800の成功したリクエストから計算していると、係数は悪い方向に歪むことになります。
4つ目の間違いは、実際に必要なジオをテストしないことです。プールはグローバルには巨大かもしれませんが、特定の都市や州にとっては小さすぎる場合があります。特にローカルなジオは、ジオターゲティング広告やローカルSMMにとって重要です。
プールが小さい場合の対処法
テストが低いユニーク性係数を示した場合、最初のステップは、テストの具体的な数字を持ってプロバイダーにサポートを求め、その理由を説明してもらうことです。誠実なプロバイダーは通常、ジオとプロキシのタイプに基づいてプールの構造を透明に説明し、より狭いが実際に機能するサンプルを提案することができます。
2つ目のオプションは、タスクに応じてプロキシのタイプを見直すことです。アカウントのファーミングや広告プラットフォームとの作業には、データセンターのIPのローテーションの強度を増やすのではなく、レジデンシャルまたはモバイルプロキシに切り替える方が効果的な場合が多いです。これにより、ネットワークの特性がアドレスのより自然な分布とアンチフロードシステムへの目立たなさを保証します。
3つ目のオプションは、プールへの負荷を軽減することです:IPの変更間隔を増やす、タスクを複数のサブネットやジオに分散させる、プラットフォームが特定の国からの作業を許可する場合。時には、プールを増やすのではなく、リクエストパターンを変更して、実際に利用可能なユニークアドレスの量に適合させることが解決策です。
結論
ユニークIPのカウントを伴う1000リクエストのテストは、プロキシの実際のプールがプロバイダーの公表した数字に合致しているかを確認するための迅速かつ客観的な方法です。Pythonの準備されたスクリプトやcURLを使った簡略化された確認は、最小限の時間で行え、その結果はアカウントのバン、マーケットプレイスのパーシング時のブロック、タスクに適さないプロキシへの無駄な支出を避けるのに役立ちます。
Facebook AdsやTikTok Adsの広告アカウントをファーミングしたり、Dolphin AntyやAdsPowerを通じて数十のInstagramプロファイルを運用する予定がある場合は、モバイルプロキシに注目してください。これらは通常、IPのより自然な分布を示し、プラットフォームのアンチフロードシステムに引っかかることが少なくなります。WildberriesやOzonの価格解析や、速度と安定性が重要なタスクのためには、この記事の方法で<а href="https://proxycove.com/ja/residential-proxies/" style="color:#2563eb;">レジデンシャルプロキシをテストすることをお勧めします。そうすれば、彼らに基づいて恒常的な作業プロセスを構築する前に、実際のデータを得ることができます。