1. ホーム
  2. 技術ノート
  3. Clash が接続済みなのにネットに繋がらない:順を追って確認する9項目チェックリスト
2026-06-08 トラブル対応 読了目安 9分

Clash が接続済みなのにネットに繋がらない:順を追って確認する9項目チェックリスト

ノードのステータスは「接続済み」と表示されているのに、ブラウザで何も開けない——これはClashの利用中に最もよく起こり、かつ最も混乱を招くトラブルの一つです。本記事では「まずローカル、次にリモート」の順で、確認作業を9つの検証可能なチェックポイントに分割し、各項目に具体的な確認方法と対応する修正手順を示します。

「接続済み」は「ネットに繋がる」を意味しない

クライアント画面に表示される緑色のドットや「接続済み」の表示は、通常、Clashとプロキシサーバー間で一度ハンドシェイクテストが完了したこと、あるいは現在選択中のノードの遅延テストに応答があったことのみを示しています。このステータスと「ブラウザで正常にページが読み込めるか」はまったく別の話です——その間にはシステムプロキシが有効になっているか、DNS解決が正しく行われているか、ルールがトラフィックを誤った出口へ振り分けていないかなど、複数の工程が挟まっています。どこか一つの工程に問題があれば「接続済みなのにネットに繋がらない」という現象が起こり、これらの工程のエラー情報はメイン画面に直接表示されないことが多いため、一つずつ確認して特定する必要があります。

以下の9つのチェックポイントは「まずローカル設定を確認し、次にノード自体を検証し、最後にルールとリモート側を調べる」という順に並べています。順番に進めることを推奨します——多くの場合、問題は最初のステップにあるにもかかわらず、ノードの不具合と誤認されがちです。

チェックポイント1〜3:まずローカルとクライアント設定を確認

1. システムプロキシが本当に有効になっているか

これは最も見落とされがちなステップです。一部のクライアントでは設定ファイルの切り替えや再起動後、システムプロキシのスイッチがオフに戻ってしまうことがありますが、ノードの接続状態は正常のまま表示され、「接続しているように見えるが、実際にはトラフィックがプロキシを通っていない」という見せかけの状態になります。

  • 確認方法:システムのネットワーク設定パネルを開き、プロキシアドレスが 127.0.0.1 と対応するポート(通常7890前後)になっているか、空白やシステムデフォルトのままではないかを確認します。
  • 対処法:クライアントのメイン画面で「システムプロキシ」のスイッチを手動でオンにし、再度ネットワーク設定パネルを開いて反映されているか確認します。

2. プロキシモードの選択ミス

Clashには通常、ルールモード(Rule)、グローバルモード(Global)、直接接続モード(Direct)の3種類があります。誤って直接接続モードに設定されていると、すべてのトラフィックがプロキシを経由せず直接送信されるため、ノードのステータスは正常に表示されても、実際にはプロキシサーバーを一切通っていません。

  • 確認方法:クライアント設定画面のモード選択を確認し、現在選択中の項目が「直接接続」になっていないかチェックします。普段ルールモードを使っているにもかかわらずアクセスできないサイトが異常に多い場合は、一時的にグローバルモードに切り替えて比較テストを行うのも有効です。
  • 対処法:ルールモードまたはグローバルモードに切り戻し、問題がすぐに解消するかを観察します。
Notice / 注意

グローバルモードはすべてのトラフィック(本来直接接続すべき日本国内のサイトも含む)をプロキシに送り込むため、あくまで検証段階での比較テスト用途です。日常利用ではルールモードに戻すことを推奨します。不要な遅延や帯域消費を避けられます。

3. ローカルネットワーク接続とポートの競合

ルーターやその他の機器からClash実行中のホストへトラフィックを転送している場合は、「LAN接続を許可」オプションを追加で有効にする必要があります。また、プロキシポートが他の実行中のプログラムに占有されていないかも確認してください——例えば別のプロキシツールを同時に起動している場合、同じポートの奪い合いが起き、プロキシへのリクエストが静かに破棄されることがあります。

  • 確認方法:クライアント設定内の「LAN接続を許可」のオン/オフ状態を確認し、コマンドラインツールでポートの使用状況を調べます。
  • 対処法:競合しているプログラムを終了するか、Clashの待受ポートを変更し、クライアントを再起動して設定を反映させます。

チェックポイント4〜6:ノード自体が使えるか検証する

4. ノード遅延テストの結果

クライアントに表示される遅延値(ms)は通常、ノードサーバーに対する一度の接続テストの結果です。数値が正常であればサーバーはオンラインでネットワーク到達可能であることを示します。タイムアウトや極端に高い遅延が表示される場合は、ノード自体に問題があり、ローカル設定とは無関係です。

  • 確認方法:プロキシグループの一覧で手動で遅延テストを実行し、現在選択中のノードがタイムアウト表示(通常は赤字や timeout 表示)になっていないか重点的に確認します。
  • 対処法:現在のノードがタイムアウトしている場合は、遅延が正常な別のノードに切り替えます。サブスクリプション内のすべてのノードがタイムアウトしている場合は、サブスクリプション自体やローカルのネットワーク環境に問題がある可能性が高いため、チェックポイント1・2に戻って再確認してください。

5. プロキシグループの自動選択ロジック

多くのサブスクリプション設定に含まれる「自動選択」プロキシグループは、遅延や生存状態に基づいて実際に使用するノードを自動的に切り替えます。この自動選択グループが現在指している実ノードがちょうど不調である場合、グループ内に他の健全なノードがあっても、切り替えの遅延によって一時的にネットにつながらなくなることがあります。

  • 確認方法:自動選択グループを展開し、現在実際に有効になっている子ノードの遅延が異常でないか確認します。
  • 対処法:自動選択グループに依存せず、動作確認済みの具体的なノードへ手動で強制切り替えを行い、自動切り替えロジックによる影響を排除します。

