Clashのよくある質問

Clashはもともと、接続処理やルール判定、DNS処理を担うプロキシコアです。Clash Metaは機能を拡張したフォークで、その後mihomoとして開発が続いています。Clash Verge Revなどのデスクトップクライアントは、コアに加えてGUIや設定管理、システム連携を提供します。同じサブスクリプションを使えるかどうかは、画面の見た目ではなく、コアが対応するプロトコルや設定項目で決まります。未知の項目や未対応プロトコルのエラーが出たら、まずクライアントのコア情報を確認し、設定要件と照らし合わせてください。テーマを変更しても、プロトコルの互換性は変わりません。

クライアントは設定を読み込んで通信を転送するもので、インストールしただけで利用可能なプロキシサービスが使えるわけではありません。通常はサービス提供元のサブスクリプションURL、またはサーバー情報・認証情報・ルールを含む設定ファイルが必要です。まず設定が使用中のコアに対応していることを確認し、読み込んで有効な設定にしたうえで、プロキシグループと通信の振り分け方法を選びます。ソフトウェアのライセンスとプロキシサービスの料金は別のもので、選んだプロジェクトやサービス提供元によって異なります。サブスクリプションURLには認証情報が含まれることがあるため、パスワードと同様に管理してください。問題を相談する際はURLやユーザー名、認証情報を隠し、設定全体を公開の掲示板に投稿しないでください。

システムプロキシは、プロキシのアドレスをOSの設定に登録し、その設定を参照するアプリの通信に適用します。ゲームやコマンドラインツール、独自にネットワークを管理するアプリなどは、システム設定を使わない場合があります。TUNモードは仮想ネットワークインターフェースとルーティングを使って通信を取り込み、より多くのアプリをカバーできますが、システム権限やルート、DNS設定への依存も大きくなります。普段のブラウジングでは、まずシステムプロキシで接続を確認し、必要に応じてTUNを試してください。TUNを有効にしても、すべての通信が必ずプロキシを通るわけではありません。実際の経路はルールや除外ルート、クライアントの実装によって異なります。クライアントで両方を連携させることはできますが、複数のプロキシソフトで同時に通信を制御するのは避けましょう。

まずOSとCPUアーキテクチャで候補を絞り、設定の互換性やシステム連携機能を比較しましょう。当サイトではWindows、macOS、Android、iOS向けにClash Plusを優先して掲載しています。LinuxではClash Verge RevやFlClashから比較できます。既存のmihomo設定を引き継ぐ場合は、名前だけで判断せず、クライアントのコアとインポート形式を確認してください。iOS版Clash PlusはApp Storeから入手でき、公式サイトはclashplus.ioです。移行前に既存の設定とルールを保存し、新しいクライアントでサブスクリプション、DNS、よく使うアプリの動作を確認してから旧クライアントを停止しましょう。複数のクライアントが同時にシステムプロキシを書き換えるのを防げます。

Windowsでは「設定」のシステム情報からシステムの種類を確認できます。macOSでは「このMacについて」でチップまたはプロセッサを確認してください。Androidは端末情報やメーカーの仕様でアーキテクチャを確認できます。x64とAMD64は通常同じ種類のアーキテクチャを指し、ARM64版は対応する端末向けです。macOSではApple Silicon版とIntel版も区別してください。ファイルサイズだけでインストーラーを選ばないようにしましょう。インストールに失敗したら、表示されたメッセージをすべて記録し、OSの必要要件、空き容量、旧プロセスの有無を確認します。セキュリティ警告はダウンロード元とプロジェクトの説明を踏まえて判断してください。インストーラーを実行するために、システム保護を長期間無効にしたり、セキュリティ設定をむやみに変更したりしないでください。

まずサブスクリプションURLが完全か確認し、コピー時に混入した空白や改行、末尾の句読点を取り除いてから、更新ログのエラー内容を確認します。401や403は認証・権限・アクセス制限、404はURLの変更が原因の可能性があります。設定データではなくWebページが返る場合は、専用のサブスクリプションURLをサービス提供元に確認してください。接続がタイムアウトする場合は、まずネットワークの状態と更新リクエストの送信経路を確認します。設定の解析に失敗したというログが出たら、サブスクリプションの形式が使用中のクライアントとコアに対応しているか確認しましょう。同じ無効なURLを何度もインポートしたり、個人用のサブスクリプションを不明な変換サイトに入力したりしないでください。認証情報が漏れた場合は、サービス側でURLを再発行してください。

