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

クライアントは設定の読み込み、プロキシグループの切り替え、ログの確認を行うための画面を提供します。コアは設定を読み込み、接続を処理して通信を振り分けます。mihomoはClashエコシステムで開発が続くコアの一つです。サブスクリプションは設定やノード情報を取得するためのURLです。クライアントをインストールしただけでは接続できず、有効な設定と対応するサービスが必要です。トラブル時は、まず設定が有効でコアが起動していることを確認し、次にプロキシグループの選択を確認しましょう。サブスクリプションの問題をインストールの問題と混同しないことが大切です。

普段はルールモードを選び、設定したルールに応じて通信の経路を決めるのがおすすめです。グローバルモードでは、コアが処理する通信にグローバルポリシーを適用します。ルールが原因かどうかを短時間で確認したい場合に便利です。DIRECTモードでは、対象の通信が直接アクセスします。ただし、グローバルモードでもシステム上のすべてのアプリがプロキシ経由になるわけではありません。対象範囲はシステムプロキシやTUNの設定によって異なります。テスト後はルールモードに戻し、モードボタンの表示だけでなく実際の接続ログも確認してください。

URLの見た目だけで互換性を判断することはできません。Clash YAMLには通常、プロキシやプロキシグループ、ルールなどが含まれます。一方、Base64の内容は別のクライアント向けのノード一覧だけで、通信の振り分けに必要な設定がそろっていない場合があります。サブスクリプションの提供元でClashまたはmihomo向けと明記された形式を選びましょう。クライアントが形式変換に対応している場合は、その手順に従ってください。サブスクリプションURLには認証情報が含まれることがあります。不明なオンライン変換サービスに送信したり、URL全体を公開したりしないでください。

基本的な項目の多くは引き継げますが、すべての設定が双方向に互換性があるとは限りません。mihomoが対応する一部のプロトコル、DNSオプション、拡張ルールは、古いコアでは認識されない場合があります。また、サードパーティ製クライアントが設定を統合または上書きすることもあります。移行前に既存のファイルをバックアップし、クライアントの設定チェックを実行してから、起動ログに項目やプロトコルのエラーがないか確認してください。未知の形式が見つかった場合は、コアの対応範囲を確認しましょう。エラー項目を削除して、そのまま使い続けるのは避けてください。

Clashチュートリアルは、クライアントの入手先や日本語の設定情報をまとめたサイトです。各クライアントの開発プロジェクトそのものではなく、サブスクリプションのアカウントやノードも提供していません。クライアントのダウンロード、コアの機能、サブスクリプションサービスはそれぞれ別の要素です。インストールの問題はOSや権限、設定の問題は形式やログを確認し、アカウントの期限や利用上限については実際のサービス提供元に問い合わせてください。クライアントの配布元を調べる際は、プロジェクト名と配布チャネルを確認しましょう。ページタイトルに「Clash公式サイト」などの検索語が含まれているだけで、公式と判断しないでください。

クライアントの設定またはサブスクリプション画面でURLを追加し、ダウンロードが完了したら、その設定を明示的に選択して現在の設定に指定します。リストに表示されているだけでは、有効になっているとは限りません。次にコアの実行状態を確認し、プロキシグループに選択可能なポリシーがあるか確認します。その後、システムプロキシを有効にしてブラウザーからアクセスを試してください。選択肢が既定のDIRECTだけの場合は、サブスクリプションのダウンロード結果と設定の解析ログを確認しましょう。初回はまずシステムプロキシで動作を確認し、必要に応じてTUNを有効にすると、どの段階で問題が起きたか特定しやすくなります。

まず、ダウンロードしたものが設定ファイルなのかWebページなのかを確認してください。ログにHTMLタグが表示される場合、URLがログインページやエラーページ、認証が必要な共有ページを指している可能性があります。サービス提供元からサブスクリプションURLをコピーし直してください。YAMLが返されている場合は、インデント、コロンの後のスペース、タブ文字の混入を確認します。エラー行だけでなく、その直前の行も確認しましょう。元の設定を取得し直すのが基本です。手動編集する前にコピーを保存し、修正後はクライアントの設定チェックを実行してから再読み込みしてください。

