Clash よくある質問とトラブルシューティング
サブスクリプションのインポートからプロキシの有効化まで、問題が発生した段階から対処方法を探せます。各項目では再現しやすい確認手順を優先し、Windows、macOS、Android、iOS、Linuxの一般的なクライアントに対応しています。
クライアント、コア、設定をまず切り分ける
Clashの問題には、グラフィカルクライアント、Mihomoコア、サブスクリプションの内容、システムプロキシが同時に関係することがあります。各層の役割を確認してから導入やネットワークの切り分けに進むと、クライアント画面の問題をノード障害と誤認せずに済みます。
Clash、Clash Meta、Mihomoクライアントにはどのような関係がありますか？
Clashは、プロキシクライアントとコアのエコシステムを総称する名前です。現在のデスクトップクライアントは、通常Mihomoコアまたは互換コアを使用します。クライアントは画面表示、設定のインポート、システムプロキシを担当し、コアは設定の解析、ルールの照合、接続の確立を担います。クライアントを選ぶ際は、対応プラットフォーム、コアの機能、メンテナンス状況を確認しましょう。
サブスクリプションURLと個別ノードの違いは何ですか？
個別ノードは1つの接続情報だけを示しますが、サブスクリプションURLからは通常、複数のノード、プロキシグループ、ルール設定が取得されます。クライアントはサブスクリプションURLから定期的に更新内容を取得するため、更新に失敗しても既存の設定は使える場合があります。ただし、新しいノードやプロキシ設定の変更は反映されません。
グローバル、ルール、直接接続モードはどう使い分けますか？
ルールモードは設定内のルールに従って接続経路を決めるため、普段使いに適しています。グローバルモードは大半の通信を選択したプロキシ経由に統一し、プロキシ経路を一時的に確認したい場合に便利です。直接接続モードはプロキシを経由せず、アクセス異常の原因がプロキシ設定かどうかを切り分ける際に使います。通常はまずルールモードを選びましょう。
同じサブスクリプションがクライアントによって異なって表示されるのはなぜですか？
クライアントによって、使用するコアのバージョン、設定の互換範囲、デフォルトのDNS設定、ルール処理方式が異なる場合があります。まずサブスクリプション形式がクライアントに認識されているか確認し、次にコアの種類、上書き設定、ルールモードを確認してください。ノード数だけでインポートの成否を判断しないようにしましょう。
許可から初回接続まで順番に確認
インストールが完了しても、プロキシが通信を制御できる状態になったとは限りません。クライアントは設定を読み込み、システム権限を取得し、プラットフォームに応じてシステムプロキシまたはVPNインターフェースを構築する必要があります。以下の項目は、初回導入や端末変更時の確認に役立ちます。
Windowsにクライアントをインストールする前に確認すべきことは？
システムバージョンがクライアントの要件を満たしていること、クライアントに通常のファイル読み書き権限があることを確認します。初回起動後は、設定ファイルの保存先、システムプロキシの状態、ファイアウォールの通知を確認してください。すでに別のVPN、プロキシツール、ネットワークフィルタリングソフトを使用している場合は、複数のソフトが同時にシステムプロキシを制御しないよう、先に動作状態を記録しておくと安心です。
AndroidクライアントにVpnService権限が必要なのはなぜですか？
AndroidクライアントはVpnServiceを使ってローカルVPNインターフェースを作成し、アプリの通信をプロキシコアに渡します。この権限は遠隔VPNサービスの利用許可ではなく、クライアントが端末の通信を処理するためにシステムから求められるものです。初回有効化時はシステムの確認画面で許可し、他のVPNが実行中でないことも確認してください。
iOSクライアントで設定をインポートしても接続できない場合、何を確認すべきですか？
まず設定が正常にインポートされていることを確認し、次にシステム設定でクライアントによるVPN構成の追加を許可します。クライアントに戻り、ルールモードまたはグローバルモードを選択して、利用可能なプロキシグループで接続してください。ステータスバーにVPNの表示がない場合は、許可画面、システムのVPN一覧、他のVPN構成との競合を再確認します。
サブスクリプションの更新に失敗した場合、どの順番で確認すればよいですか？
まずブラウザまたはクライアントのログで、サブスクリプションURLにアクセスできるか確認します。次に、システム時刻、ネットワーク接続、URLが完全かどうかを確認してください。その後、クライアントに利用可能なプロキシがあるか確認し、必要であれば直接接続で更新するか、一時的にネットワークを切り替えます。URLから設定内容ではなくHTML、ログイン画面、エラーメッセージが返る場合は、サブスクリプション提供元にURLの状態を確認してください。
サブスクリプション、ノード、プロキシモードを管理する
安定した利用には、確認できる設定手順が欠かせません。更新後に内容を確認し、接続前にプロキシグループを確認し、アクセス異常時にはテスト先を切り分けます。1回の速度テストだけで、すべての通信状況を判断しないようにしましょう。
サブスクリプションの更新は成功したのに、ノード一覧が変わらないのはなぜですか？
クライアントが古い設定を保持しているか、サブスクリプション側の内容がまだ更新されていない可能性があります。更新ログの応答状態とインポート結果を確認し、設定の更新時刻が実際に変わっているか確認してください。その後、設定を再読み込みし、プロキシグループが新しいノードを参照しているか確認します。サブスクリプション自体の内容が変わっていなければ、クライアントが新しいノードを自動生成することはありません。
ノードテストはタイムアウトするのに、ブラウザではWebページを開けます。問題をどう切り分ければよいですか？
ノードテストの接続先と実際のアクセス先は、同じ経路とは限りません。タイムアウトの原因は、テスト先への到達不能、ノード側の制限、DNS解決、またはテスト時間の短さなどが考えられます。まずプロキシモードで既知の正常な接続先にアクセスし、クライアントのログを確認してください。同時に、別のノードや異なるテストURLとも比較します。1回の遅延値やタイムアウトだけで、ノードが完全に使えないと判断しないようにしましょう。
TUNモードを有効にする前に何を準備すべきですか？
TUNを有効にする前に、クライアントが対象システムに対応していること、管理者権限またはシステムの許可を準備できることを確認します。競合する可能性のあるVPN、仮想ネットワークアダプター、その他の通信制御ツールは停止してください。有効化後はTUNの状態、DNS設定、ルールモードを確認し、コマンドラインまたはブラウザで実際の通信がプロキシに入っているか検証します。通信できなくなった場合は、まずTUNを無効にしてシステムプロキシモードに戻し、結果を比較します。
TUNモードで権限不足と表示される、または有効化直後に無効になる場合はどうすればよいですか？
クライアントが必要な権限で実行されているか確認し、セキュリティソフトが仮想ネットワークアダプターやネットワークサービスをブロックしていないか確認します。Windowsでは関連ドライバーのインストール通知と既存のVPNアダプターも確認してください。Linuxでは実行権限、ルーティング設定、カーネルの対応状況を確認します。ログの具体的なエラーを確認してから再度有効にし、短時間に何度も切り替えて残存インターフェースを増やさないようにしましょう。
システムプロキシ、ループバック、DNSを順に確認
一部のアプリだけがアクセスできない場合、問題が「ノードがオンラインかどうか」の層にあるとは限りません。アプリがシステムプロキシに従うか、ローカルのループバックを必要とするか、DNSが想定したアドレスを返しているかの順に確認すると、原因の範囲を絞り込めます。
システムプロキシを有効にしているのに、一部のソフトが直接接続するのはなぜですか？
システムプロキシの影響を受けるのは、主にシステムプロキシの仕様に従うアプリです。一部のソフトは独自のネットワークスタックや固定プロキシ設定を使用したり、特定のプロトコルにしか対応していなかったりするため、システムプロキシを読み取りません。まずクライアントの待ち受けアドレスとポートを確認し、次に対象ソフトのプロキシ設定を確認してください。このような通信も制御する必要がある場合は、TUNモードを検討し、権限、DNS、ネットワークルーティングへの追加要件に注意します。
WindowsのUWPアプリがプロキシ経由で通信できない場合、ループバックをどう設定しますか？
一部のUWPアプリはデフォルトでローカルのループバックアドレスにアクセスできないため、端末上で動作するプロキシのポートに接続できません。システムのアプリループバック免除ツールを使い、対象のUWPアプリにループバック権限を付与して設定を保存し、アプリを再起動してください。操作前に、ローカルプロキシへのアクセスが本当に必要なアプリだけを選択します。完了後はシステムプロキシとクライアントログも確認してください。
Fake-IPモードでLAN機器や一部のアプリにアクセスできない場合はどうすればよいですか？
Fake-IPはドメインに仮想アドレスを割り当てるため、ドメイン解決やルール照合に依存するアプリで互換性の問題が起きることがあります。まず対象ドメインがFake-IPの除外リストまたはnameserver-policyに設定されているか確認し、クライアントのDNSキャッシュを削除して再接続します。LAN機器、プリンター、ゲーム機、実際のアドレスを直接取得する必要があるアプリは、状況に応じて直接接続または除外に設定してください。
DNS設定に異常があるとき、名前解決の問題とノードの問題をどう区別できますか？
まず直接接続モードで同じドメインを解決し、次にルールモードへ切り替えて結果を比較します。直接接続では解決に失敗し、プロキシ経由では正常な場合は、ローカルネットワークまたはDNSに問題がある可能性があります。どちらでも解決できるのに接続できない場合は、ノード、ルール、対象サービスを引き続き確認してください。ログのDNSリクエスト、返されたアドレス、適用されたルールを確認すると、ノードを何度も変えるより原因を特定しやすくなります。
ルールを変更したのに、すぐ反映されないのはなぜですか？
ルールファイルを変更しても、クライアントがメモリ上の古い設定や古いDNSキャッシュを使い続けている場合があります。まず設定を保存して再読み込みし、ルールファイルのパスと構文が正しいことを確認してください。その後、関連する接続を切断するかアプリを再起動します。ルールのヒット情報を見るときは、ルールの順番も確認してください。MATCHなどのフォールバックルールが早い位置にあると、後続のルールに一致しなくなります。