2026-06-15 トラブル対応 読了目安 8分

Clash 接続済みなのにサイトが開けない:システムプロキシからDNSまでの点検リスト

プロキシは接続済みでもネットに繋がらない時の点検順:システムプロキシの反映、ポート競合、ノードの有効性、DNS汚染、ルール誤マッチを検証コマンド付きで解説。

クライアントの画面には「接続済み」と表示され、ステータスランプも緑色、ノードの遅延数値も正常なのに、ブラウザでどのページを開いてもぐるぐる回るかエラーになる——これはClash利用中に最も頻繁に遭遇するトラブルの一つで、原因はノード自体ではなく、システムからクライアント、そして出口までのどこかの経路にあることが多い。以下は発生頻度が高い順に並べた5つの点検ポイントで、それぞれすぐ実行できる検証コマンドを付けている。当てずっぽうで確認する必要はない。

ステップ1:システムプロキシが実際に反映されているか確認する

クライアントが「接続済み」と表示するのは、コア処理が動いていてリスニングポートが開いていることを示すだけで、システムのトラフィックが実際にそのポートを通っているとは限らない。多くの場合、ユーザーはClash自体の「システムプロキシとして設定」スイッチをオンにしているが、システム側のプロキシ設定が他のソフトに上書きされていたり、ブラウザが独自のプロキシ設定を使っていたりして、トラフィックがそもそもClashに入っていないことがある。

  • Windows:「設定 → ネットワークとインターネット → プロキシ」を開き、「セットアップスクリプトを使う」または「プロキシを手動で設定」内のアドレスとポートがクライアント側の表示と一致しているか確認する。
  • macOS:「システム設定 → ネットワーク → 詳細 → プロキシ」を開き、「Webプロキシ(HTTP)」と「セキュリティWebプロキシ(HTTPS)」が127.0.0.1とクライアントのポートを指しているか確認する。
  • ブラウザ側で個別にプロキシ拡張(SwitchyOmegaなど)を設定している場合、システムプロキシをどう変えてもそのブラウザには影響しないため、拡張機能内の設定も合わせて確認する必要がある。

TUNモードを使用している場合、このステップは無視して構わない——TUNはネットワークカード層で全トラフィックを引き受けるため、HTTP/SOCKSプロキシ設定には依存しないが、TUNがクライアント上で実際に有効化されているか(設定ファイルには書いてあるが有効化されていない、という状態ではないか)を確認する必要がある。

ステップ2:ポートの競合・占有を確認する

Clashはデフォルトで7890(HTTP/SOCKS混合ポート)と9090(外部コントロールポート)をリスニングしている。同じ端末上で他のプロキシソフト、仮想マシンのネットワークコンポーネント、または前回正常終了しなかったClashプロセスが動いている場合、ポートが占有されてしまい、クライアントの表示上は正常に動いているように見えても、実際のリスニングには失敗していることがある。

Windows PowerShell
netstat -ano | findstr 7890
macOS / Linux
lsof -i :7890

ポートがClash以外のプロセスに占有されていることが分かった場合は、まずそのプロセスを終了させるか、Clashのリスニングポートを別の値(7891など)に変更してからクライアントを再起動する。同時にタスクマネージャー/アクティビティモニタに複数のclash / mihomoバックグラウンドプロセスが残っていないかも確認しておく。重複したプロセス同士が干渉し合うことがある。

ステップ3:ノード自体が利用可能か検証する

ノードの遅延が数十ミリ秒と測定されても、そのノードが本当に目的のサイトに接続できることを保証するものではない——速度テストツールは通常、着地サーバーとのTCPハンドシェイクしか測っておらず、出口IPが目的サイトからブロックされていないことや、そのノードの出力帯域がまだ残っていることを保証しない。切り分け方法は次の通り。

  1. クライアントのノード一覧で別の地域・別のプロトコルのノードに切り替え、同じURLに再度アクセスして、問題が現在のノードに限って発生しているかを判断する。
  2. クライアントの接続ログまたはトラフィックパネルを開き、今のアクセスが本当に選択中のノードを経由しているか、それともあるルールによって「DIRECT」直結に振り分けられていないかを観察する。
  3. コマンドラインで出力接続性を直接テストし、ブラウザのキャッシュやDNSキャッシュといった干渉要因を排除する。
