Clashのよくある質問と接続トラブル対処

Clashは、ルールに基づく通信の振り分けに対応したプロキシツール群を指す言葉として使われます。mihomoはそのエコシステムで開発が続くコアで、設定の解析、ルールの照合、接続の確立を担います。クライアントは画面表示、サブスクリプション管理、システム連携を提供します。同じ設定項目が使えるかどうかは、実際に動作しているコアとそのバージョンによって異なります。トラブル対処を始める前に、クライアントの「バージョン情報」やコア情報で名称とバージョンを確認してください。別のクライアントの画面操作をそのまま当てはめないようにしましょう。

クライアントは設定を実行するためのもので、利用可能なリモートプロキシサービスを自動で提供するわけではありません。サブスクリプションからノード、プロキシグループ、ルールを取得するのが一般的ですが、ローカルのYAMLでも同様の設定ができます。インポート後は対象の設定を選び、プロキシグループで利用可能な出口を指定してください。ルールと空のプロキシグループだけでは、リモートプロキシに接続できません。サブスクリプションの提供元、有効期限、利用枠は提供元に確認しましょう。インストールできたことと、サービスを利用できることは別です。

通常は mode: rule を選び、接続を rules の上から順に照合します。グローバルモードでは、コアに届いた接続をグローバル用のポリシーに振り分けます。DIRECTモードでは、コアに届いた接続を直接外部へ送信します。ただし、これらは通信をコアへ取り込む方法とは別の設定です。アプリがシステムプロキシ、明示的なプロキシ、TUNのいずれも使っていなければ、モードを切り替えても影響しない場合があります。まずログに対象アプリの接続が記録されているか確認し、そのうえでルールモードとグローバルモードの結果を比べてください。

システムプロキシは、システム設定に従うアプリにプロキシのアドレスを通知しますが、無視するアプリもあります。TUNは仮想ネットワークインターフェースとルートを使って通信を取り込み、DNS、権限、ルート除外の設定も関係します。初回はシステムプロキシでサブスクリプションとノードを確認し、必要なアプリに応じてTUNを有効にするのがおすすめです。最初からすべての通信取り込み方式を同時に有効にする必要はありません。TUNで処理できる通信はプラットフォームの制限や設定によって異なるため、スイッチがオンになっているだけでは取り込みを確認できません。

Profileは通常、クライアント内の設定情報を指し、リモートサブスクリプションから作成する場合も、ローカルのYAMLから作成する場合もあります。サブスクリプションを更新すると提供元の内容を再取得します。オーバーライドは、読み込み時にローカルの設定項目やルール、プロキシグループの変更を追加するためのものです。設定のマージ順はクライアントごとに異なり、サブスクリプションから生成されたファイルを直接編集すると、更新時に変更が失われることがあります。継続して変更する前に設定をバックアップし、クライアントのオーバーライド仕様を確認したうえで、編集画面の元データではなく最終的に適用された設定を確認してください。

まず設定またはサブスクリプション画面でインポートが完了していることを確認し、その設定を現在使用する項目に指定してください。次に更新結果を確認します。Webページやログイン画面、エラーメッセージが返ってきた場合は、利用可能な設定とはいえません。サブスクリプションの有効期限と、内容が現在のコアに対応しているかも確認してください。解析に成功してもノードが表示されない場合は、proxy-groups が proxies または proxy-providers を参照しているか確認します。サブスクリプションのURL全体を公開しないでください。スクリーンショットを共有する場合も、クエリパラメーターに含まれる認証情報を隠しましょう。

ログに表示された行番号の周辺で、インデント、コロン、リストのハイフンを確認します。特に直前に編集した箇所を重点的に見てください。YAMLのインデントにはスペースを使い、タブを混在させないようにします。同じ階層の項目は位置をそろえ、特殊文字を含む文字列は必要に応じて引用符で囲みます。行番号が実際のエラーより後を示す場合もあるため、ひとつ前のブロックも確認してください。最後に使えた設定に戻し、一度に変更するのは一項目だけにします。解析に成功しても参照先がすべて有効とは限らないため、プロキシグループ名やルールの宛先も確認しましょう。