まず、ほかのプロキシクライアントと残っているコアを終了し、同じ待ち受けポートを別のプロセスが使用していないか確認しましょう。通常、再インストールは不要です。競合するプロセスを停止するか、mixed-portを未使用のポートに変更して設定を再読み込みしてください。ポートを変更したら、手動でプロキシを設定しているブラウザー、ターミナル、ほかのアプリも同じポートに変更します。クライアントが管理するシステムプロキシは、いったんオフにしてから再度オンにしてください。設定ファイルだけを変更してアプリ側に古いポートが残っていると、コアが正常に起動しても接続できないことがあります。

まずTUNをオフにし、通常のシステムプロキシが動作することを確認してから、クライアントの説明に従ってサービスコンポーネントをインストールまたは修復してください。Windowsでは通常、管理者権限が必要です。macOSでは補助プログラムの許可が求められる場合があります。Linuxでは起動方法やネットワーク管理権限によって異なります。許可した後、関連サービスを再起動し、TUNをオンにしてルートとネットワークアダプターのログを確認します。ルートの競合を防ぐため、ほかのVPNや同様の通信制御ツールも終了してください。警告を消すために、システムのセキュリティ機能を長期間無効にするのは避けましょう。

モバイル端末で初めてトンネルを確立するときは、通常VPN構成の許可を求められます。システムの確認画面で許可してください。Androidで画面ロック後に切断される場合は、バッテリー最適化、バックグラウンド実行、自動起動の制限を確認します。まずバックグラウンドで実際に停止されているか確認し、その後で該当アプリの設定を変更してください。iOSではVPN構成が有効か、ほかのVPNが接続を切り替えていないか確認します。システムに表示されるVPNマークが示すのはトンネルの状態だけです。サブスクリプションの有効性や、すべての宛先へのアクセスを保証するものではありません。クライアントのログもあわせて確認してください。

必ずしもそうとは限りません。クライアントの速度テストは通常、指定されたテストURLにアクセスします。タイムアウトの原因には、テストサイトに接続できない、DNSの異常、ハンドシェイクの失敗、ノード自体の障害などがあります。まず、そのノードで実際に利用したいサービスを選び、接続ログを確認してください。必要に応じて、確実にアクセスできる別のテストURLに変更し、各ノードを同じ条件で比較します。テスト結果はダウンロード速度や、すべてのWebサイトでの使い勝手を示すものではありません。複数のノードが同時に失敗する場合は、何度もテストを繰り返すのではなく、端末のネットワーク、システム時刻、サブスクリプションの状態を先に確認しましょう。

selectはユーザーが出口を手動で選ぶ方式で、同じノードを安定して使いたい場合に適しています。url-testはテスト結果に応じて候補を自動選択します。判定にはテストURLと間隔が影響します。fallbackは候補の順番に従って利用可能なものを選ぶ方式で、あらかじめ設定した優先順位を重視します。いずれも設定に記載された候補の範囲内で動作し、新しいノードを自動で追加することはありません。ポリシーの変更が反映されるのは通常、新しい接続です。既存の長時間接続は以前の出口を使い続けることがあるため、確認時はテスト接続を新しく作成してください。

クライアントの上書き設定、拡張ルール、設定統合機能を使い、サブスクリプション更新で置き換わるリモートファイルを直接編集しないでください。ルールは上から順に照合されます。具体的なドメインのルールは、広範なルールやMATCHより前に置きます。転送先のプロキシグループ名は、実際の設定と完全に一致させてください。追加後に再読み込みし、接続の詳細画面で適用されたルールと出口を確認します。設定の統合順序はクライアントによって異なります。保存できたら終わりではなく、最終的に有効な設定にルールが反映されたことも確認しましょう。

Fake-IPモードで予約済みアドレス範囲のマッピング用アドレスが表示されるのは、多くの場合、想定どおりの動作です。コアはマッピングを使ってドメインと接続を関連付けており、実際のサーバーがそのアドレスにあるという意味ではありません。LAN上の機器、特定のゲーム、実際の名前解決結果を必要とするアプリで問題が起きる場合は、必要なドメインをfake-ip-filterに追加します。その後、クライアントの機能に応じて関連するDNSキャッシュを消去し、再度試してください。見慣れないアドレスだからといって、DNS設定全体を変更するのは避けましょう。まず、問題のアプリやリクエストがコアを経由しているか確認してください。