まずTUNを無効にし、通常のプロキシ接続が使えることを確認してから、サービスや仮想ネットワークアダプター、ルートの作成に関するエラーをログで確認します。Windowsのデスクトップクライアントでは、サービスモードのインストールや修復が必要な場合があります。クライアントの説明に従って操作してください。macOSではシステムから求められるネットワーク拡張機能やVPNの許可を完了します。LinuxではTUNインターフェースの作成とルート変更に必要な権限を確認してください。Androidでは通常VPN接続の許可画面が表示されるため、使用中のクライアントからの要求であることを確認します。既存のVPN、古い仮想アダプター、セキュリティソフトが競合することもあります。一度に変更する項目は一つにして再試行し、権限の原因を調べずに常時管理者権限で実行するのは避けましょう。

アプリコンテナーで分離された一部のWindowsアプリは、ローカルのループバックプロキシに直接アクセスできません。そのため、ブラウザーは使えるのに特定のストアアプリだけ接続できないことがあります。ただし、すべてのストアアプリに当てはまるわけではありません。まず対象アプリがシステムプロキシを使うか確認し、クライアントの接続ログにそのアプリの通信が記録されているかを見ます。ループバック制限が原因なら、クライアント付属のUWPループバック免除ツールを使い、必要なアプリだけに許可を与えてください。操作には管理者権限が必要な場合があります。設定を変更したら対象アプリを再起動してテストします。それでも解決しない場合は、アプリ側のネットワーク設定、DNS、ルールを確認し、互換性があればTUNも試してください。すべてのアプリに一律で許可を与えるのは避けましょう。

普段はルールモードを使い、設定内のルールに従って通信を振り分けるのが基本です。グローバルモードでは、通信をグローバルポリシーに従って処理します。実際の接続先は、そのポリシーで現在選択されている項目によって異なります。振り分けが原因かどうかを短時間で確認する用途には使えますが、特定のプロキシサーバーが必ず選ばれるわけではありません。DIRECTモードでは通常、プロキシを経由せず接続先に直接アクセスします。モードを切り替えると新しい接続には新しいポリシーが適用されますが、既存の長時間接続はすぐに張り直されるとは限りません。テスト時は対象アプリを再起動するか、影響範囲を確認してから関連する接続を終了してください。同じモード名でもクライアントによって画面上の場所は異なります。モードとポリシーグループの選択内容をあわせて確認しましょう。

サブスクリプションから生成されるファイルを直接編集すると、次回の更新で上書きされることがあります。まずクライアントのオーバーライド、マージ、永続ルール機能を使いましょう。ルールは通常上から順に評価されるため、具体的なドメインルールは先に一致する可能性のある広範なルールより上に置きます。フォールバック用のMATCHは通常、末尾に置きます。追加後はYAMLのインデント、ルールタイプ、ポリシーグループ名の大文字・小文字を確認し、現在有効な設定を再読み込みしてください。ドメインルールが機能するかは、クライアントが接続先のドメインを識別できるかにも左右されます。宛先IPしか確認できない場合は、マッチ結果が異なることがあります。接続ログで一致したルールと実際の出口を確認すると、ページを何度も更新するより、ルールが読み込まれたか判断しやすくなります。

クライアントの起動、プロキシコアの起動、システムプロキシの有効化はそれぞれ別の処理です。クライアントがどの設定に対応しているかを個別に確認してください。まず手動起動で使える設定を保存し、その後ログイン時の自動起動を有効にして、重複したスタートアップ項目がないか確認します。ログイン後に一時的にネットワークが使えなくなる場合、コアの準備ができる前にシステムプロキシが設定されている、またはネットワーク接続前にサブスクリプションの更新が始まっている可能性があります。クライアントに起動遅延の設定があれば利用し、複数のネットワークツールが同時に起動しないようにして、起動ログも確認してください。個人用のサブスクリプションURLを公開スクリプトに記載しないでください。自動起動を無効にしたりアンインストールしたりする前に、クライアントを正常終了してシステムプロキシをオフにし、使えないローカルポートが設定に残らないようにしましょう。

