プロキシが機能しているかどうかを確認する方法（および動作しなくなる理由）

昨日まで機能していたプロキシが、今日には完全に使えなくなっているということはよくあります。これは、無料で一般公開されているプロキシサーバーの性質そのものです。作業の途中でそれに気づくよりも、プロキシが動かなくなる理由、稼働時間や応答時間の数値が実際に何を意味しているのか、そして依存する前にプロキシが実際に生きているかを確認する方法を理解しておく価値があります。この記事では、その3点すべてについて解説します。

プロキシが動かなくなる理由

無料プロキシは通常、サービス契約のない共有、管理されていない、または流用されたインフラストラクチャ上で動作しているため、動作しているプロキシが死んでしまう一般的な理由はいくつかあります。

• サーバーがオフラインになる。 運営者がサーバーを停止させたり、クラッシュしたり、ホスティングの期限が切れたりします。
• 過負荷になる。 無料プロキシで見つけた全員が共有しているため、同時ユーザーが多すぎるとタイムアウトしたり、新しい接続を拒否したりします。
• 再割り当てまたは再設定される。 IPがまったく別の用途に流用され、プロキシとして機能していたポートが閉じられる場合があります。
• 自動チェックのブロックを開始する。 一部のプロキシは、ボットやスキャナーのように見えるトラフィックを拒否するように設定されており、チェッカーから見ると正常に動作しているプロキシが死んでいるように見えることがあります。
• 宛先サイトがそれを個別ブロックし始める。 異常なトラフィックを検知して特定のウェブサイトがIPをブラックリストに登録した一方で、プロキシ自体には一般的にアクセスできるという状態になり得ます。

だからといって無料プロキシが全体的に信頼できないわけではありません。個々のプロキシの寿命が短く予測不可能であるためであり、まさにこのサイトのリストが静的なスナップショットを表示するのではなく15分ごとに更新される理由です。

プロキシが機能していない兆候

専用のチェッカーを使う前に、いくつかの症状を自分で認識する価値があります。

• プロキシを経由したページのタイムアウト、または読み込みが完了しない。
• タイムアウトではなく、接続が即座に拒否される。
• 応答が返ってきたが、プロキシを経由したようには全く見えない（実際のIPが露出している）。
• 断続的に動作する（つながったりつながらなかったりする）。これは通常、完全に死んでいるのではなく過負荷なサーバーを示しています。
• 通常のエブリデイブラウジングと比較してリクエストは成功するが異常に遅く戻ってくるため、他のユーザーからの高負荷下にあることが示唆されます。

稼働時間と応答時間が実際に測定するもの

このサイトのプロキシリストでは、すべてのエントリに信頼する前に理解しておく価値のある2つのライブメトリクスが表示されます。稼働時間 (Uptime) は、そのプロキシが正常に応答した最近のチェックの割合です。90%のプロキシは最近信頼性が高かったことを意味し、20%のプロキシは成功よりもはるかに頻繁に失敗しています。応答時間 (Response time) は、最も最近の成功した接続にかかった時間（ミリ秒単位）であり、低い方が高速です。リストのデフォルトの「最速応答」ソートは、最も低い応答時間を純粋に追い求めているわけではありません。稼働時間の健全なプロキシ（緑またはアンバー）を信頼性の低いものの前にグループ化し、そのグループ内で速度順にソートします。半分失敗するような超高速のプロキシは実際には良い選択ではないためです。

プロキシを手動で確認する方法

最も簡単な手動テストは、ブラウザでプロキシを設定し（PCとモバイルでのプロキシの設定方法を参照）、IPルックアップサイトにアクセスすることです。表示される場所とIPがご自身の接続ではなくプロキシのものと一致していれば、機能しています。これは1つのプロキシを確認するには適していますが、テストする対象が1つや2つ以上ある場合には遅く完全に手動であり、候補を比較するための応答時間の数値は得られません。

プロキシチェッカーで一括してプロキシを確認する方法

単一のプロキシを超えるすべてのケースにおいて、専用のチェッカーは劇的に高速です。このサイトのプロキシチェッカーツールを使用すると、リスト全体を一度に貼り付けることができ（1バッチあたり最大30件）、リストが使用するプロトコルと形式を選択して、並行してすべてに接続し、通常わずか数秒で完了します。インストールやアカウントは不要で、送信した内容は後で保存されることもありません。

使用方法：プロキシを貼り付け（1行に1つ）、HTTP、HTTPS、SOCKS4、SOCKS5のいずれであるかを選択し、リストに一致する形式（通常のhost:port、またはhost:port:username:passwordなどの資格情報を含む形式のいずれか）を選択して、プロキシの確認をクリックします。Pingやポートオープンチェックだけでなく、ライブエンドポイントへの実際の接続でそれぞれがテストされます。これは、プロキシのポートが技術的には開いていても、プロキシ自体が誤設定されていたり実際にトラフィックを転送するのを拒否している場合があるため重要です。

結果の理解

チェックされた各プロキシは、2つの状態のいずれかとして返されます。

