プロキシ接続失敗の切り分け：出口・経路・アプリ層の順で確認

プロキシを設定し、ユーザー名とパスワードも正しいのに、チェックすると接続失敗と表示されることがあります。多くの人はそこでプロキシ事業者に連絡し、ノードを替えたり、ポートを変更したり、サポートを急かしたりします。しかし、失敗の原因は通信経路全体のどこにでもあり得て、プロキシはその一部にすぎないため、効率はあまり高くありません。

手当たり次第に試すのではなく、外側から内側へ固定した順序で確認します。まず出口が本当に有効になっているかを確認し、次に経路が通っているかを見て、その後でアプリケーション層の認証とプロトコルを確認します。この3層を順に見れば、多くの問題を特定できます。

出口は本当に有効になっているか

設定が成功しているように見えるため、この確認は飛ばされがちです。ただし、設定が成功したことと、実際の通信がプロキシを経由していることは別です。

確認するのは2点です。1つ目はIPが変わったかどうかです。プロキシを使わない状態のグローバルIPを記録し、プロキシを有効にしてもう一度確認します。同じIPなら、通信はプロキシから出ていないため、その先を調べても意味がありません。2つ目は所在地が正しいかです。プロキシの詳細には通常、国、地域、州・省、都市、小数点以下6桁の緯度・経度、郵便番号などが表示されます。購入時に指定した地域情報と照合してください。出口地域とシステムのタイムゾーンが明らかに合っていない場合も注意が必要です。

出口が有効にならない原因は、事業者側ではなく端末に残った設定にあることも多いです。以前使ったネットワークツールが終了時に正しく設定を消していないと、HTTP_PROXY や HTTPS_PROXY のような環境変数がシステムに残ったり、macOS のWebプロキシやSOCKSプロキシが有効なままになったりします。その場合、クライアントはシステムプロキシを使っているつもりでも、実際のリクエストは迂回していることがあります。こうした残存設定を消して再テストするほうが、プロキシを一から設定し直すより有効です。

経路層でよくある3種類のエラー

出口に問題がないことを確認したら、次にリクエストが実際に宛先まで届いているかを見ます。

最初の詰まりやすい点はDNS名前解決です。名前解決そのものに失敗する場合や、本来ターゲットサービスを指すはずのドメインが不自然なアドレスに解決される場合があります。公開DNSで再度解決するか、ローカルのDNSキャッシュを消して、復旧するか確認してください。

2つ目は接続タイムアウトです。ファイアウォールやセキュリティソフトにポートを遮断されると、読み込みが続いた後にタイムアウトします。ポートの許可ルールを確認し、企業ネットワークや公共Wi-Fiなど、その環境自体に制限がないかも見てください。簡単な判定方法は、プロキシを使わず直接接続することです。それでもどのWebサイトも開けないなら、問題は基礎ネットワーク側であり、プロキシではありません。ルーターを再起動するか、スマートフォンのテザリングに切り替えて確認できます。

証明書エラーは別に考える必要があります。「証明書が信頼されていない」「ハンドシェイクに失敗した」と表示されると、通信が復号されている、あるいは証明書が差し替えられていると考えがちです。確かにその可能性はありますが、もっと見落としやすい原因として端末の時刻ずれがあります。多くの認証やセッション機構はタイムスタンプに依存します。ローカル時刻とサーバー時刻の差が5分を超えると署名検証が失敗し、接続を拒否されることがあります。HTTPSでは証明書検証失敗として現れます。証明書エラーを見たら、システムの時刻同期も確認してください。異常なら自動同期を有効にしてすぐ補正し、クライアントを再起動してもう一度試します。

認証とプロトコルを取り違えない

プロキシサーバーには到達できるのに通信できない場合、問題は多くの場合アプリケーション層にあります。

最も多いのは認証情報です。プロキシのユーザー名、パスワード、認証方式は事業者から提供された内容と一致している必要があります。パスワードを変更したのに設定側を更新していないケースもよくあります。手動設定の場合は、入力したポート番号がプロキシツール自身の待受ポートと一致しているかも確認してください。数字が似ていても、間違ったポートではまったく接続できません。

2つ目はプロトコルの不一致です。HTTP、HTTPS、SOCKS5を混同してはいけません。事業者からSOCKS5が提供されているのに設定をHTTPにすると、チェックは必ず失敗します。また、プロキシが対象サイトと対象ポートへのアクセスを許可しているかも確認してください。プロキシによっては宛先やプロトコルを制限しています。

ノードの問題か設定の問題かを最も早く見分ける方法は、別のノードで試すことです。切り替えて使えるなら元のノードの問題です。切り替えても失敗するなら、設定と経路に戻って確認します。このとき複数のパラメータを何度も同時に変更せず、1回につき1つの変数だけを変えて結果を記録してください。そうしないと、自分の操作で原因が見えなくなります。

接続できても、その環境が使えるとは限らない

もう1つよくある落とし穴があります。プロキシは正常に接続しているのに、アカウントが頻繁にリスク判定を受ける場合です。問題は接続できるかどうかではなく、その出口が通常のユーザー環境らしく見えるかどうかにあることがあります。

確認項目は同じです。出口の所在地とアカウント登録地域が一致しているか、IPの種類が妥当か、そしてそのIPが対象サイトで過去にマークされていないかを確認します。プラットフォーム側ではデータセンターIPと住宅IPで信頼度が異なる場合があります。また、同じIPで過去に大量の異常行動が行われていると、後から使う人にも影響が及ぶことがあります。接続テストに通った後、出口のクリーンさも数分かけて確認してください。

1台の端末で複数の環境を動かすなら、出口は1対1にするのが理想です。各環境に専用の出口を割り当てれば、問題を個別に特定でき、ある出口がマークされても対応する環境だけに影響を限定できます。PurpleMarkのマルチ環境管理も、この考え方に基づいて環境ごとに出口を設定し、分離しています。

このトラブルシューティング方法は技術的な情報共有を目的としています。関連するツールやサービスは、適用される法令や規則を守って利用してください。