無料プロキシは、動作するよりも失敗することの方が多い。公開リストは数万もの候補を循環しており、あなたの仕事は、現在生きていて、十分に高速で、積極的に悪意のない小さなサブセットを見つけることです。5つのテストは、それぞれ低コストで、順番に実行されます。
テスト1: TCP到達可能性
curl --connect-timeout 5 --proxy http://1.2.3.4:8080 \
-s -o /dev/null -w "%{http_code}\n" \
https://api.ipify.org非ゼロの終了コードまたは空の応答は、プロキシが死んでいることを意味します。どの時点でも、任意の無料リストの約60～80%がこのテストに失敗します。すぐにスキップし、再試行しないでください。
テスト2: 出口IP検証
同じ呼び出しは、リクエストが発信されたパブリックIPを返します。それが1.2.3.4（プロキシのアドレス）と等しい場合、プロキシはトラフィックを正しく転送しています。ローカルIPと等しい場合、プロキシは壊れているか透過的です。接続を受け入れましたが、実際には自身を経由して中継していません。TCPが成功した場合でも、それを失敗として扱います。
テスト3: ヘッダーの透過性
curl --proxy http://1.2.3.4:8080 https://httpbin.org/headers応答は、宛先が受信したヘッダーをエコーバックします。実際のIPを含むX-Forwarded-For、Via、またはForwardedを探してください。それらが見つかった場合、プロキシはエリートモードではなく、透過的または匿名モードです。CONNECTを介したHTTPSの場合、これは意味がありません。宛先はTLSハンドシェイクのみを認識し、アプリケーションヘッダーは認識しません。しかし、平文HTTPの場合、プロキシが目的に適しているかどうかを判断します。
テスト4: 負荷時のレイテンシ
単発のタイミングはノイズが多い。プロキシを経由して10回のシリアルリクエストを実行し、中央値を取ります。2秒を超えるものはインタラクティブな作業には使用できません。500ミリ秒未満はプロキシなしと同等のパフォーマンスです。その間の数値では、プロキシはバッチスクレイピングには適していますが、ブラウジングには適していません。
テスト5: TLSフィンガープリントの整合性
プロキシを経由して既知のTLSエンドポイントに接続し、証明書チェーンがプロキシなしで取得したものと一致することを確認します。不一致は、プロキシがTLSをインターセプトしていることを意味します。中間者攻撃を実行しており、「暗号化された」トラフィックはプロキシ以降実際には暗号化されていません。これは適切に設定されたSOCKSプロキシではまれですが（TLSを認識できません）、誤設定された企業のHTTPSプロキシや、時折悪意のある公開ノードで発生します。openssl s_client -proxy 1.2.3.4:8080 -connect example.com:443がチェーンを出力します。
実用的なワークフロー
リストを取得し、国とプロトコルでフィルタリングし、5つのテストを約50ワーカーの並列プールに展開し、生き残ったものを保持します。100の生の候補から、典型的な実行では5～15の使用可能なエントリが得られます。減衰率はHTTPおよびHTTPSで約30～60分、SOCKSではやや長くなります。その周期でリフレッシュをスケジュールし、生き残ったセットをスクレイパーまたはブラウザ設定に供給します。テスト結果は1バッチの存続期間中キャッシュし、次のバッチで再テストします。