公開リストには、すでに接続を受け付けなくなったエンドポイントが含まれることがあります。これはプロキシが失敗するよくある理由ですが、唯一の理由ではありません。プロトコルの間違い、迂回設定、ポートの遮断、出口 IP に対するサイトの拒否でも同じ症状が起こります。

アプリを変更する前に登録情報を確認する

IP、ポート、プロトコルをもう一度コピーしてください。ポート番号の数字が一つ欠けたり、HTTP と SOCKS を取り違えたりするだけで、ハンドシェイクは失敗します。8080 や 1080 というポート番号からプロトコルを推測せず、サービスが実際にユーザー名を提供していない限り追加しないでください。

HTTP のエンドポイントなら、短い curl リクエストで、ブラウザー拡張機能やシステム設定からテストを切り離せます。

curl --proxy http://203.0.113.10:8080 --noproxy '' --connect-timeout 5 --max-time 15 --verbose https://example.com/

文書用のアドレスを実際の登録情報に置き換えてください。SOCKS5 なら実際のポートと対応する SOCKS スキームを使います。

最初に失敗した箇所を見る

結果調べるべき箇所の候補
接続拒否ポートが閉じているか、機器が能動的に接続を拒否しました。
接続タイムアウト経路、フィルタリング、サービスの問題で制限時間内に接続を確立できませんでした。
想定外のプロキシハンドシェイク応答選択したプロトコルがサービスと一致していない可能性があります。
407プロキシが認証を要求しています。
CONNECT が拒否されたプロキシがその接続先やポートを制限している可能性があります。
サイトが 403 または 429 を返すリクエストは HTTP サーバーに到達しましたが、拒否または制限されました。どのサーバーが応答したのか確認してください。

TCP 接続の成功は最初の段階にすぎません。そのポートのサービスが選択したプロキシプロトコルでなければ、リクエストは直後に失敗することがあります。

二つの比較を行う

同じプロトコルの別のプロキシで同じ接続先を試してください。最初のエンドポイントだけが接続確立時に失敗するなら、問題をそのエンドポイントか経路に絞れます。次に、最初のプロキシで別の一般的な接続先を試します。一つのサイトだけが失敗するなら、プロキシ全体が使えないと判断する前に、その接続先固有のポリシーを調べてください。

直接アクセスが可能なら、直接リクエストする比較も役立ちます。継承したプロキシ変数により、直接接続のつもりのテストが密かにプロキシ経由にならないよう、迂回を明示してください。

その登録情報のテストを打ち切る時点

時間を制限した複数のリクエストが同じ接続段階で失敗するなら、待ち時間を数分に延ばすのではなく、無料プロキシ一覧から別の候補を選びます。報告が必要なら正確なエラーを保存してください。再接続を繰り返しても、閉じたポートや削除されたエンドポイントは直りません。

すべての候補が失敗するなら、いったん視野を広げましょう。クライアント設定、ネットワークの送信規則、プロキシなしで接続先に到達できるかを確認します。全リクエストに共通する問題を理由に、リスト全体を捨てるのは適切ではありません。

関連記事