問題を再現したときに、クライアント名、コアの情報、OS、使用モード、発生時刻を記録し、発生前後の関連ログを保存してください。共有する前に、サブスクリプションURL全体、認証情報、ノードのパスワード、アカウント識別情報、公開したくないドメインやアドレスを隠します。スクリーンショットのQRコードにサブスクリプション情報が含まれている場合もあります。設定ディレクトリ全体をアップロードせず、解析エラー、接続失敗の原因、適用されたルールなど、必要な部分だけを共有してください。サブスクリプション全体を公開してしまった場合は、サービス提供元に連絡し、URLの変更または古い認証情報の無効化を依頼しましょう。

まず、サーバー側で拒否されたのか、端末から接続できなかったのかを切り分けます。401や403は認証情報、権限、サービス提供元のポリシーが原因の可能性があります。404はURLの変更がよくある原因です。接続タイムアウトの場合は、現在のネットワーク、DNS、更新リクエストの通信経路も確認してください。サービス提供元のページにログインし、有効期限、利用上限、最新のURLを確認します。コピー時にクエリパラメーターを落としたり、空白が混入したりしないよう注意してください。無効になったノード経由でしか更新できない場合は、DIRECTまたは別の利用可能なネットワークに切り替えてから更新を試します。制限がかかるおそれがあるため、短時間に何度も再試行しないでください。

まず、コアが想定したローカルアドレスとポートで待ち受けているか確認し、次にシステムプロキシの設定が別のプログラムによって書き換えられていないか確認してください。ブラウザー拡張機能、アプリ内プロキシ、ターミナルの環境変数がシステム設定を上書きすることがあります。また、システムプロキシを参照しないアプリもあります。ブラウザーから新しいリクエストを送信し、クライアントの接続一覧に該当する記録が現れるか確認してください。記録がなければ通信の取り込みを、記録があればルールとノードを確認します。システムプロキシに従わないアプリも制御する必要がある場合は、TUNの設定を検討してください。

一部のUWPアプリはネットワーク分離の影響で、ローカルのループバックプロキシに接続できないことがあります。まず、通常のデスクトップブラウザーが同じプロキシ経由でアクセスできることを確認します。次に、クライアントにUWP向けのループバック免除ツールがあるか確認してください。ツールがある場合は、必要なアプリだけを免除対象に追加します。WindowsのCheckNetIsolationツールでルールを確認・管理する方法もあります。操作前にアプリのパッケージIDを確認してください。すべてのストアアプリを一括で免除したり、ストアアプリの接続障害をすべてループバック制限のせいにしたりしないでください。

まず、対象のアプリがクライアントの接続一覧に表示されるか確認します。次に、アプリが使うTCPまたはUDP通信が取り込まれているか、選択したノードが必要な通信方式に対応しているかを確認してください。ブラウザーが正常でも、経路の一部が使えることしか確認できず、ゲームや通話のUDP通信が正常とは限りません。TUNを有効にしてから問題が起きた場合は、一時的にオフにして比較し、ルート、DNS、ほかのVPNとの競合を確認します。一度に変更する設定は一つにして、結果を記録してください。必要に応じて、利用が許可された別のネットワークでも再テストしましょう。

まずシステムのネットワーク設定を開き、ローカルアドレスを指す手動プロキシ設定が残っていないか確認してください。コアの終了後は、その待ち受けポートが使えなくなっている可能性があります。残っているプロキシをオフにし、TUNまたはVPN接続が正常に切断されていることを確認します。必要ならクライアントを再起動し、通信制御を先にオフにしてから終了してください。それでも接続できない場合は、クライアント起動中にしか使えないDNSアドレスが残っていないか確認し、元のネットワーク設定に戻します。最初からネットワーク全体をリセットするのではなく、原因を調べられるようログと既存の設定を残しておきましょう。