Clashのよくある質問

Clashは通常、プロキシツールのエコシステムを指し、以前のコアプロジェクトを指す場合もあります。mihomoはClash Metaから派生したコアで、設定の解析、DNS処理、ルール照合、出力先への接続を担います。クライアントはサブスクリプション管理やプロキシ選択、システムプロキシなどの操作画面を提供します。トラブル時は、Clashをインストールしたというだけでなく、クライアント名とコアの情報をそれぞれ記録してください。同じ画面でも使用するコアが同じとは限りません。設定項目がサポートされているかは、実際に動作しているコアのドキュメントと起動ログで確認します。

クライアントは接続を管理し、通信を振り分けるためのツールです。インストールしただけでは、プロキシ経由で通信できる状態にはなりません。通常は、有効なサブスクリプションURLを用意するか、利用権限のあるノード情報を入力します。サブスクリプションにはノード、プロキシグループ、ルールが含まれる場合もあれば、ノード一覧のみの場合もあります。インポート前に、サービス提供元が案内する形式を確認してください。サブスクリプションURLのトークンは認証情報として扱い、スクリーンショット、ログの共有、オンライン変換時にはURL全体を隠してください。当サイトではクライアントのダウンロードと設定方法を案内していますが、サブスクリプションの発行や、サービス提供元によって停止されたアカウントの復旧はできません。

普段はまずルールモードを使いましょう。接続はrulesの順に照合され、最初に一致したルールで出力先が決まります。グローバルモードは通常、コアに取り込まれた接続を一つのグローバルポリシーに通すため、短時間の比較テストに向いています。DIRECTモードでは、これらの接続が直接アクセスを試みます。ここでいうグローバルとは出力先の決定方法であり、すべてのアプリの通信が自動的にクライアントへ取り込まれるという意味ではありません。アプリの通信を取り込めるかどうかは、システムプロキシ、アプリ内のプロキシ設定、またはTUNによって異なります。モードを切り替えたら新しい接続でテストしてください。既存の長時間接続は、切り替え前の出力先を使い続けることがあります。

新たに導入する場合は、まずClash Plusを確認し、Clash Verge RevやFlClashなどもOSの対応状況や操作方法で比較しましょう。特定の機能が必要なら、古い記事の名称だけで選ばず、最新のリリースノートを確認してください。移行前にサブスクリプションURL、自分で追加したルール、必要な設定をバックアップし、新しいクライアントに設定を再インポートします。以前のクライアントのデータベース、サービスコンポーネント、画面設定は、そのまま移せるとは限りません。移行中はシステムプロキシまたはTUNを制御するクライアントを一つに絞り、新しい設定が使えることを確認してから古いサービスを削除してください。

まずシステム情報でOSのバージョンとCPUアーキテクチャを確認し、ダウンロードページの対象環境を確認してください。Windowsのx64とARM64、macOSのIntelとApple Silicon、Androidのarm64とarmは、端末の見た目だけでは判断できません。Linuxではディストリビューションごとのパッケージ形式や実行時の依存関係も確認が必要です。インストーラーに非対応と表示された場合は、まずこれらの条件を確認してください。ファイルの拡張子を適当に変更してインストールを試すのは避けましょう。最低システム要件は、各クライアントの最新リリースノートで確認してください。古いOSではアプリが起動しても、システムプロキシや仮想ネットワークインターフェースに必要なコンポーネントが不足している場合があります。

まず、ダウンロードの失敗と内容の解析エラーを切り分けます。ダウンロードできない場合は、サブスクリプションの期限、トークンのリセット、更新リクエストがDIRECTかプロキシ経由かを確認してください。プロキシがまだ使えない場合、クライアントが対応していればDIRECTで更新します。ダウンロードできてもノードが表示されない場合は、ログインページやエラーメッセージを取得していないか、形式に互換性があるかを確認し、完全な設定ファイルが必要なのか、プロキシ一覧のURLが必要なのかも確認してください。非公開のサブスクリプションを公開変換サイトに貼り付けないでください。URLが正しいのにアクセス拒否やアカウントエラーが返る場合は、サブスクリプションの提供元に問い合わせましょう。クライアントを何度も再インストールしても、通常は解決しません。