遅延テストで分かるのは、通常、特定のテスト先への一度のリクエストにかかる時間です。継続的なダウンロード速度や、すべてのWebサイトでの使い心地を示すものではありません。接続先の場所、サーバー負荷、回線の混雑、パケットロス、ポリシーグループの選択などが実際の速度に影響します。まずWebページの通信がテスト対象の出口を使っていることを確認してください。同じ接続先・ネットワークを使い、近い時間帯に比較し、複数の速度テストを同時に実行しないようにします。特定のサイトだけ遅い場合は、そのドメインに適用されたルール、DNSの結果、接続先サービスの状態を確認します。すべての接続が遅い場合は、出口や基盤となるネットワークを切り替えて比較してください。一度の遅延テストだけを根拠にDNSやTUNの設定を大量に変更するのは避けましょう。

まずプロキシをオフにして、通常のネットワークから一般的なサービスにアクセスできるか確認します。次に、サブスクリプションが正常に更新されているか、認証が有効か、システム時刻が正確かを確認してください。その後、実際のWebアクセスと接続ログを使ってテストします。Webページを開けるのに遅延テストだけがタイムアウトする場合、テスト先に到達できないか、現在の回線に適していない可能性があります。すべてのノードが無効だとすぐに判断しないでください。実際のリクエストも失敗する場合は、タイムアウト、認証エラー、TLSエラーなど具体的な内容を記録し、別の出口と別のネットワークでも試します。すべての出口で同時に失敗するなら、サブスクリプションの状態、端末のファイアウォール、ネットワーク環境を優先して確認してください。条件は一度に一つだけ変更し、サービス提供元に説明できるようエラー情報を残しましょう。

まずクライアントでコアが動作中であることを確認し、システムプロキシに設定されたアドレスとポートが実際の待ち受け先と一致するか確認します。他の解説に書かれたポートを、そのまま自分の環境に設定しないでください。次に接続一覧を見て、対象アプリのリクエストがクライアントに届いているか確認します。ブラウザー拡張機能、アプリ独自のプロキシ設定、一部のコマンドラインツールの環境変数がシステムプロキシより優先されることがあります。また、システム設定を参照しないアプリもあります。まず明示的なプロキシ指定に対応したツールで単体テストを行い、その後アプリごとにプロキシを設定するかTUNを有効にするか決めましょう。クライアントを終了してもネットワークに問題が残る場合は、システムにローカルプロキシの設定が残っていないか確認し、古いプロキシ環境変数を削除してターミナルを再起動します。

まず、どのドメインをどの経路で名前解決したいかを明確にし、クライアント、システム、ブラウザーのセキュアDNS、ほかのVPNがそれぞれ名前解決を処理していないか確認します。テストサイトに表示されるリゾルバーの場所は手がかりにすぎず、それだけでDNS漏れがあるとは断定できません。設定やログを確認し、必要に応じてパケットをキャプチャして、DNSクエリの実際の経路を調べてください。Fake-IPは対応するアドレスを返して、コアがドメインと接続を関連付けられるようにする仕組みです。暗号化DNSと同じものではなく、すべての環境で有効にする必要もありません。LAN機器の検出や特定アプリとの互換性に問題がある場合は、ドキュメントに従って例外を設定してください。名前解決の方式を変えたら、関連するキャッシュを消去してアプリを再起動し、同じリクエストで再テストします。古いキャッシュを新しい結果と取り違えないようにしましょう。

まずクライアントでTUNとシステムプロキシを無効にし、正常に終了したあと、通常のネットワークが復旧するか確認します。クライアントが異常終了した場合は、システムにプロキシ設定が残っていないか、サービスのプロセスが動き続けていないかを調べてください。VPNや通信制御ツールは一つだけにし、DNS、ルート、仮想ネットワークアダプターの競合を確認します。クライアントを再起動したら、まずシステムプロキシをテストします。問題がなければTUNだけを有効にし、インターフェースの作成、ルート設定、DNSに関するログを確認してください。通常のネットワークが復旧しない場合は、ネットワークに再接続するか端末を再起動して再確認します。最初からすべてのネットワークアダプターを削除したり、ルートを消去したり、出所不明のネットワークリセットコマンドを実行したりしないでください。リモート接続やほかの業務用ネットワークに影響することがあります。