Clash よくある質問

Clash MetaはClash派生コアの旧称で、プロジェクト名は後にmihomoへ変更されました。コアはプロトコル接続、ルール判定、DNS処理を担い、GUIクライアントはサブスクリプションの追加、プロキシグループの選択、システムプロキシの切り替えなどを行う画面を提供します。同じmihomoを使うクライアントでも、メニューの場所や設定の上書き方法は異なる場合があります。トラブル時はクライアント名とコアのバージョンを記録し、ウィンドウにClashと表示されているだけで対応機能を判断しないでください。クライアントを変更する前に設定を書き出してカスタマイズ内容を記録し、新しいクライアントのコアに関する説明を確認しましょう。

クライアントは設定を実行するためのツールです。インストールしただけでは、利用可能なリモートプロキシサービスが使えるようになるわけではありません。通常は利用権限のあるサブスクリプションURLを追加するか、プロキシ、プロキシグループ、ルールを含むローカル設定を読み込む必要があります。サブスクリプションの有効期限や利用量の制限、サーバーの状態はサービス提供元が管理しており、クライアントを再インストールしてもリセットされません。初回利用時は設定の入手元を確認し、プロキシグループが正しく生成されているかを確認しましょう。DIRECTしか表示されない場合は、システムプロキシを何度も切り替えるのではなく、設定内容とインポートログを確認してください。サブスクリプションURLには認証情報が含まれる場合があるため、公開しないでください。

サブスクリプションURLはリモートの設定を取得するための入口です。Profileは通常、クライアントに保存された設定情報を指し、YAMLは一般的な設定ファイル形式です。サブスクリプションから取得する内容は、Clash設定一式の場合も、プロキシノード一覧のみの場合もあります。ノード一覧の場合は、クライアントが対応するインポート方法を備えているか、信頼できるツールで変換する必要があります。インポート後は、プロキシグループ、ルール、DNS設定がそろっているか確認しましょう。リモート更新では通常、サブスクリプションから生成された内容が置き換わります。長く使うカスタムルールはクライアントの上書き・マージ設定に保存し、更新で消えるファイルを直接編集しないようにしてください。

ルールモードは設定内のルールに基づいて接続ごとにプロキシを選ぶため、宛先に応じた振り分けに適しています。グローバルモードは、コアに渡された接続をすべてグローバルポリシーに従わせます。一時的な比較テストには便利ですが、端末上のすべてのアプリを制御するわけではありません。DIRECTモードでは通常、コアが処理する接続をプロキシ経由にせず宛先へ直接接続するため、プロキシ側の問題を切り分ける際に役立ちます。いずれのモードも、通信が実際にコアへ届いていることが前提です。アプリがシステムプロキシを経由しない場合、モードを切り替えても変化しないことがあります。変更後は新しい接続を作成して接続ログを確認してください。既存の長時間接続には、切り替え前のプロキシが使われ続ける場合があります。

まずOSを選び、次にCPUアーキテクチャとパッケージ形式を確認します。Windowsでは「設定」の「バージョン情報」でシステムの種類を確認できます。macOSでは「このMacについて」でAppleシリコンかIntelかを確認してください。Linuxではuname -mでアーキテクチャを調べ、ディストリビューションに合ったパッケージを選びます。Androidでは端末とクライアントのアーキテクチャ要件を確認しましょう。デスクトップ用インストーラーやコアの圧縮ファイルをスマートフォンアプリとして扱うことはできません。インストールに失敗したらOSのバージョンとエラーメッセージ全文を記録し、アーキテクチャの不一致、OSのバージョン不足、古いインストールとの競合を確認してください。出所不明の改変版を次々に試すのは避けましょう。