6. ノードのプロトコルとサーバー側設定が一致しているか

手動で追加または変更したノード(サブスクリプションから直接生成した設定ではない場合)では、プロトコルの種類、暗号化方式、トランスポート層の設定などのパラメータがサーバー側と一致していないと、「接続はできるが有効なセッションが確立できない」状態になります。この場合も、遅延は正常なのにページが開けないという症状として現れます。

  • 確認方法:ノードのパラメータとサーバー提供者から渡された元の設定が完全に一致しているか照合します。特にトランスポートプロトコルと暗号化方式の2点に注意してください。
  • 対処法:サブスクリプションリンクから設定を再生成し、手動入力によるパラメータの誤りや漏れを避けます。

チェックポイント7〜9:DNSとルールレベルの確認

7. DNS解決が汚染されていないか

一部のネットワーク環境ではDNSクエリのハイジャックや改ざんが行われることがあります。プロキシ自体が正常に動作していても、ドメイン解決の段階で誤ったIPアドレスが返されていれば、その後のリクエストは失敗するか、誤ったサーバーに送られてしまいます。この場合、プロキシの速度テストは完全に正常でも、ページは開けないままという状態になります。

  • 確認方法:プロキシを有効にした状態と無効にした状態で、同一ドメインの解決結果のIPアドレスが異なっていないか比較します。クライアントのログに記録されたDNSクエリ履歴を直接確認する方法もあります。
  • 対処法:設定ファイル内でClash内蔵のDNSモジュールを有効にし、ドメイン解決をシステムデフォルトのDNSではなくClashに処理させます。必要に応じて fake-ip モードを有効にし、根本的にローカルネットワーク環境による解決結果の改ざんを防ぎます。
Notice / 確認のポイント

DNS汚染は見落とされやすいものの、影響範囲が最も広い問題の一つです——プロキシ接続自体にエラーは出ず、最終的にアクセスする対象アドレスが誤っているだけなので、調査時には「ノードが不安定」と誤判定されやすい点に注意してください。

8. ルールがトラフィックを誤ってDIRECTと判定していないか

ルールモードでは、設定ファイル内のルールセットがリクエストのドメインやIPを1件ずつマッチングし、DIRECTルールにヒットした時点でトラフィックはプロキシを経由せず直接接続されます。ルールセットのバージョンが古い場合やルールの順序に誤りがある場合、本来プロキシを経由すべきドメインが先に直接接続ルールにマッチしてしまうことがあります。特にカスタムルールや複数のルールセットを重ねて使用している設定では注意が必要です。

  • 確認方法:クライアントの接続ログやルールマッチング履歴を確認し、対象ドメインが実際にどのルールにヒットし、どの出口ポリシーグループを経由しているかを確認します。
  • 対処法:ルールの順序を調整し、より詳細なプロキシルールを大まかな直接接続ルールより前に配置するか、ルールセットを最新版に更新します。一時的な検証時にはグローバルモードに切り替えてルールによる影響を排除するのも有効です。

9. 出口ポリシーグループが指すノードグループが空、または全ノードが無効になっていないか

一部の設定では、トラフィックの種類(動画配信、SNSアプリ、国内直結など)ごとに独立したポリシーグループを設け、そのポリシーグループ内部からさらに具体的なノードを参照する構成になっています。フィルタ条件が厳しすぎるためにあるポリシーグループ内に利用可能なノードが存在しない場合、そのポリシーグループにマッチしたトラフィックは、主用のデフォルトプロキシグループが正常であっても直接失敗します。

  • 確認方法:設定ファイル内で定義されているポリシーグループを1つずつ確認し、各グループに現在利用可能なノードが少なくとも1つ含まれているか確認します。
  • 対処法:ポリシーグループのノード元を補充するか、空のポリシーグループを一時的に主用プロキシグループへ差し替え、特定タイプのトラフィックが行き場を失う事態を避けます。

9項目のチェックを一本の調査フローにまとめる

実際の作業では、番号順に一つずつ機械的に終えてから結論を出す必要はありません。より効率的な方法は、まず2回の簡易判定で範囲を絞ることです。1回目は「ローカル設定の問題かどうか」を判定します——一時的にグローバルモードに切り替え、問題が解消すればルールまたはDNSレベルの問題である可能性が高いです(チェックポイント7〜9)。切り替えても依然としてネットにつながらない場合は、システムプロキシのスイッチ、ポートの競合、ノード自体の状態を重点的に確認します(チェックポイント1〜6)。

9項目すべてを確認しても問題が解決しない場合は、クライアントのログのスクリーンショットを保存しておき、サブスクリプションを再インポートして全く新しい設定ファイルを生成し、比較テストを行うことをお勧めします。長期間の手動修正が積み重なった既存の設定ファイル自体に問題があることもあるため、クリーンな設定を用意する方が、旧設定を掘り続けるより時間の節約になる場合が多いです。

# プロキシが有効かどうかを素早く確認するコマンドライン方法(WindowsとmacOSで類似の構文が利用可能)
curl -x http://127.0.0.1:7890 https://www.google.com -I

# タイムアウトや接続拒否ではなくHTTPステータスコードが返る場合、プロキシ経路自体は通っている
# この場合、問題はDNS解決またはルールマッチングのレベルにある可能性が高い
Clash をダウンロード