プロキシのテストの多くは、接続が成功し、自分のIPアドレスとは異なるアドレスが返ってくるかどうかを確認するだけのものであり、これは5秒程度で済む便利な簡易チェックではありますが、そのプロキシが実際に自分の目的を果たしてくれるかどうかについては、ほとんど何も教えてくれません。
プロキシは、接続が完璧に成立し、もっともらしい外国のアドレスを返し、応答も速くても、まったく役に立たない場合があります。それは、実際にアクセスしたいサイトがそれをブロックしているから、販売された国とは異なる国でジオロケーションされているから、あるいはホスト名の解決がまったく別の場所に行っているからかもしれません。
私たちは Geonode であり、プロキシを販売しています。そのため、この記事は私たちの立場とは少し矛盾しています。適切なテスト手順こそが、顧客がプロバイダーが期待通りのサービスを提供していないことを発見する手段であり、私たちは皆さんに私たちに対してそのテストを実行するよう勧めているのです。 これは意図的なものです。 この市場において最もコストのかかる結果は、ターゲットに対して一度も正常に機能しなかったサービスに何ヶ月も料金を払い続けることです。そして、それが起こる原因は、ユーザーが実行したテストが「接続できるか」だけだったからです。
以下の4つのテストは、セットアップに半日ほどかかり、その後の実行にはおよそ1分程度かかります。重要度の高い順に大まかに並べると：
- 接続性と報告されるアドレス — 迅速で、必要だが、不十分。
- 位置情報の精度 — アドレスが、販売時に説明された場所と実際に一致しているかどうか。
- 情報漏洩 — ヘッダーやDNS。これらはいずれも、テスト全体を台無しにする可能性がある。
- 実際のターゲットに対する成功率 — すべてを決定づける要素。
以下で推奨するエンドポイントはすべて、執筆時点で確認済みであり、正常にレスポンスを返していました。これは最低限の基準ではありますが、驚くほど多くの公開ガイドが、数年前にサービス終了しているものを推奨しています。
テストする価値のある4つの項目
コマンドを紹介する前に、その根拠を説明します。各テストが存在する理由を理解することで、テストが失敗した際の解釈の仕方がわかるからです。
接続性
プロキシは接続を受け入れ、認証を行い、リクエストを転送していますか？ 宛先が認識するアドレスは、あなた自身のものではなく、プロキシのものでしょうか？
これは最低限確認すべき事項であり、多くの人がここでテストを終わらせてしまいます。
地理位置情報
ベルリンにあると販売されているアドレスが、実際にはフランクフルトやオランダ、あるいは特定の場所ではないと分類される可能性があります。 地理位置情報データベースは互いに一致しないものであり、重要なのはターゲット側が使用するデータベースであって、プロバイダーが使用したデータベースではありません。
これはよくある、そして本当に紛らわしい失敗例です。すべてが正常に動作し、プロキシはドイツのアドレスを報告しているにもかかわらず、サイトはオランダのコンテンツを表示し続けてしまうのです。
リーク
2種類あり、いずれも気づかないうちに目的を台無しにしてしまう可能性があります。
ヘッダーのリーク。 一部のプロキシは、元のクライアントのアドレスを明かしたり、プロキシが使用されていることを通知したりするヘッダーを追加します。プロキシを使用する理由が「宛先に一般ユーザーとして認識されるため」である場合、それとは異なる情報を示すヘッダーは問題となります。
DNSリーク。 トラフィックはプロキシを経由しますが、ホスト名の解決はローカルで行われます。リゾルバー（通常はISP）は、あなたがアクセスするすべてのサイトを把握してしまいます。さらに悪いことに、ローカルで解決されたホスト名が地域的に誤ったアドレスを返す可能性があり、その結果、正しい国から間違ったエンドポイントに接続してしまうことになります。
ターゲットサイトでの成功率
実際の作業に結果が反映される唯一のテストです。
上記のすべては一般的なものであり、公開エンドポイントに対して測定可能です。しかし、そのどれもが、あなたがアクセスする必要がある特定のサイトがコンテンツを提供してくれるかどうかを予測するものではありません。 前述の3つのテストをすべて通過したプロキシであっても、ターゲット側で完全にブロックされる可能性があり、一見何の問題もなさそうなプロキシが完璧に機能することもあります。
大量購入を行う前に、必ずこれを測定してください。 これが、「機能するプロキシ」と「単に接続できるだけのプロキシ」との違いなのです。
接続できるか、どのアドレスが表示されるか
基本的なテストです。執筆時点で、各エンドポイントの応答が確認されています。
ワンライナー
curl -x http://user:pass@proxy.example.com:8080 https://api.ipify.org?format=json
自分のアドレスではないアドレスが返ってきた場合、プロキシは最低限のレベルで機能しています。
便利なエンドポイント
| エンドポイント | 返される内容 |
|---|
https://api.ipify.org?format=json | アドレスのみ。最小限の情報で高速 |
https://httpbin.org/ip | アドレス（JSON形式） |
https://ipinfo.io/json | アドレスに加え、位置情報とネットワークの詳細 |
http://ip-api.com/json | アドレスに加え、詳細な地理位置情報 |
https://ifconfig.me/all.json | アドレスに加え、送信したヘッダー |
最後のものは知っておく価値があります。なぜなら、これはあなたのリクエストをそのまま反映しているからです。これにより、特別なツールを使わずにヘッダーの漏洩を確認することができます。
実際のアドレスと比較する
# Without the proxy
curl -s https://api.ipify.org
echo
# With it
curl -s -x http://user:pass@proxy.example.com:8080 https://api.ipify.org
値が異なれば、プロキシが経路に含まれていることを意味します。 値が同じ場合はプロキシが介在していないことを意味します。これは想像以上に頻繁に発生しますが、通常はプロキシURLのタイプミスが原因で、curlがそれを黙って無視してしまったためです。
値が一致する場合は -v を追加し、curlが実際にどのホストに接続したかを確認してください。
エラーとその意味
Connection refused — ホストまたはポートが間違っているか、プロキシがダウンしています。
407 Proxy Authentication Required — 認証情報が間違っているか、不足しています。一部のプロバイダでは、代わりに自身のアドレスを許可リストに登録することで認証を行う場合があります。その場合、現在のアドレスがリストに含まれていない可能性があります。
タイムアウト — プロキシに接続できないか、過負荷状態です。--max-time 10 を追加して、待ち続けるのではなく、すぐに状況を確認できるようにしましょう。
動作はするが、アドレスが自分のものになっている — プロキシ設定が適用されていません。入力ミスがないか確認し、環境変数が指定した設定を上書きしていないか確認してください。
SOCKS を適切にテストする
curl -x socks5h://user:pass@proxy.example.com:1080 https://api.ipify.org
socks5h であることに注意してください。socks5 ではありません。h を指定すると、プロキシが自分のマシンではなくホスト名を解決してしまいます。これは後述する DNS リークであり、この分野で最も一般的な「半ば機能している」設定です。
位置情報の精度
誰も警告してくれない、実際に頻繁に発生する問題を突き止めるテスト。
コマンド「
curl -s -x http://user:pass@proxy.example.com:8080 http://ip-api.com/json | python3 -m json.tool
」 これにより、国、地域、都市、およびその住所が属する組織が取得できます。
確認すべき点
国が契約内容と一致しているか。 これは当然のことですが、安価なIPプールでは想定以上に頻繁に失敗します。
都市名が妥当であること。 マンチェスターのアドレスを購入したのにロンドンと報告される場合、多くの用途では問題ないかもしれませんが、ローカル検索のテストにおいては致命的です。
組織名が一般消費者向けISPのように見えること（住宅用IPを購入した場合）。 ホスティング会社として報告される場合、販売時の表記に関わらず、そのアドレスはデータセンターのアドレスとなります。これは、保護されたサイトで機能する製品と機能しない製品との違いに関わるため、特に確認する価値があります。
多くの人が混乱する点
ジオロケーションデータベースの情報が一致しない。 住所から場所への決定的な対応関係は存在しません。登録データ、ルーティング、観測情報から場所を推測する商用データベースがいくつかあり、それらは異なる方法とタイミングで更新されています。
したがって、ある住所は次のように判定される可能性があります：
- あるデータベースではベルリン
- 別のデータベースではフランクフルト
- 3つ目のデータベースではドイツだが都市名は不明
- 最近再割り当てされたため、別のデータベースではオランダと判定される
対象サイトはこれらの一つを使用していますが、どれを使用しているかはわかりません。 これが、テストではドイツと判定された住所でも、あなたが注目しているサイトではオランダ語のコンテンツが表示されることがある理由であり、唯一決定的なジオロケーションテストは対象サイト自体で行うしかない理由です。
実践的なテスト
2～3つのデータベースを確認した後、ターゲット（
PROXY="http://user:pass@proxy.example.com:8080"
curl -s -x $PROXY http://ip-api.com/json | python3 -m json.tool
curl -s -x $PROXY https://ipinfo.io/json | python3 -m json.tool
）を確認してください。結果が一致すれば、購入した通りの内容である可能性が高いでしょう。結果が一致しない場合は、ターゲット側の判断が唯一の基準となります。プロキシ経由で実際のサイトを読み込み、どの通貨、言語、地域向けコンテンツが表示されるかを確認してください。
ヘッダーとDNSリーク
これらは2つの「目立たない不具合」であり、どちらも確認は簡単ですが、実際にはほとんどチェックされません。
ヘッダーの漏洩
一部のプロキシは、元のアドレスを明かしたり、プロキシが介在していることを示したりするヘッダーを追加することがあります。宛先にリクエストを反射させて確認してください：
curl -s -x http://user:pass@proxy.example.com:8080 https://httpbin.org/headers | python3 -m json.tool
存在してはならないヘッダー： 実アドレスを含む「
X-Forwarded-For
」。Via
。X-Real-IP
。Forwarded
。Proxy-Connection
。プロキシベンダー名を記載したもの。
X-Forwarded-For: your.real.address
を追加するプロキシは、隠蔽という観点からはまったく意味を成しません。単に、宛先が読み取れるようにリクエストにあなたのアドレスを書き込んだに過ぎないからです。
この業界で説明されている3つの匿名性レベルは、このテストにそのまま当てはまります。「透過型」プロキシは、ヘッダーにあなたのアドレスを転送します。 匿名プロキシはアドレスを転送しませんが、自身をプロキシとして識別します。エリートプロキシはどちらも行いません。上記のコマンドを実行すれば、現在使用しているプロキシの種類がわかります。リストを鵜呑みにするよりも、実際に実行してみる価値があります。
DNSリーク
単一のコマンドではテストが難しく、多くの人が認識している以上に重大な影響を及ぼします。
問題点：トラフィックはプロキシを経由しますが、ホスト名の解決は自身のマシンで行われます。トラフィックが別の場所にルーティングされていても、リゾルバーはあなたがアクセスしたすべてのサイトを把握してしまいます。
curl と SOCKS の場合、修正はたった 1 文字です：
# Leaks the lookup to your local resolver
curl -x socks5://proxy.example.com:1080 https://example.com
# Proxy resolves the hostname
curl -x socks5h://proxy.example.com:1080 https://example.com
HTTP プロキシの場合、ホスト名の解決は通常プロキシ側で行われるため、この問題はそれほど深刻ではありません。ただし、特にクライアントライブラリが関与している場合は、推測するのではなく確認してください。
なぜこれが単なるプライバシーの問題ではないのか： ローカルで解決されたホスト名によって、地域によって異なるサーバーに接続される可能性があります。ドイツ経由でプロキシ接続しているにもかかわらず、英国からホスト名解決が行われている場合、ドイツのIPアドレスから英国のエンドポイントに接続することになります。この組み合わせは、本来の目的から外れているだけでなく、異常に目立つため、気づかれる可能性があります。
確認方法
プロキシを経由してDNSリーク検査サービスを利用し、報告されたリゾルバーが自身のネットワークではなく、プロキシのネットワークに属していることを確認してください。所要時間は30秒で、ターゲットテストに次いで、この記事で最も価値のある検証方法です。
実際のターゲットにおける成功率
他の3つのテストを合わせたものよりも重要であり、購入前に実施する人がほとんどいないテストです。
一般的なテストでは予測できない理由
これまでのテストはすべて、誰をもブロックする理由のない中立的な公開エンドポイントに対してプロキシを評価するものです。しかし、あなたのターゲットは中立ではありません。ターゲットは、アドレスの発信元を確認したり、独自のブロックリストを維持したり、レート制限を適用したり、クライアントのフィンガープリントを取得したり、地域ごとに異なるコンテンツを提供したりする可能性があります。
あらゆる一般的なテストに合格したプロキシであっても、あなたのターゲットによって完全にブロックされる可能性があります。 一見ごく普通に見えるプロキシが、完璧に機能することもあります。一般的なテストはプロキシが機能していることを示すだけであり、実際に機能しているかどうかはターゲット側でしか確認できません。
方法
実際に必要なURLの代表的なサンプルを用意します。ホームページではなく、仕事に関わるページを選んでください。50～数百件あれば、有意義な結果が得られます。
それらをプロキシ経由で実行します。以下の項目を記録してください：
成功した件数。ここで「成功」とは、レスポンスに目的のコンテンツが含まれていたことを意味し、HTTP 200が返されたことではありません。
消費された帯域幅（失敗分も含む）。
各リクエストにかかる時間。
成功数のカウントにおける落とし穴
これは本番システムで何ヶ月も放置されがちな問題であるため、特に注意を促す必要があります。
HTTP 200を成功としてカウントしてはいけません。 ここで典型的な失敗のパターンは、一見すると本物に見えるが内容が間違っているページです。例えば、認証要求ページ、ソフトブロック、 「不審なアクティビティが検出されました」というインタースティシャル、地域別のバリエーション、あるいは正当な空の結果セットと全く同じように見える空の結果セットなどです。これらすべてが200を返します。
真に成功したページにのみ表示される要素——価格、商品名、特定の要素、最低限のコンテンツ量——を確認してください。ステータスコードだけを信頼する成功カウンターは、実際には何も収集できていないにもかかわらず、素晴らしい数値を報告してしまうでしょう。
重要な数値
cost per successful request = (bandwidth used × price per GB) ÷ successes
失敗したリクエストも成功したものと同様に有料の帯域幅を消費するため、プロバイダーを意味のある形で比較できる唯一の数値がこれです。ターゲットに対する成功率が低い安価なプロキシは、正常に機能する高価なプロキシよりも、結果1件あたりのコストが高くなる可能性があります。
同じ朝に、同じターゲットリストと同時実行数で2～3社のプロバイダーに対してこのテストを実行すると、ランキングは価格表とはしばしば異なる結果になります。これこそが、このテストを行う意義なのです。
リスト全体をテストするスクリプト
プロキシを1つ手動でテストする分には問題ありません。しかし、200個もテストするにはスクリプトが必要です。
import concurrent.futures
import time
import requests
TEST_URL = "https://api.ipify.org?format=json"
TIMEOUT = 10
def check(proxy):
"""Return a dict describing one proxy's behaviour."""
proxies = {"http": proxy, "https": proxy}
started = time.perf_counter()
try:
r = requests.get(TEST_URL, proxies=proxies, timeout=TIMEOUT)
elapsed = time.perf_counter() - started
if r.status_code != 200:
return {"proxy": proxy, "ok": False, "error": f"HTTP {r.status_code}"}
return {
"proxy": proxy,
"ok": True,
"ip": r.json().get("ip"),
"seconds": round(elapsed, 2),
}
except Exception as exc:
return {"proxy": proxy, "ok": False, "error": type(exc).__name__}
def main(proxy_list, workers=20):
with concurrent.futures.ThreadPoolExecutor(max_workers=workers) as pool:
results = list(pool.map(check, proxy_list))
working = [r for r in results if r["ok"]]
print(f"{len(working)}/{len(results)} responded")
for r in sorted(working, key=lambda x: x["seconds"]):
print(f"{r['seconds']:>6}s {r['ip']:<16} {r['proxy']}")
for r in results:
if not r["ok"]:
print(f" FAIL {r['proxy']} ({r['error']})")
if __name__ == "__main__":
main([
"http://user:pass@proxy1.example.com:8080",
"http://user:pass@proxy2.example.com:8080",
])
注目すべき点
すべてのリクエストにはタイムアウトが設定されています。 これを設定しないと、1つのプロキシが応答しなくなっただけでワーカーが無限にハングし、実行が永遠に完了しなくなります。これは自作のプロキシチェッカーで最もよくある欠陥です。
例外は捕捉され、分類されます。そのため、1つの不良エントリがあっても実行が停止することはなく、失敗の原因がタイムアウト、拒否、認証の問題のいずれであるかを確認できます。
並行して実行されます。というのも、200個のプロキシを10秒のタイムアウト設定で1つずつテストしていたら、昼食の時間が長くなってしまいますから。
所要時間を記録します。これは、次のセクションでの速度比較の基礎となります。
実用的な拡張方法
TEST_URL を実際のターゲットに置き換え、ステータスチェックをコンテンツチェックに置き換えてください。これにより、接続性チェッカーから前のセクションで紹介した成功率テストへと変換され、そこに真の価値があります。
スケジュールに従って実行し、結果を保存してください。プロキシプールは変化するため、先月機能していたリストは今日の状況を反映しているとは限りません。
速度と遅延――正しい測定方法
速度は人々が考えるほど重要ではなく、その測定も往々にして不適切に行われています。
単一の数値ではなく、内訳を把握する
curl を使えば、実際にどこで時間がかかっているのかが分かります：
curl -s -o /dev/null -x http://user:pass@proxy.example.com:8080 \
-w "dns=%{time_namelookup} connect=%{time_connect} tls=%{time_appconnect} ttfb=%{time_starttransfer} total=%{time_total}\n" \
https://example.com
これらの数値の差から、何が遅延の原因なのかが分かります。ホスト名解決、TCPハンドシェイク、TLSネゴシエーション、あるいはサーバーの処理などです。単一の合計値だけでは何も分かりませんし、「プロキシが遅い」と言われる場合、実際には「ターゲットが遅い」ことがよくあります。
1回きりでなく、繰り返し測定する
1回の測定結果はノイズに過ぎません。10回実行して中央値を算出し、最悪のケースを記録しておきましょう。
大規模に実行される処理においては、平均値よりも95パーセンタイルの方が重要です。平均400ミリ秒という数値では、20件に1件のリクエストが8秒かかっているという事実が見え隠れしており、スケールアップすると、こうしたリクエストがワーカープールを埋めてしまうことになります。
同等の条件で比較する
同じターゲット、同じ時間帯、同じ同時接続数。一般家庭向けプロキシの構成は、実際のユーザーがオンラインになる時間帯によって変化するため、午前3時のテストと午後6時のテストでは、測定されるネットワークが異なります。
バランスを考慮する
レジデンシャルプロキシはデータセンタープロキシよりも遅く、これは本質的な特性です — データセンターのバックボーンではなく、一般家庭のブロードバンドを経由してルーティングされるためです。速度だけで比較すると、常にデータセンターのアドレスが有利に見えますが、ターゲットでデータセンターのアドレスが機能しない場合、それは有用な情報とは言えません。
まずは成功率で順位付けしましょう。実際に機能する選択肢の間でのみ、速度を比較してください。高速でもブロックされてしまうプロキシには価値がありません。一方、速度は遅くてもコンテンツを取得できるプロキシこそが、最も価値があるのです。
プロキシチェッカーサイトではわからないこと
無料のWebベースのチェッカーは、ある点では確かに有用ですが、他のいくつかの点では誤解を招く恐れがあります。
得意な点
プロキシが稼働しており、接続可能かどうかを素早く確認できること、および転送されるヘッダーから匿名性の大まかな分類を行うことです。 未知のプロキシが大量にあるリストを初期選別する上では、手間をかけずに得られる真の価値と言えます。
できないこと
ターゲットの状況を予測すること。 これらのツールは、自分自身を基準にテストを行っています。ターゲット側には、異なる防御策、異なるブロックリスト、そして地域ごとの異なる挙動が存在します。これが最大の限界であり、非常に大きな問題です。
ターゲット側から見た地理的位置情報を提供すること。 これらは単一のデータベースを使用していますが、ターゲット側は別のデータベースを使用しています。
経時的な成功率を測定すること。 単一のチェックはあくまでその時点のスナップショットに過ぎません。プロキシプールはローテーションされ、アドレスは再利用され、レピュテーションは1時間ごとに変化します。
認証を適切にテストする。 多くのチェッカーはホストとポートのみを受け入れるため、認証情報を必要とするものはそこでテストできません。
注意すべき点
認証情報を含む動作中のプロキシをサードパーティのチェッカーに貼り付けると、見知らぬ人に有効な認証情報のセットを渡すことになります。
無料のパブリックプロキシであれば、損失はありません。しかし有料プロキシの場合、これは極めて不注意な行為です。それらの認証情報はあなたのアカウントや請求書に紐づいているからです。有料プロキシのテストは、他人のウェブサイトではなく、自分のコマンドを使って行ってください。
無料プロキシリスト全般について
テストツールと無料リストはセットで提供される傾向があるため、関連する警告を付け加えます。無料のパブリックプロキシとは、運営者が自費で見知らぬ人のトラフィックを中継することを志願しているサーバーのことです。その妥当な理由は限られており、その中でも「何が通過しているかを確認する」という目的が顕著です。
また、それらは本質的に信頼性が低いものです。過負荷になりやすく、寿命が短く、アクセスする価値のあるサイトからはすでにブロックされていることが頻繁にあります。テストを行っても、現時点で応答するプロキシがどれかを知るだけであり、その情報は極めて短期間しか有効ではありません。
よくある質問
プロキシが機能しているかどうかを確認するにはどうすればよいですか？
プロキシを経由してアドレス報告エンドポイントにリクエストを送信し、実際のアドレスと比較してください：curl -x http://user:pass@host:port https://api.ipify.org. 異なるアドレスが返ってきた場合、その経路にプロキシが存在します。 同じアドレスが返ってきた場合は、設定が適用されていません。-v を追加し、curl が実際にどのサーバーに接続したかを確認してください。
プロキシの実際の場所を確認するにはどうすればよいですか？
http://ip-api.com/json や https://ipinfo.io/json などの位置情報エンドポイントに、プロキシ経由でリクエストを送信してください。位置情報データベースによって結果が異なるため、2つ確認することをお勧めします。 結果に矛盾がある場合は、対象サイトの判断が唯一の基準となります。実際のサイトを読み込み、どの地域のコンテンツが表示されるかを確認してください。
プロキシから自分の IP アドレスが漏洩しているかどうかを確認するにはどうすればよいですか？
プロキシ経由で https://httpbin.org/headers にリクエストを送信し、X-Forwarded-For、Via、X-Real-IP、または Forwarded に自分の実際のアドレスが含まれていないか確認してください。ヘッダーにアドレスを転送してしまうプロキシは、何も隠蔽できていません。
プロキシ利用時のDNSリークとは？
トラフィックはプロキシを経由しますが、ホスト名の解決は自身のマシンで行われるため、自身のリゾルバーがアクセスしたすべてのサイトを把握してしまいます。curlとSOCKSを使用する場合は、socks5:// ではなく socks5h:// を使用することで、プロキシがホスト名を解決するようになります。また、これにより地域的に不適切なサーバーに接続されてしまう可能性もあります。
複数のプロキシを一度にテストするには？
短い並行処理スクリプトを作成します。スレッドプールを使用し、プロキシごとに1リクエストを送信し、各リクエストにタイムアウトを設定し、例外をキャッチして、1つの不良エントリで実行が停止しないようにします。タイムアウトはよく省略されがちですが、これがなければ、1つの応答のないプロキシだけでテスト全体がハングしてしまいます。
プロキシの成功率として適切な数値は？
対象サイトにおいて、おおむね95%以上であれば良好と言えます。80%を下回ると、再試行が帯域幅を圧迫し始め、結果1件あたりの実質コストが急速に上昇します。この数値は対象サイトごとに異なるため、あるサイトで測定された成功率は別のサイトについては何の意味も持ちません。
オンラインのプロキシチェッカーを使うべきか？
未知の無料プロキシを初期選別する場合は、使うべきです。有料プロキシの場合は、使うべきではありません。動作する認証情報をサードパーティのサイトに貼り付けると、見知らぬ第三者に、あなたのアカウントで課金されるアクセス権を与えてしまうことになります。代わりに、独自のコマンドを使用してください。
プロキシはどのくらいの頻度でテストすべきですか？
本番環境にあるものについては、単発のテストではなく、ヘルスチェックとして継続的に実施してください。プロキシプールはローテーションされ、IPアドレスは再割り当てされ、レピュテーションも変化します。テスト結果は、その瞬間の事実であり、サービスの恒久的な特性ではありません。
まとめ
4つのテストがありますが、その重要度は均等ではありません。
接続性は1つのコマンドで実行でき、必要不可欠ですが、それだけではほとんど意味がありません。位置情報は、現実的かつ混乱を招くような障害を検出しますが、データベースによって結果が異なり、最終的にはターゲット側の判断のみが決定権を持つという点に注意が必要です。 情報漏洩チェック（ヘッダーとDNS）はそれぞれ1分程度かかり、正しく接続できているプロキシが実際には何の役にも立っていないことを明らかにする可能性があります。
実際のターゲットに対する成功率こそが重要な指標ですが、本番環境に投入する前にこれを確認する人はほとんどいません。 実際のURLを50個選び、それらをテストし、HTTP 200ステータスコードではなく、期待されるコンテンツの有無を確認して成功数をカウントしてください。なぜなら、チャレンジページ、ソフトブロック、空の結果はすべて200を返すため、ステータスコードだけを信頼する成功カウンターは、何も収集できていないにもかかわらず、素晴らしい数値を報告してしまうからです。
次に、帯域幅を成功数で割って、成功したリクエスト1件あたりのコストを算出します。失敗したリクエストも成功したものと同様に有料の帯域幅を消費するため、ギガバイトあたりのコストが最も安いプロバイダーが、結果あたりのコストで最も安いとは限らないのです。
実用上の注意点として、テストスクリプト内のすべてのリクエストにタイムアウトを設定してください。そうしないと、1つのプロキシが応答しなくなっただけで実行が停止してしまいます。 平均値ではなく95パーセンタイルを測定してください。大規模な環境では、この値がワーカーを埋める要因となるからです。まず成功率で順位付けし、実際に機能する選択肢の間でのみ速度を比較してください。また、有料プロキシの認証情報をサードパーティのチェッカーサイトに貼り付けないでください。
当社はプロキシを販売しており、単に安さだけで購入するよりも、当社のプロキシを適切にテストしていただきたいと考えています。購入を決定する前にこの手順を踏むお客様こそが、長期的に利用し続けてくださるお客様です。なぜなら、単に接続できるだけのものよりも、確実に機能することが実証されたものを購入しているからです。