設定またはProfiles画面にサブスクリプションURL全体を貼り付けてインポートし、該当する設定が現在の設定として選択されていることを確認します。クライアントによっては、設定のダウンロードと有効化が別操作です。リストに表示されただけでは、コアに読み込まれたとは限りません。次に、プロキシグループに想定した選択肢が表示されているか確認し、ログにYAMLの解析エラーや未対応フィールドがないか調べましょう。ローカルファイルを読み込んだ場合は元ファイルのコピーを保管し、外部ルールセットやプロキシ一覧を取得できるか確認します。最後に利用可能なプロキシを選び、新しい接続を作成して、適用されたルールとプロキシを確認してください。

TUNモードは仮想ネットワークインターフェースの作成とルーティングの変更を行うため、通常はシステムプロキシより高い権限が必要です。Windowsではクライアントのサービスモードがインストールされ、実行中か確認してから、画面の指示に従って権限を許可します。macOSではシステムネットワーク拡張機能や補助サービスの許可状態を確認してください。Linuxではクライアントのドキュメントに従い、TUNデバイスと必要な権限を確認します。AndroidとiOSでは通常、VPN構成の追加を許可する必要があります。トラブル対処のためにシステムのセキュリティ機能を長期間無効にしないでください。解決しない場合は、ほかのVPNや通信制御ツールを終了してから、インターフェース、ルート、権限に関するエラーを確認しましょう。ログを共有する前にサブスクリプションURLと認証情報を削除してください。

iOSクライアントは通常、システムネットワーク拡張機能を使って通信を処理するため、初回接続時にVPN構成の追加を求めます。許可を求めているのがインストールしたクライアントであることを確認し、システムの手順に従って許可してください。その後アプリに戻り、設定を読み込んで接続を開始します。システムにVPNアイコンが表示されても、トンネルが有効になったことを示すだけで、選択したリモートプロキシが使えるとは限りません。クライアントの接続ログも確認してください。組織管理下の端末では、ポリシーにより権限が制限されている場合があります。端末の管理者に相談してください。Clash Plusを利用する場合はダウンロードページからApp Storeに進めます。製品情報はclashplus.ioで確認できます。

手動選択グループでは、ユーザーがプロキシを1つ選んで固定します。自動テストグループは通常、指定されたテスト先への応答をもとにプロキシを選びます。フェイルオーバーグループは設定順と利用可否に基づいて切り替えます。テスト結果が示すのは、その時点でテスト先に接続した結果であり、すべてのWebサイトでの使い心地やダウンロード速度を保証するものではありません。特定のサイトの問題を調べる場合は、手動選択グループで同じノードに固定すると、自動切り替えの影響を抑えられます。プロキシグループがほかのグループを内包していないかも確認してください。最終的な接続先は、画面に直接表示されたグループの一段先にある場合があります。切り替え後は新しい接続で確認しましょう。

ルールは通常、上から順に評価され、最初に一致したルールでプロキシが決まります。先に一致する可能性がある広範なルールより前にカスタムルールを置き、指定するプロキシ名が実際のプロキシグループ名と一致していることを確認してください。クライアントに上書き・マージ機能がある場合は、ルールが挿入される位置を確認したうえで、そこで管理するのがおすすめです。リモート設定を直接編集すると、サブスクリプション更新時に変更が失われることがあります。保存後に設定を再読み込みし、接続ログで適用されたルールを確認しましょう。ドメインルールの判定には、コアがドメイン名を認識できる必要があります。接続の再利用や既存の長時間接続が確認に影響する場合もあるため、テスト前に古い接続を終了して再アクセスしてください。

Fake-IPはドメイン名に仮想アドレスを割り当て、コアがその対応関係から接続先を識別して通信を振り分けます。redir-hostは通常、アプリに実際の名前解決結果を返します。方式名だけで選ぶのではなく、クライアントのDNS処理方法とアプリとの互換性を考慮してください。特定のLANサービスやアプリで問題が起きた場合は、まず該当するドメインを確認します。そのうえで必要に応じてfake-ip-filterから対象ドメインを除外し、範囲を広げすぎないようにしましょう。方式を切り替えた後は、システムやアプリのDNSキャッシュを消去して接続を作り直す必要がある場合があります。アプリが独自に暗号化DNSを使う場合は、その名前解決が現在の設定を迂回していないかも確認してください。

