Clash初心者向け FAQ 10選｜サブスクリプションの読み込み失敗・ノードのタイムアウト・システムプロキシが効かない原因と対処法

Clashのトラブルは、まずどの段階で起きているかを確認しましょう。設定が正常に読み込まれているか、ノードに接続できるか、アプリの通信がクライアントに届いているかを順番に調べます。モードやポートを次々と変更したり、再インストールしたりするより、原因を特定しやすくなります。

01 / Clash、クライアント、mihomoの違いは？

クライアントは操作画面を提供し、コアは接続を処理します。サブスクリプションの読み込み、ノードの選択、システムプロキシの有効化は通常クライアントで行います。ルールを読み込み、サーバーに接続するのはコアです。Clash Metaプロジェクトは後にmihomoへ名称を変更しました。古い解説では以前の名称が使われている場合があります。

クライアント：デスクトップのウィンドウやトレイメニュー、スマートフォンアプリなどを指します。ボタンや設定項目の配置を決めます。
コア：プロキシプロトコル、ルール判定、DNS、接続処理を担い、設定項目に対応しているかどうかを決めます。
設定：コアが読み込む設定ファイルです。通常はYAML形式で、インデントによって階層を表します。

「未対応のプロキシタイプ」や「不明なフィールド」と表示された場合は、アプリのアイコンだけで判断しないでください。クライアントの「バージョン情報」やコア情報の画面で名称とバージョンを確認し、サブスクリプションがそのコアに対応しているか調べましょう。旧版Clashで読み込める設定と、現在のmihomoで読み込める設定は完全には一致しません。

02 / インストールしたのに、ノードを選べないのはなぜ？

クライアントをインストールしただけでは、プロキシ設定は使えません。ノードはリモートサーバーへの接続情報で、通常はサービス提供元からサブスクリプションとして提供されます。サブスクリプションURLは設定の取得・更新に使うアドレスで、開けばそのまま使える一般的なウェブページではありません。

信頼できる提供元から、使用中のクライアントまたはコアに対応したサブスクリプションURLを取得します。アカウント管理ページのURLを代わりに使わないでください。
クライアントの「設定」画面を開き、リモート設定の新規作成またはURLからの読み込みを選び、URL全体を貼り付けます。
読み込み後、この設定を選択して現在有効な設定にします。
「プロキシ」画面を開き、ルールから参照されているプロキシグループを展開してノードを選びます。プロキシグループは、ルールから利用できる接続先のまとまりです。

設定一覧に名前が表示されていても、コアがその設定に切り替わったとは限りません。プロキシ画面に直接接続しか表示されない場合は、まず現在の設定が選択されているか確認し、次にログで読み込みエラーがないか調べてください。

03 / サブスクリプションを読み込めないとき、URLとネットワークのどちらを確認する？

エラーの内容を見てから、確認する箇所を決めましょう。タイムアウト、権限エラー、解析エラーはそれぞれ原因が異なります。何度も更新ボタンを押しても、同じエラーが繰り返されるだけです。

エラー・症状	まず確認すること	次に行うこと
接続タイムアウト、ドメイン名の解決に失敗	サブスクリプション取得時のネットワーク経路	通常のウェブページが開けることを確認し、更新処理が無効なプロキシ経由になっていないか調べる
HTTP 401または403	サブスクリプションの認証情報、アカウントの状態、アクセス制限	サービス提供元のページからURLを再取得します。古いURLを何度も公開の場でテストしないでください。
HTTP 404	URL全体が正しいか、接続先の仕様が変更されていないか	サブスクリプションURLをコピーし直し、パスやクエリパラメーターが欠けていないか確認します。
YAMLの解析に失敗	取得した内容が実際に設定ファイルかどうか	ログインページやエラーページが返されていないか、未対応のサブスクリプション形式ではないか確認します。

3つの手順で原因を絞り込む

URLをコピーし直し、前後の空白を削除します。日本語の句読点や改行が混入していないか確認してください。
サービス提供元が案内する形式を確認し、使用中のコアに合ったClashまたはmihomoの設定を選びます。
現在のプロキシが使えず、サブスクリプション更新がプロキシ経由に設定されている場合は、一時的に直接接続で更新します。反対に、直接接続でURLにアクセスできない場合は、利用可能で使用が許可された経路が必要です。

04 / 読み込みは成功したのに設定エラーが出るとき、どこを直せばいい？

取得の成功と読み込みの成功は別です。クライアントがファイルをダウンロードできても、コアが内容を解析できないことがあります。「ログ」を開き、最後に表示された起動失敗だけでなく、今回の読み込みで最初に発生した設定エラーを確認しましょう。

インデントの誤り：YAMLでは空白で階層を表します。Tabは使わないでください。エラー箇所の直前の行も確認しましょう。
参照先が見つからない：ルールが参照するプロキシグループ名は、定義された名前と完全に一致している必要があります。空白が一つ違うだけでもエラーになります。
コアとの互換性：設定に現在のコアが認識できないプロトコルやフィールドが含まれている場合は、対応する形式または互換性のあるコアを使います。エラー行をそのまま削除するだけでは解決しません。