まずTUNを無効にし、通常のプロキシ接続が正常か確認します。その後、クライアントの案内に従ってサービスコンポーネントをインストールまたは修復してください。Windowsではサービスの状態と管理者権限を確認します。macOSでは案内に従って必要なネットワーク権限を許可します。Linuxではクライアントが対応する権限昇格の方法と、/dev/net/tun が利用可能かを確認してください。必要な条件はクライアントによって異なるため、システム権限を一律に緩めないでください。解決しない場合は、ほかのVPNや仮想ネットワークアダプターのツールを終了して再試行し、インターフェース作成エラーのログを記録します。

OS起動時のクライアント起動、コアの起動、プロキシによる通信の取り込みを分けて確認してください。クライアントによってはユーザーのログイン後に画面だけが起動し、サービスコンポーネントやシステムプロキシ、TUNは有効にならないことがあります。再起動後にクライアントのプロセスが存在するか、現在の設定が読み込まれているか、選択中のポリシーが利用可能かを確認し、OSのスタートアップ許可も確認してください。起動時にネットワークが利用可能になる前に、サブスクリプションの取得が失敗している可能性もあります。スタートアップ項目を何度も追加して解決しようとしないでください。複数のプロセスが起動すると、待ち受けポートを奪い合うことがあります。

まずOSの「バージョン情報」などでプロセッサのアーキテクチャを確認してから、ダウンロードするファイルを選びます。Windowsではx64とARM64、macOSではApple SiliconとIntel、Androidではarm64-v8aとarmeabi-v7aがよく使われます。Linuxではディストリビューションが対応するパッケージ形式も確認してください。アーキテクチャが合わないと、インストールや起動に失敗したり、互換レイヤーが必要になったりします。デバイスのブランドだけで判断せず、更新前に設定をバックアップしてください。クライアントのインストーラーと、単体のmihomoコアファイルを混同しないようにしましょう。

現在のモードが mode: rule で、編集中の設定が実際に使用されていることを確認してください。rules は上から順に照合されます。広い範囲に一致するルールや MATCH が先にあると、後続のルールは適用されません。ルールの宛先がプロキシグループ名と完全に一致しているか確認し、接続ログで実際のドメイン、宛先、適用されたルールを確認します。サブスクリプションの更新後に消える変更は、クライアントが対応するオーバーライド先へ移してください。読み込まれていないローカルのバックアップファイルにルールを書き足すだけでは反映されません。

select は出口を手動で選ぶ方式で、接続先の地域を固定したい場合や、出口を一貫させたい場合に向いています。url-test は指定したテストURLの結果に基づいて自動選択しますが、テストに成功してもすべての通信が正常とは限りません。fallback は通常、候補の順に利用可能な出口を選ぶため、優先順位を決めた予備経路に適しています。まず候補のノードが使えることを確認し、必要に応じて url、interval、tolerance などを調整してください。グループの種類を変えても、ノード自体の帯域は向上しません。

Profile全体の更新と、proxy-providers の更新を分けて考えます。前者は通常、クライアントのサブスクリプション設定で管理し、単位は画面の表示に従います。後者は設定内の interval で指定し、mihomoでは秒単位です。health-check.interval はヘルスチェックの間隔であり、サブスクリプションの再取得間隔ではありません。提供元の制限に合わせて更新頻度を設定してください。失敗したら手動で更新してエラーを確認し、短すぎる間隔で何度もリクエストしないようにしましょう。サーバー側で制限されるおそれがあります。

元の形式が現在のクライアントで使えず、提供元にも適切な形式がない場合に限り、変換を検討します。提供元が用意した互換形式を優先するか、信頼できるツールをローカルで使ってください。オンライン変換サービスにURLを送ると、そのサービスにサブスクリプションへアクセスする権限を渡すことになります。変換しても有効期限切れ、利用枠の超過、サーバー障害は解決できません。変換後はノードの種類、プロキシグループ、ルールが保持されているか確認してください。URLを誤って公開した場合は、提供元でサブスクリプションURLを再発行します。