リモートサブスクリプションの更新で設定全体が再生成されると、生成済みファイルを直接編集した内容は上書きされます。まずクライアントが実際に読み込んでいるファイルを確認し、クライアントが対応するオーバーライド、マージ、設定拡張機能を使って変更を保存してください。ルール配列は全体が置き換えられる場合も、指定位置に挿入される場合もあり、動作はクライアントによって異なります。追加するルールが、実在するプロキシグループを参照していることも確認してください。変更後は最終的に適用された設定とコアのログを確認し、エディター上の元データだけで判断しないでください。元の設定をバックアップし、一度に変更する項目を一種類に絞ってからサブスクリプションを更新し、変更が保持されるか確認しましょう。

TUNは仮想ネットワークインターフェースを作成し、ルートを変更する場合があるため、通常はクライアントのサービスコンポーネントまたはシステムの許可が必要です。利用中のクライアントの手順に従ってサービスをインストール・起動し、OSのネットワーク拡張、VPN、管理者権限の許可が完了しているか確認してください。LinuxではTUNデバイスとプロセスに必要な権限も確認します。警告を消すためにファイアウォールを常時無効にしたり、すべてのファイルの権限を広げたりしないでください。許可後も失敗する場合は、ログで最初に出たエラーを確認し、別のVPNがルートを制御していないか調べます。TUNは通信をコアに取り込む方法を決めるものです。有効にした後も、使用可能なノードと適切なルールが必要です。

プロキシグループの選択が影響するのは、最終的にそのグループを参照する接続だけです。すべてのルールに自動で適用されるわけではありません。まず接続パネルで対象の通信がコアに取り込まれているか確認し、次に一致したルールと最終的な出力先を確認してください。ルールがDIRECTを指定している場合、別のプロキシグループを変更しても結果は変わりません。ルールは通常、上から順に照合されるため、上位の広いルールが後ろの詳細なルールに先に一致することがあります。入れ子になったプロキシグループがさらに別のグループを参照していないか、アプリがシステムプロキシを迂回していないかも確認しましょう。設定を変えた後は既存の接続を閉じて再試行してください。ノードを次々と切り替えるより、影響した設定を特定しやすくなります。

カスタムルールは、先に一致する可能性のある広いルールより前に配置し、クライアントが提供する永続的なオーバーライド機能から追加するのが一般的です。DOMAINは指定したドメインに一致し、DOMAIN-SUFFIXはドメインのサフィックスに一致します。どちらもURL全体ではなくドメイン名を指定し、スキーム、パス、クエリパラメーターは含めません。ルール末尾のポリシー名は、既存のノード、プロキシグループ、または組み込みポリシーと一致させてください。MATCHは他の条件に一致しなかった場合のフォールバックルールで、通常はルール一覧の最後に置きます。早い位置に置くと、それ以降のルールは照合されません。保存後は新しい接続で一致記録を確認し、ルールが読み込まれ、実際に適用されていることを確かめましょう。

Fake-IPモードは、アプリに予約済みアドレス範囲内のマッピングアドレスを返します。コアはそのアドレスとドメインの対応を保持し、ドメインに基づいて実際の接続を処理します。Webサイトの権威DNSに登録された実際のレコードを書き換えるものではありません。LAN内のデバイス検出や制御、実際の名前解決結果に依存するアプリでは、fake-ip-filterへの追加が必要な場合があります。フィルター項目が変えるのは名前解決の動作であり、そのドメインへのアクセスをDIRECTにする設定ではありません。互換性の問題が起きたら、まず対象ドメインを特定し、必要最小限の項目だけを追加します。その後、関連するDNSキャッシュを消去して接続をやり直してください。原因を見えにくくするために、すべてのドメインを除外するのは避けましょう。