次の2行は、ルールからグループ名を参照する方法の例です。完全な設定ファイルではありません。

rules:
  - DOMAIN-SUFFIX,example.com,Webプロキシ
  - MATCH,DIRECT

ここで指定した「Webプロキシ」は、設定のproxy-groupsに存在している必要があります。MATCHは、残りの通信に一致することを示します。変更する前に元のファイルをバックアップしてください。リモートサブスクリプションでは、ダウンロードしたファイルを直接編集しても次回更新時に上書きされることがあります。継続的に変更する場合は、クライアントが対応する上書きまたはマージ機能を使い、変更が実際に反映されたことを確認しましょう。

05 / ノードの速度テストがすべてタイムアウトする場合、ノードが全滅したということ？

速度テストのタイムアウトは、テスト要求が制限時間内に完了しなかったことを示すだけです。ノードに接続できない場合だけでなく、テスト先URL、DNS、設定の選択に問題がある場合もあります。速度テストの数値は通常、指定先への応答状況を表し、ダウンロード速度を示すものではありません。

まず、端末から通常の直接接続サイトにアクセスできることを確認し、回線障害やWi-Fiのログイン画面が原因でないか切り分けます。
現在の設定が正常に読み込まれていること、サブスクリプションの期限が切れておらず、通信量も残っていることを確認します。
ノードを手動で1つ選び、利用が許可されたページにアクセスしながら、接続状況とログを確認します。
実際のアクセスは正常なのに速度テストだけがタイムアウトする場合は、テストURL、タイムアウト時間、テスト方法を確認します。実際のアクセスにも失敗する場合は、別のノードでも試してください。

レイテンシだけで判断せず、条件を変えて比較する

たとえば、あるノードが80 ms、別のノードが180 msと表示されても、今回のテストで応答にかかった時間が異なるというだけです。前者のダウンロード速度が必ず速いとは限りません。自宅のネットワークでは複数のノードが使えず、スマートフォンのテザリングに切り替えると使える場合は、クライアントをすぐ再インストールするのではなく、まずローカルネットワークの経路を確認しましょう。

ログのconnection refusedは通常、接続が拒否されたことを示します。timeoutは待ち時間が上限を超えたことを示し、no such hostは多くの場合、ドメイン名の解決に問題があることを示します。対象と発生時刻を記録すれば、ローカルの接続口、リモートノード、接続先サイトのどこに問題があるか切り分けやすくなります。

06 / システムプロキシを有効にしたのに、ブラウザーに反映されないのはなぜ？

システムプロキシは、その設定に従うアプリに対して、リクエストをローカルのプロキシポートへ送るよう指示します。すべてのプログラムを自動的に経由させるわけではありません。まず、システムに設定されたアドレスと、コアが実際に待ち受けているアドレスが一致しているか確認しましょう。

クライアントの設定または実行中の設定で、HTTPポートまたは混合ポートを確認します。混合ポートはHTTPとSOCKSの両方のプロキシリクエストを受け付けます。
ローカルの混合ポートが実際に7890の場合、システムプロキシには127.0.0.1:7890を指定します。この例のポート番号を、すべてのクライアントの既定値だと考えないでください。
Windows 11では「設定」→「ネットワークとインターネット」→「プロキシ」を開き、手動プロキシの設定を確認します。macOSでは「システム設定」→「ネットワーク」→接続中のネットワーク→「詳細」→「プロキシ」を開きます。
ブラウザーのプロキシ拡張機能、個別のプロキシ設定、起動中のほかのネットワークツールを確認し、システム設定が上書きされていないか調べます。

Windows PowerShellでは、次のコマンドでローカルのHTTPプロキシ接続口を直接テストできます。ポート番号は実際の値に変更してください。

curl.exe --proxy http://127.0.0.1:7890 --connect-timeout 10 -I https://example.com

このコマンドはプロキシを明示的に指定するため、ブラウザーがシステムプロキシに従うかどうかには左右されません。テスト先へのリクエストが1回成功したかどうかを確認するだけです。127.0.0.1に接続できない場合は、コアが起動しているか、ポート番号が正しいかを確認します。クライアントまで接続できているのにアクセスに失敗する場合は、ルールとノードを確認しましょう。

07 / ルールモード・グローバルモード・直接接続モードはどれを選ぶ？

普段はルールモードを使い、トラブルの切り分け時だけ一時的に切り替えましょう。3つのモードは、コアに届いたリクエストの接続先を決めるもので、アプリの通信がクライアントに届いているかどうかを決めるものではありません。

ルールモード：設定内のルールを上から順に照合し、該当するプロキシグループ、直接接続、拒否のいずれかを適用します。
グローバルモード：通常、コアに届いたリクエストをグローバルポリシーで処理します。グローバルグループでノードと直接接続のどちらが選択されているか確認してください。
直接接続モード：コアに届いたリクエストを直接接続します。システムプロキシが無効になる、またはコアが停止するという意味ではありません。