クライアントの接続一覧またはログを開き、フィルターを解除してから、対象アプリで新しいリクエストを発生させます。該当するドメイン、プロセス、適用ルール、最終的な出口を確認してください。以前から続いている接続は、前のポリシーを使い続ける場合があります。必要に応じて対象アプリを終了してから再試行しましょう。Webページが開けたとしても、そのリクエストが成功しただけで、すべてのアプリの通信が取り込まれているとは限りません。出口IPの確認ページで分かるのも、そのページへの接続だけです。経路を確認したら詳細ログを無効にし、不要なアクセス記録を長期間残さないようにしてください。

ノードのテスト結果だけで判断せず、まずサブスクリプション更新ログを確認してください。HTTP 401や403はアクセス認証、404はURLの変更、429はリクエスト過多が原因の可能性があります。正確な意味は提供元の案内も確認してください。タイムアウトの場合は、サブスクリプションのドメインを名前解決できるか、現在のネットワークと更新リクエストの経路を確認します。解析に失敗した場合は、返された内容がWebページや非対応形式ではないか確認してください。証明書エラーが出たら、まずシステム時刻を確認し、問題を隠すために証明書検証を無効にしないでください。

サブスクリプションサーバーとプロキシノードは接続先が異なります。サブスクリプションを更新できても、ノードが利用可能とは限りません。ノードとテストURLを変えて比較し、サービスの利用枠、ノードのパラメーター、システム時刻を確認してください。特定のノードだけ失敗する場合は、発生時刻とエラーを提供元に伝えます。すべてのノードが失敗する場合は、ローカルのファイアウォール、ほかのVPN、現在のネットワーク制限を確認してください。テストURL自体にアクセスできず、タイムアウトすることもあります。実際の通信も確認し、テスト結果ひとつだけを理由に設定全体を削除しないでください。

まずコアが動作していることと、システムプロキシのアドレス・ポートが mixed-port または実際のHTTP待ち受けポートと一致していることを確認します。次に、ブラウザー独自のプロキシ設定、拡張機能、企業ポリシーを確認し、プロキシの除外リストに対象のアドレスが含まれていないか調べてください。ブラウザーを完全に終了して再起動し、接続ログを確認します。ログにリクエストがなければ、通信を取り込む経路に問題がある可能性があります。リクエストが記録されていれば、適用ルールと出口を確認してください。ローカル接続のために allow-lan を安易に有効にしないでください。

AppContainerで分離された一部のWindowsアプリは、既定ではローカルのループバックアドレスにアクセスできず、127.0.0.1 で待ち受けるプロキシに接続できないことがあります。まず対象アプリがローカルプロキシを実際に使っているか確認してください。そのうえで、クライアントが提供するループバック許可ツールを使い、必要なアプリだけに個別で許可を設定します。ツールの実行に管理者権限が必要な場合があります。この制限はすべてのWindowsアプリに当てはまるわけではないため、全プログラムをまとめて許可しないでください。許可後も解決しない場合は、同じ許可を何度も追加せず、アプリ独自のプロキシ動作、DNS、ファイアウォールを確認します。

まずTUNを無効にして、通常のネットワーク接続が復旧するか確認します。次にログでDNSのタイムアウト、ルートの競合、インターフェースのエラーを調べてください。設定で auto-route を有効にしている場合は、ほかのVPN、コンテナネットワーク、LANのルートと競合していないか確認します。dns-hijack を使っている場合は、DNSサービスが動作しているか、上流のDNSに到達できるかを確認してください。LAN内の機器に接続できない場合は、ルート除外とルールの両方を確認します。DIRECT を追加するだけでは、通信の取り込み層で起きている競合を解決できないことがあります。一度に変更するのは一項目だけにして、元に戻せるよう設定を保存してください。