Clashは接続済みだがWebページが開かない:システムプロキシ・DNS・ルールの点検チェックリスト

第1段階:システムプロキシが本当に有効になっているか確認する

クライアントの画面に「接続済み」と表示されているのは、あくまでクライアントとノードの間にプロキシトンネルが確立されたことを示すだけで、システムの通信がそのトンネルへ実際に流れているかどうかとは別問題です。ここは最も見落とされやすい層であり、点検の出発点になります。

1. システムのネットワーク設定を開き、プロキシ設定項目を確認します(Windowsは「設定 → ネットワークとインターネット → プロキシ」、macOSは「システム設定 → ネットワーク → 詳細 → プロキシ」)。アドレスとポートがクライアントがローカルで待ち受けているポート(通常は127.0.0.1:7890のようなミックスポート)を指しているか確認してください。
2. クライアントでシステムプロキシの自動設定機能をオンにしている場合、この項目はクライアントが自動で書き込んだ状態になっているはずです。一度手動でオフにしてからクライアント側で再度オンにし、設定が正しく上書きされるか確認してください。
3. TUNモード(仮想ネットワークアダプタで全体の通信を横取りする方式)を使っている場合はシステムプロキシ設定に依存しないため、代わりにネットワークアダプタの一覧にクライアントが作成した仮想アダプタが存在し、有効な状態になっているかを確認します。

システムプロキシの項目が空欄だったり、ポートが一致しなかったり、TUNモードで対応する仮想アダプタが見つからない場合は、通信がそもそもクライアントに入っていないということです。この時点で以降の点検はすべて無意味になるため、まずこの層を解決してください。

第2段階:ノードの疎通——プロキシスイッチの先にある最初の壁

システムプロキシが有効になっていることを確認したら、次は「トンネルは張れているが、ノード自体が外に出られない」状態を排除します。クライアント上の「接続済み」表示は基本的にハンドシェイクの成功のみを示すもので、そのノードが現時点で正常に通信を転送できているかは保証しません。

• クライアントのノード一覧で、現在使用中のノードに対して遅延テストを実行します。タイムアウトや異常に高い遅延が表示された場合は、まず同じサブスクリプション内の別の利用可能なノードに切り替えてください。
• クライアント標準搭載のログパネルを開き、接続拒否やハンドシェイク失敗といった記録がないか確認します。この種のログはローカル側の設定ミスではなく、ノード側の問題を直接示している場合が多いです。
• すべてのノードでテストに失敗する場合は、サブスクリプションのサーバー側に異常が起きているか、ローカル環境から出口プロトコルへ向かうポートがブロックされている可能性が高く、これは別種の問題として、当サイト内のノードが全て応答しない場合の点検手順を参考に個別に対処してください。

第3段階:DNS解決——ドメイン名が正しいアドレスに変換されているか

プロキシの経路が通り、ノードも疎通しているのにWebページが読み込み中のまま——この場合、高確率でドメイン名の解決段階に問題があります。DNSリクエストがプロキシを経由していない、またはローカルに誤った結果がキャッシュされている場合、ブラウザは永遠に返ってこない接続を待ち続けることになります。

1. クライアント設定のDNS項目を確認し、fake-ipやクライアント内蔵のリモートDNS転送が有効になっているか、それとも端末本来のDNSサーバーをそのまま使い続けていないかを確認してください。
2. システムのコマンドラインで、プロキシ経由でないとアクセスできないドメインを対象に名前解決テストを実行します。国内(日本国内)の通信キャリアDNSでよく見られるエラーアドレスやタイムアウトが返る場合は、解決リクエストがプロキシに引き取られていないことを示します。
3. クライアントが規則内でDNS振り分けを個別設定できる場合、DNSクエリが誤って「直接接続」ポリシーグループに割り振られていないか確認してください。この設定ではプロキシ経路自体は正常でも、ドメイン解決が常に失敗する状態になります。
4. 端末のDNSキャッシュをクリアし(Windowsではipconfig /flushdns、macOSではsudo killall -HUP mDNSResponderを実行)、対象サイトに再度アクセスしてみてください。

DNS層の問題は「一部のサイトは開けるが、一部は開けない」という形で現れやすく、同じサイトでも時間帯によって挙動が変わることがあります。こうした現象が見られる場合は、ノード自体よりも解決処理の方をまず疑ってください。

第4段階:ルールの一致——つながっているはずなのに開かない理由

ClashおよびClash Meta(mihomo)コアは、各接続がどのポリシーグループを経由するかをルール(rules)によって決定します。目的のサイトが誤って「直接接続」や失効済みのポリシーグループに割り振られていれば、プロキシ自体が完全に正常でもそのサイトは開けません。

• クライアントの接続パネルまたはログを開き、目的のサイトへのリクエストが実際にどのルールに一致し、どのポリシーグループに割り振られているかを確認してください。ポリシーグループが「接続済み」と表示されているだけで判断しないようにします。
• 一致したポリシーグループで現在選択中の出口ノード自体が使用不可の場合、ルールの一致自体は正しくても接続は失敗します。そのポリシーグループ内のノード状態を個別に確認する必要があります。
• カスタムルールセットが多く、ルールの順序が乱れている場合、前方の広い範囲を対象とするルールが先に一致してしまい、後方の精密なルールが効かなくなることがあります。一時的にカスタムルールをすべて削除してサブスクリプションのデフォルト設定に戻し、再テストして問題が解消するか確認することをおすすめします。
• TUNモードを使用している場合は、システムの重要プロセスやブラウザプロセスを横取り対象から除外するルールが存在しないかも確認してください。この種の除外ルールがあると、ブラウザのリクエストがプロキシを完全に迂回してしまいます。

第5段階:ブラウザとローカルキャッシュの最終チェック

前の4段階すべてで問題なしと確認できても、個別のWebページだけ開かない場合は、プロキシ経路ではなくブラウザ自身がキャッシュした古い接続や古い証明書情報が原因になっていることが多いです。

1. ブラウザのプライベート/シークレットウィンドウで目的のサイトを開き直し、ブラウザ拡張機能とローカルキャッシュによる影響を排除してください。
2. ブラウザが証明書エラーや接続のリセットを表示する場合は、システム時刻が正確かどうかを確認してください。時刻のずれが大きいとTLSハンドシェイクの検証に失敗し、見た目上はプロキシの問題に似た挙動になります。
3. 一部のブラウザは同一ドメインに対して長時間接続プールを保持し続けます。ノードやポリシーグループを切り替えた後も古い接続が解放されないことがあり、ブラウザのプロセスを再起動することで通常この種の残留問題は解消します。

以上5段階を近い層から遠い層へ順に切り分けていけば、「接続済みなのにWebページが開かない」状況の大半は10分以内に具体的な切断点を特定できます。点検の結果クライアント自体のバージョンに互換性の問題があると判明した場合は、最新版へ更新して再テストすることを検討してください。