プロキシ接続に失敗したら、プロキシサービス、認証とプロトコル、クライアント設定、対象サイトの順に確認します。各段階の判断材料を使い、設定を変える前にどの層で問題が起きているかを特定します。
プロキシを入力したあと、テストボタンで失敗が表示されることがあります。このとき最も避けたいのは、原因を切り分けずにポート、プロトコル、ノードを次々と変更し、最終的に何が効いたのか分からなくなることです。
原因は大きく4つの層に分かれます。プロキシサービス自体、認証とプロトコル、クライアント設定、対象サイトです。プロキシ側から外側へ、この順番で確認します。
まずプロキシ単体でテストする
最初から業務ツール内で確認しないでください。手動でプロキシを設定できる通常のブラウザー、またはOSのプロキシ設定にそのプロキシを入れ、インターネットへ接続できるかを確認します。この手順により、プロキシと業務環境を分離して確認できます。
この環境でも接続できない場合、問題はプロキシ自体にあります。期限切れ、無効化、出口ノードの障害、またはプロバイダー側のアクセス制限などが考えられます。その場合は後続の手順を続ける必要はなく、プロキシプロバイダーに状態と利用状況を確認します。
ここで接続できるなら、プロキシ自体は生きています。問題は設定か通信経路にあるため、次へ進みます。
判断基準は簡単です。同じ認証情報が別の場所で使えるなら、認証情報そのものに問題がある可能性は低いと考えられます。
認証とプロトコルを一致させる
認証情報が正しいのに接続できない場合、次に疑うべきはプロトコルです。よくある不一致は3種類あります。プロバイダーから提供されたのはSOCKS5なのに環境ではHTTPを選んでいる、自前のSSHトンネルをSOCKS5として設定している、または1つのプロキシが複数プロトコルに対応しているものの、プロトコルごとにポートが異なり、別プロトコル用のポートを入力しているケースです。
エラーメッセージを判断材料にします。認証失敗や認証情報エラーなら、ユーザー名とパスワードを確認します。コピー＆ペーストで混入した空白や改行、ユーザー名内の特殊文字に必要なエスケープ処理にも注意してください。プロトコルエラーやハンドシェイク失敗なら、プロトコル種別とポートを確認します。
ユーザー名やパスワードは、一度手入力して比較することをおすすめします。見えない文字が原因の失敗は、目視では見つけられません。
クライアント設定が本当に反映されているか確認する
ここでは、もう少し見えにくい問題を確認します。設定値は正しいとして、その設定は実際に有効になっているでしょうか。
よくあるのは2つです。1つ目は設定自体が適用されていないケースです。変更を保存していない、別の環境を編集した、または前のセッションがまだ動いていることがあります。2つ目は設定は適用されたものの、別の設定に上書きされているケースです。環境内に別のネットワークスイッチがある、拡張機能がプロキシを制御している、またはOSレベルのプロキシ設定の優先度が高いことがあります。
判断には出口アドレスを使います。接続後に現在の出口アドレスを表示するページへアクセスし、ローカルアドレスではなくプロキシのアドレスが表示されることを確認します。ローカルアドレスのままなら、テストボタンが成功を示していても、実際のリクエストはプロキシを通っていません。
比較方法は単純です。同じ環境でプロキシを一度オンにし、次にオフにして、出口アドレスが変化するか確認します。変わらなければ、問題はクライアント側にあります。複数の環境を同時に動かしている場合は、それぞれの出口を個別に確認します。PurpleMarkのようにアカウント単位で環境を分離するツールがプロキシの割り当て時に重視しているのもこの点です。
対象サイト側の拒否パターンを見分ける
各層の接続に問題がなく、プロキシも確実に有効なのに業務ページが開けない場合は、プロキシをさらに変更するのではなく、対象サイトの反応を確認します。
この種の問題には比較的分かりやすい特徴があります。接続とハンドシェイクは完了するのにリクエストが403を返す、またはリセットされる。ページは開くがログインや投稿などの操作が拒否される。同じ出口で他のサイトは正常なのに、そのサイトだけ失敗する。あるいは断続的に失敗し、出口や通信経路のレート制限、同時接続数の制限が疑われるケースです。
重要なのは、接続層と業務層を分けることです。そもそも接続できないなら、プロキシ側の問題である可能性が高くなります。接続できるのに拒否されるなら、出口品質やアクセス頻度が原因であることが多いです。データセンターIPや大量に使い回された共有IPは、業務層でブロックされやすくなります。住宅IPは比較的通りやすい場合がありますが、万能ではありません。リクエスト頻度、同時実行数、アクセス時間帯も結果に影響します。
トラブルシューティングで守る3つの習慣
一度に変えるのは1項目だけにします。プロトコルとノードを同時に変えると、たとえ接続できても何が原因だったのか分からず、次回また同じ問題に直面します。
先に記録し、そのあと調整します。正常に使える設定について、アドレス、ポート、プロトコル、認証方式を記録しておきます。次回問題が起きたとき、ゼロから確認するより直接比較するほうがはるかに速くなります。
繰り返し再試行するより比較テストを優先します。設定に問題がないように見えるのに接続できない場合、テストボタンを何度押しても新しい情報は増えません。別のネットワーク環境や別のプロキシに切り替え、対照テストを行うほうが有効です。