AppContainerで隔離された一部のWindowsアプリは、ローカルのループバックアドレスに直接アクセスできません。一方、ローカルプロキシは通常ループバックアドレスで待ち受けるため、ブラウザーでは接続できても、これらのアプリでは失敗することがあります。まず対象アプリが実際にこの制限を受けているか確認し、クライアント付属のUWPループバックツールか、WindowsのCheckNetIsolationツールを使って、必要なアプリにだけループバックの例外を追加してください。管理者権限が必要な場合があります。設定後は対象アプリを再起動します。Microsoft StoreのアプリがすべてUWPとは限らず、接続失敗の原因が常にループバック制限とも限りません。ログに接続記録がある場合は、例外を繰り返し追加するのではなく、ルールとノードを確認してください。

まず、端末の基本的なネットワーク接続が正常か確認し、ログで失敗しているのがノードサーバーの名前解決、サーバーへの接続、速度テスト先へのリクエストのどれかを調べます。速度テストのタイムアウトは、テストリクエストが制限時間内に完了しなかったことを示すだけで、ノードが恒久的に使えなくなったとは限りません。動作確認済みの別の出力先と同じテスト先を使って比較し、端末の時刻、サブスクリプションの有効期限、サーバーポート、プロトコル設定も確認してください。すべてのノードで同時に失敗する場合は、まずローカルネットワークと共通設定を確認します。一部のノードだけ失敗する場合は、提供元に稼働状況を問い合わせてください。明確な名前解決エラーがある場合に限り、DNSを調整しましょう。

まず、失敗したドメイン、エラーが発生した時刻、使用したリゾルバーを記録し、ノードサーバーのドメインと接続先Webサイトのドメインのどちらを解決できないのか切り分けます。設定したDNS上流に到達できるか、暗号化DNS上流のドメインを解決するためのブートストラップ経路が使えるかも確認してください。TUN使用時は、システムのDNSリクエストが想定どおりコアに取り込まれているかを確認し、他のDNSツールと制御が競合していないか調べます。上流DNSまたはルート設定は一度に一つだけ変更し、キャッシュを消去してから再試行し、比較用のログを残してください。複数のDNS制御機能を同時に有効にすると、一時的に直っても原因を特定しにくくなります。

システムプロキシはアプリが参照するプロキシ設定であり、すべてのプログラムに使用を強制するものではありません。コマンドラインツール、ゲーム、独自のネットワーク処理を行うアプリなどは、設定を無視することがあります。まずOSのプロキシアドレスとポートがクライアントの待ち受け設定と一致しているか確認し、接続パネルに対象アプリの通信が記録されているか調べます。記録がない場合は、アプリ独自のプロキシ設定、プロキシ環境変数、除外リストを確認してください。必要であれば、権限を確認したうえでTUNを使用します。記録がある場合は、ルールと出力先を順に確認しましょう。テスト中は他のプロキシクライアントを終了し、システム設定が上書きされないようにしてください。TUNとグローバルの出力モードは別の機能です。

ポート使用中のエラーは、必要な待ち受けアドレスを別のプロセスが使用している状態です。クライアントを二重起動していないか、古いコアやバックグラウンドサービスが残っていないか確認してください。プロセスの用途を確認してから通常の方法で停止し、正体の分からないシステムプロセスを終了しないでください。ローカルの待ち受けポートを変更する方法もありますが、その場合はシステムプロキシやアプリに手入力したポートも更新が必要です。終了後にネットワークがおかしくなった場合は、停止したクライアントを指すプロキシ設定がシステムに残っていないか確認し、他のVPN、ルート、DNSの状態も調べます。まずクライアントの通常の終了手順で通信制御を解除してください。通常の方法で復旧しない場合に限り、元のネットワーク設定を記録してからネットワークのリセットを検討します。