LAN内接続を許可すると、同じ信頼できるネットワーク上のほかの端末から、この端末のプロキシポートを利用できます。スイッチをオンにするだけでなく、待ち受けアドレス、実際のポート番号、システムのファイアウォール設定も確認してください。接続する端末には、クライアントを実行している端末のLAN内アドレスを入力します。接続元端末自身のループバックアドレスではありません。必要なネットワークと端末に限って公開し、公共のネットワークでは無効にしてください。クライアントが対応している場合はアクセス認証も設定しましょう。ルーターのポート転送でプロキシポートやコントロールインターフェースをインターネットに公開してはいけません。接続できない場合は、ネットワーク分離、ファイアウォール、ポートの待ち受け、認証情報の順に確認してください。スイッチの状態だけで利用可能かどうかを判断しないでください。

まず更新ログの具体的なエラーを確認してから、次の対処を決めましょう。HTTP 401または403は認証やサービスの状態、404はURLの無効化やパスの変更、429は時間をおいて再試行する必要がある可能性を示します。タイムアウト、DNS名前解決の失敗、TLSエラーの場合は、ネットワーク、システム時刻、証明書環境を優先して確認してください。ダウンロードには成功しても解析に失敗する場合、取得した内容がログイン画面やエラーページ、非対応のサブスクリプション形式である可能性があります。現在使える設定は残し、サブスクリプション更新時にクライアントがDIRECTとプロキシのどちらを使うか確認して、別の取得方法も試しましょう。認証情報を含むURL全体を公開のチェックサイトに貼り付けないでください。

通常は再インストールを急がず、問題のあるプロキシを個別に確認します。対象ノードを手動で選択し、ログからDNS名前解決の失敗、接続拒否、ハンドシェイク失敗、テストのタイムアウトのどれに該当するかを確認します。サブスクリプションの期限やサーバー設定が変更されていないかも調べましょう。テスト先の一部に到達できない場合、テストがタイムアウトしても実際の通信がすべて失敗するとは限りません。実際のリクエスト結果も確認してください。信頼できる別のネットワークに切り替えて再テストすると、ネットワーク経路とサーバーのどちらに問題があるか切り分けやすくなります。UDPを使うプロトコルだけで問題が起きる場合は、ネットワークが該当する通信に対応しているか確認しましょう。エラーを消すために証明書検証を安易に無効化しないでください。

システムプロキシの設定が適用されるのは、その設定に従うアプリに限られます。コマンドラインツール、一部のブラウザー設定、アプリ内蔵のネットワーク機能は、個別のプロキシ設定を使う場合があります。まずシステム上のプロキシアドレスとポートが現在のクライアントの設定と一致しているか確認し、ほかのソフトウェアが設定を繰り返し変更していないか調べてください。新しいページにアクセスし、クライアントの接続ログを確認します。ログがまったくない場合は通信の入口を、ログがありDIRECTに一致する場合はモードとルールを、プロキシが選ばれているのに接続できない場合はプロキシ側を確認してください。より多くのアプリの通信を制御する必要がある場合はTUNモードを検討できますが、事前に権限とルーティング環境を確認し、複数の通信制御ツールを同時に動かさないようにしましょう。

一部のUWPアプリはAppContainerのループバックアクセス制限により、クライアントが待ち受けるローカルプロキシポートに接続できないことがあります。まず通常のデスクトップアプリで同じプロキシが使えることを確認し、対象アプリが実際にこの制限を受けているか調べましょう。Microsoft StoreからインストールしたアプリがすべてUWPというわけではありません。クライアント付属のループバック免除ツールを使うか、WindowsのCheckNetIsolationの説明に従って対象パッケージに免除を設定できます。通常、この操作には管理者権限が必要です。設定後はアプリを完全に終了して再起動し、接続ログを確認してください。免除は必要なアプリに限って設定し、不要になったら該当する免除を削除しましょう。