ターミナルテスト(プロキシ経由のリクエスト)
curl -x http://127.0.0.1:7890 -I https://www.google.com --max-time 8

このコマンドがHTTP/2 200や同様の正常なステータスコードを返す場合、プロキシ経路自体には問題がないことが分かる。ブラウザでページが開けないのはブラウザ自身のキャッシュ、拡張機能、あるいはHTTP/3プロトコルとの互換性の問題かもしれないので、シークレットウィンドウを試すか別のブラウザで確認してみるとよい。

ステップ4:DNSが汚染・ハイジャックされていないか確認する

プロキシ経路は正常なのに特定のサイトだけ開けない、あるいは接続できても間違った内容が表示される場合、大抵はDNSの部分に問題がある。システムのデフォルトDNSでドメインを解決すると汚染された誤ったIPを取得してしまうことが多く、トラフィック自体はClashに渡されていても、ドメイン解決の段階でプロキシ内蔵のDNSモジュールを通っていなければ、後続のリクエストは依然として誤ったアドレスに接続してしまう。

設定ファイルでdnsモジュールを有効にし、fake-ipまたはenhanced-mode: fake-ipを使うことを推奨する。同時にnameserverを信頼できる暗号化DNS(DoH/DoTアドレスなど)に向けることで、ドメイン解決もプロキシの判定を経由させ、端末側のシステムDNSに依存しないようにする。

config.yaml の抜粋
dns:
  enable: true
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - https://doh.example-provider.com/dns-query
  fallback:
    - tls://1.1.1.1:853

DNSが正常に解決されているかを検証するには、コマンドラインでプロキシ経由前後の解決結果を直接比較すればよい。

ターミナルテスト(DNS比較)
nslookup www.example.com
nslookup www.example.com 198.18.0.2

2回の結果で返ってくるIPが明らかに異なる場合や、どちらか一方がタイムアウトする場合は、端末のデフォルトDNSとプロキシ内蔵DNSの間に不一致があることを示している。プロキシ内蔵DNSの解決結果を優先させ、システムのネットワーク設定で通信事業者のDNSが強制指定されてプロキシ設定を上書きしていないかも確認する。

ステップ5:ルールでトラフィックが誤って振り分けられていないか確認する

Clashの中心的な動作方式は、各接続をルールに従って異なるポリシーグループへ振り分けることである。ルールセットの設定が適切でない場合、「プロキシは接続済みで一部のサイトは開けるが、一部だけ開けない」という状況が十分に起こり得る——問題のサイトがあるルールによって「直結すべき」と誤判定され、しかもローカルネットワークからはそのアドレスに直結できない、というケースだ。

  • クライアントのルール/ログパネルを開き、開けないURLにアクセスして、その接続が実際にどのルールにマッチし、どのポリシーグループに落ちているかを確認する。
  • DIRECTにルーティングされていて、プロキシノードではないと表示されている場合は、ルールセット(GeoSite、GeoIPの分類など)がそのドメインやIPレンジを誤って「本土ノード」や「直結」カテゴリに分類していないか確認する。
  • ルールセット自体が古いバージョンで、長期間更新されていないと新しく追加されたドメインセグメントが正しく収録されていないことがある。定期的に設定内のルールセット取得元を更新するか、メンテナンスが活発なルールリポジトリに乗り換えることを推奨する。

トラブルに遭遇したからといってmodeをruleからglobalに変えたまま長期間使い続けないこと——グローバルモードは問題がルール層にあるかを一時的に検証できるが、すべてのトラフィック(ローカルネットワークへのアクセスも含む)がプロキシの出口を経由してしまう。検証が終わったらルールモードに戻すべきである。

5つのステップを終えても解決しない場合

以上の順序で一つずつ点検すれば、「接続済みなのにネットに繋がらない」というほとんどのケースは具体的な箇所を特定できる。すべての確認が通り、トラフィック・DNS・ルールがいずれも正常なのにページが依然として開けない場合は、さらに次の2点を確認するとよい。ローカルのファイアウォールやセキュリティソフトがClashプロセスに対して個別のネットワーク制限を設定していないか、サブスクリプションのノードが一時的にオフラインになっていないか(サブスクリプションリンクを再インポートしてノード一覧を強制的に更新してみる)。多くの場合、まずクライアントプロセスを再起動してから上記の順序で再確認すれば、どこかのステップで問題が明らかになる。

Clash をダウンロード