ルールは通常、上から順に照合され、一致すると該当するポリシーが適用されます。そのため、同じサイトがルールモードでは直接接続され、グローバルモードではノード経由になることがあります。これはルールの適用結果の違いであり、必ずしもクライアントの不具合ではありません。「接続」を開いて対象ドメイン、適用されたルール、実際のポリシーチェーンを確認すると、ページが開くかどうかだけを見るより原因を特定しやすくなります。

08 / TUNモードが必要なのはどんなとき？有効にした後、ネットに接続できなくなったら？

システムプロキシに従わない通信も取り込みたい場合は、TUNの利用を検討してください。TUNは仮想ネットワークインターフェースで、システムのルート設定を通じて対象の通信をコアに渡します。管理者権限やクライアントのサービスモードが必要な場合があり、利用できる機能はOS、コア、設定によって異なります。

有効にする前に、基本の接続経路を確認する

プロキシを明示的に指定したリクエスト、またはブラウザーを使って、少なくとも1つのノードから目的のサイトに正常にアクセスできることを確認します。
システムプロキシ、DNS、ほかのVPNの現在の状態を記録し、複数の条件を同時に変更しないようにします。
クライアントの要件に従ってサービスをインストールするかネットワーク権限を付与してからTUNを有効にし、インターフェースが作成されたか、ルートや権限のエラーがないか確認します。

有効にした後、直接接続のサイトも開けなくなった場合は、まずTUNを無効にして元のネットワークが復旧するか確認し、権限、ルートの競合、DNS設定を調べます。DNSはドメイン名をIPアドレスに変換する仕組みです。DNS設定に問題があると、接続自体は保たれていてもドメイン名を解決できないことがあります。

ほかの解説にあるfake-ip、DNSハイジャック、ルート設定の項目をまとめて既存の設定に貼り付けないでください。fake-ipは仮想アドレスを使ってドメイン名とIPアドレスを対応付ける仕組みです。適切かどうかは、現在のDNSやルーティング方式に応じて判断してください。企業ネットワーク、ほかのVPN、仮想マシンのネットワークもTUNと競合する場合があります。

09 / ブラウザーは使えるのに、ゲームやストアアプリが使えないのはなぜ？

まず、問題のアプリからの通信がクライアントに表示されているか確認しましょう。ブラウザーで成功しても、ほかのアプリが同じ接続方式を使っているとは限りません。

接続一覧にリクエストが表示されない：アプリがシステムプロキシを無視しているか、独自のプロキシ設定を使っている可能性があります。まずアプリの設定を確認し、必要に応じてTUNで通信を取り込めるか検討してください。
リクエストは表示されるが、直接接続されている：適用されたルールとプロキシグループを確認し、想定どおりか調べてください。ノードを替えるだけでは解決しない場合があります。
ノードに接続しても失敗する：接続先のプロトコル、サービスの制限、ノードが必要な通信方式に対応しているか確認してください。ゲームによってはUDPを使用するため、HTTPプロキシが使えてもUDP通信が使えるとは限りません。
一部のWindowsストアアプリで失敗する：UWPのネットワーク分離が関係している場合があります。UWPはWindowsのアプリプラットフォームの一つです。この種のアプリがローカルのループバックプロキシにアクセスするには、アプリごとにループバックの除外設定が必要な場合があります。

ループバックの除外設定で対処できるのは、特定のアプリがローカルインターフェースにアクセスする際の制限だけです。期限切れのサブスクリプションを直したり、未対応のプロトコルを使えるようにしたりするものではありません。まずアプリと通信経路を特定してから、信頼できるクライアントが提供する適切なツールを使いましょう。テスト目的で、すべてのアプリの制限を一括解除しないでください。

10 / サブスクリプションの更新後やクライアント終了後に異常が起きたら、安全に復旧するには？

まず以前の接続経路に戻し、その後で根本的な対処を行いましょう。サブスクリプションを更新すると、ノード名、プロキシグループの構成、ルールが変わることがあります。また、クライアントを終了しても、システムプロキシがローカルポートを指したままになる場合があります。この2つの問題は分けて対処してください。

サブスクリプション更新後に接続できない

現在有効になっている設定と、直近の更新が正常に完了したかを確認します。
プロキシグループの選択を確認します。以前手動で選んだノードの名前が変わったり削除されたりすると、グループ内の選択結果が変わる場合があります。
設定の読み込みログを確認します。利用可能だと分かっているローカルバックアップがあれば、一時的に切り替えて検証できます。ただし、バックアップ内のノードや認証情報も期限切れの可能性があります。
復旧後、カスタムルールを一つずつ移行します。構成が変わった新しい設定に古いルールをそのまま上書きしないでください。

クライアント終了後にインターネットへ接続できない

まず、システムプロキシがまだ127.0.0.1を指していないか確認します。クライアントの待ち受けが停止した後もこのプロキシ設定が有効だと、接続に失敗します。残ったプロキシ設定を無効にしてください。TUNを使っていた場合は、インターフェースとルートが元の状態に戻っているかも確認します。この確認をせずに設定フォルダー全体を削除しないでください。