• 生存 (Alive): チェッカーはそれを通じて実際のりクエストを正常に完了しました。表示されるIP、国、および都市は、リストが主張するものだけでなく、その応答から直接読み取られます。これはプロキシの実際の現在の出口ポイントです。
• 死亡 (Dead): 接続が失敗したか、タイムアウトしたか、使用可能な応答を返しませんでした。これは必ずしもプロキシが永遠になくなったことを意味するわけではなく（一時的に過負荷になっている可能性があります）、現時点では信頼すべきではないことを意味します。

また、チェッカーは生きているすべてのプロキシについてミリ秒単位の応答時間を報告します。これにより、実際に使用できるものがわかれば、バッチを速度で素直にソートする簡単な方法としても機能します。期待していたプロキシが死亡して返された場合でも、完全に諦める前に1分か2分待ってからもう一度試してみる価値があります。一時的に過負荷になったサーバーは回復できますが、本当にオフラインのサーバーは回復しません。

リピートチェックの自動化

プロキシの同じローテーションを定期的に操作する場合、ブラウザで1つずつ確認するのはすぐに面倒になります。また、Webベースのプロキシチェッカーでも毎回手動でのアクセスが必要です。スケジュールに従ってプロキシを検証する必要があるワークフロー（たとえば、各スクレイピング実行の前に）の場合、基盤となる同じアイデアがプログラムで適用されます。短いタイムアウトで既知のエンドポイントに各プロキシを介して実際のリクエストを送信し、成功した応答を「生存」とし、タイムアウトまたはエラーを「死亡」として扱います。ほとんどのHTTPクライアントライブラリ（自動化に使用する言語に関係なく）は、プロキシを介したリクエストのルーティングを直接サポートしているため、バッチをチェックし応答したものだけを保持する小さなスクリプトを構築することが簡単になります。これは、プロキシチェッカーツールが実行するのと同じ正確なロジックであり、ブラウザではなく独自のパイプラインに配線されているだけです。

よくある質問への簡単な回答

まだ閲覧できるのに、プロキシが死亡しているとチェッカーが言うのはなぜですか？

これは通常、プロキシが断続的に過負荷になっていることを意味します。一部のリクエストは処理できるがチェッカーが送信した特定のリクエストを処理できない、またはチェッカーのより厳しい制限時間でタイムアウトしている状態です。少し待ってからもう一度お試しください。

プロキシが「生存」していても安全に使用できない場合がありますか？

はい。「生存」は現在トラフィックを正常に転送していることを確認しているだけであり、誰が運営しているかやどれほど信頼できるかを確認しているわけではありません。ステータスに関係なくすべての無料プロキシを未検証として扱い、そのいずれかを介した機密性の高いログインや支払いは避けてください。

高速な応答時間は、優れたプロキシを保証しますか？

それ単体ではありません。プロキシは高速であっても信頼性が低い（稼働率が低い）場合や、ニーズに対して地理的に間違っている場合があります。応答時間を稼働時間や場所と一緒に確認し、孤立して確認しないでください。

定期的に使用するプロキシはどのくらいの頻度で再確認する必要がありますか？

無料プロキシがいかに速くステータスを変更できるかを考慮すると、使用の直前が最も安全です。同じものを繰り返し信頼している場合は、少なくとも毎日再確認してください。

死亡したプロキシは後で試してみる価値がありますか？

多くの場合、はい。一時的な過負荷のためにチェックに失敗したプロキシは数分または数時間以内に回復する可能性があるため、単一の失敗したチェックの後に完全に破棄するのではなく、自分にとって重要だったものを再テストするのは合理的です。特定のプロキシが長期間利用可能であることに依存するワークフローを構築しないでください。

チェッカーはプロキシ自体の速度を落としたり影響を与えたりしますか？

いいえ。チェックは単一の軽量なリクエストであり、プロキシを介して1つの小さなページを読み込むことに匹敵します。他の簡潔で通常の使用よりもプロキシに影響を与えることはありません。

信頼性のためのベストプラクティス

1. 1回だけでなく、セッションごとに再確認してください。 プロキシのステータスは数分以内に変わる可能性があるため、「先ほど機能していた」という保証はありません。
2. 使用予定の同じバッチでテストします。 タスクに複数のプロキシをローテーションさせる場合は、古いチェックに依存するのではなく、開始する直前にすべてを一緒に確認してください。
3. 必要な数よりも多くの候補を保持します。 タスクに3つの動作するプロキシが必要な場合は、6〜8個を確認してください。無料のリストからであるため、一部は必然的に死亡します。
4. リストの形式に正確に一致させます。 解析の不一致（間違った形式の選択）は、プロキシが本質的に問題ない場合でもすべてが無効であると表示されます。リストの構造と形式のドロップダウンが一致していることを再確認してください。
5. 単一のチェックを過度に信頼しないでください。 通過したばかりのプロキシでも、特にその使用法がクイック検証リクエストよりも重い場合、実際の使用時に数分後に失敗することがあります。「生存」を永続的な保証としてではなく、「現在アクセス可能である」として扱ってください。

無料プロキシは性質上動く的ですが、依存する前に確認することは数秒しかかからず、最初から機能するはずのない接続をデバッグするはるかに大きな時間のコストを節約できます。