Clashのよくある質問

クライアントはサブスクリプションの管理、システムプロキシの切り替え、接続状況の表示を担当し、コアはプロトコル接続、DNS処理、ルール判定を担当します。Clash MetaはオリジナルのClashから派生したコアで、後にmihomoへ名称が変更されました。クライアント名にClashが含まれていても、同じコアを使っているとは限りません。設定が動作するか判断するには、まず「バージョン情報」やコア設定で実際のコアを確認し、対応する項目やプロトコルを調べてください。移行時は元の設定をバックアップし、画面が似ているかどうかだけで互換性を判断しないようにしましょう。

クライアントのインストールで完了するのは、端末へのソフトウェア導入までです。通常は有効なサブスクリプションを読み込むか、自分で設定を管理する必要があります。サブスクリプションにはノードのアドレスや認証情報、プロキシグループなどが含まれ、クライアントが接続先を自動で用意するわけではありません。読み込み後は設定が有効になっているか、プロキシグループに選択肢があるかを確認し、ノードを選んで接続をテストします。リストが空の場合は、まずサブスクリプションの応答内容と形式を確認してください。システムプロキシを何度も切り替えても解決にはなりません。有効期限や利用量は提供元によって決まります。

以前の設定で引き続き動作する場合はありますが、クライアントの開発・保守は終了しているため、新しいプロトコルや設定項目に対応しているとは限りません。Clash Verge Revなどへ移行する前に、サブスクリプションのURL、プロキシグループの選択、ポート、カスタムルールを記録し、ひとつずつ読み込んで確認しましょう。新しいクライアントが設定ファイルを読み込めても、すべての動作が以前の環境と同じとは限りません。特にDNS、TUN、オーバーライドの設定を確認してください。新しい環境で正常に動作することを確認してから旧クライアントを終了し、複数のプロキシプロセスが同時にシステム設定を変更しないようにします。

ルールモードでは、設定されたルールの順序に従って接続先を決めます。グローバルモードでは通常、コアに入った接続をグローバル用のプロキシグループに渡します。直接接続モードでは、コアに入った接続を宛先へ直接つなぎます。変わるのは、コアが受け取った接続の処理方法です。すべてのアプリの通信が自動的にコアへ送られるわけではありません。初めて使う場合はルールモードを選び、接続画面で適用されたルールを確認してください。トラブルの切り分けには一時的にグローバルモードを試す方法もありますが、確認後は元のモードに戻し、ほかのアプリの通信経路を変えないようにしましょう。

iOSではダウンロードページからClash PlusのApp Storeページに進めます。製品の詳細は公式サイト clashplus.io で確認できます。サブスクリプションを共用できるかどうかは、クライアントが対応するプロトコルや設定形式によって異なり、名称だけでは判断できません。読み込む前に提供元が案内するリンクの種類を確認し、読み込み後はノードやプロキシグループが揃っているかを確認してください。デスクトップ向けのスクリプトやファイルパス、一部のTUN設定項目はスマートフォンにそのまま移せません。未対応項目のエラーが出た場合は、何度も読み込み直すのではなく、モバイル版のドキュメントに沿って設定を調整してください。

まず端末の日時が正しいか、サブスクリプションのURLが完全かを確認し、アカウントの期限切れや利用量超過も調べてください。クライアントの更新エラーも確認します。認証エラーならURLの認証情報、タイムアウトならサブスクリプションサーバーまでの通信経路、形式エラーなら設定ファイルではなくログイン画面などが返っていないかを確認しましょう。現在のプロキシが使えず更新できない場合は、クライアントが対応していれば直接接続で更新を試します。サブスクリプションURLには認証情報が含まれることがあります。公開変換サイトに送信したり、スクリーンショットに載せたりしないでください。解決しない場合は提供元にサービス状況を問い合わせましょう。

まずOSのデバイス情報でCPUアーキテクチャを確認し、対応するインストーラーを選びます。IntelやAMDの一般的なデスクトップCPUには通常x64、ARM端末にはARM64を選びます。Apple Silicon搭載MacとIntel Macも、それぞれに合ったものを選んでください。LinuxではCPUアーキテクチャに加えて、ディストリビューションのパッケージ形式も確認が必要です。OSが対応していないというエラーが出たら、クライアントのリリースノートで最小システム要件を確認してください。拡張子の変更や強制展開で、正規のインストール手順を代用しないでください。

TUNは仮想ネットワークアダプターを作成してルートを設定するため、デスクトップクライアントでは通常、サービスモードや管理者権限での操作が必要です。まずTUNを無効にし、クライアントの設定でサービスがインストール済みか、実行中かを確認してから、クライアントの案内に従って権限を付与してください。Linuxのサービスや権限の設定は、インストール方法に応じた手順を確認します。企業端末ではドライバーやルートの変更が制限されている場合があるため、管理者にポリシーを確認してください。エラー回避のためにファイアウォールを常時無効にしたり、ルートを制御するツールを複数同時に起動したりしないでください。具体的なエラーを記録してから、サービスの再インストールが必要か判断しましょう。

システムプロキシは、その設定に従うアプリにプロキシアドレスを知らせる機能です。独自のプロキシ設定を使うアプリもあり、既存の接続がそのまま再利用されることもあります。まずシステム設定のアドレスとポートが、クライアントの混合ポートと一致しているか確認します。対象アプリを再起動し、クライアントの接続画面に新しいリクエストが表示されるか確認してください。ブラウザー拡張機能、コマンドラインの環境変数、ほかのプロキシツールがシステム設定を上書きしている場合もあります。アプリがシステムプロキシに対応していない場合はTUNを検討できますが、通信がどこから入るか確認せずにノードや振り分けルールを変更しないでください。

AppContainerで分離された一部のWindowsアプリは、既定ではローカルのループバックアドレスにアクセスできず、端末上で待ち受けるプロキシポートに接続できない場合があります。まず対象アプリがこの種類に該当するか確認し、クライアントにループバックの除外設定がある場合は、必要なアプリだけを許可してください。すべてのアプリを一括で許可する必要はありません。ストアからインストールしたアプリがすべて同じ分離方式とは限らず、通常のデスクトップアプリにはこの説明が当てはまらない場合があります。TUNで通信を取り込む場合も、接続記録を改めて確認し、リクエストが実際にコアへ届いているか確かめてください。

クライアントの接続画面を開き、対象アプリから新しいリクエストを送信します。ドメイン名またはプロセス名で接続を探し、適用ルール、プロキシグループ、実際の出口を確認してください。既存の長時間接続には以前のルールが適用されたままの場合があるため、ルール変更後は接続を張り直して判断します。ルールは通常、上から順に照合されるため、先にある大まかなルールが後続の詳細なルールに優先することがあります。ルールモードになっているかも確認しましょう。ログにドメインの名前解決記録があるだけでは、通信がプロキシを通ったとは限りません。接続の詳細とアプリでのアクセス結果を合わせて確認してください。

サブスクリプションの更新では通常、設定が再ダウンロードされて置き換わるため、ダウンロードしたファイルを直接編集しても変更が残るとは限りません。継続して使うルール、DNS設定、プロキシグループの変更は、クライアントが対応するオーバーライドや設定マージ機能に記述し、適用順序も確認してください。配列の追加、項目の上書き、スクリプトの実行方法はクライアントによって異なるため、ほかのソフトの記述をそのまま流用しないでください。まず少数のルールで試し、マージ後の有効な設定を確認しましょう。クライアント移行時はサブスクリプションURLだけでなく、オーバーライドの内容もバックアップしてください。

Fake-IPはアプリに仮想アドレスを返し、コアがアドレスとの対応関係からドメイン名を復元して接続します。ドメイン情報を振り分けに利用しやすくなる仕組みです。LAN内のサービスや実際のIPアドレスを必要とするアプリでは、この応答方式が適さない場合があります。実際の不具合に応じて対象ドメインを適切なフィルター設定に追加し、すべてのドメインを除外するのは避けてください。変更後はアプリにドメインを再解決させ、接続を張り直します。フィルターの動作はコアのバージョンやフィルターモードによって異なります。設定を流用する前に該当バージョンの説明を読み、マッチ結果を逆に解釈しないようにしましょう。

遅延テストでわかるのは、通常、特定のテスト先への1回のリクエストにかかった時間です。大容量ファイルの転送速度や、すべてのWebサイトでの速度を示すものではありません。同じ端末、同じ接続先、近い時間帯でノードを比較し、特定の回線やアプリだけが遅いのかを確認してください。次にパケットロス、サーバー負荷、プロキシグループの出口、端末のネットワーク使用量を調べます。速度測定中はほかの大容量通信を止め、同時テストによる影響を避けてください。直接接続でも遅い場合は、クライアントの設定だけでなく、Wi-Fiやアクセス回線を先に確認しましょう。

まず画面ロック後やネットワーク切り替え後に、毎回切断されるかを確認します。Androidではクライアントのバックグラウンド実行権限、バッテリー最適化、システムVPNの設定を確認してください。メーカー独自のバックグラウンド制限がある場合もあります。iOSではクライアントのVPN状態やログを確認し、すべての切断をバックグラウンド処理の問題と決めつけないようにしましょう。画面点灯中にも接続できない場合は、サブスクリプションの有効期限やノード接続も確認します。プロトコルのキープアライブ、再接続の頻度、ネットワーク品質はいずれも電池消費に影響します。プロトコル名だけで設定の省電力性を判断することはできません。

必ずしもそうとは限りません。テスト先に接続できない、DNSに問題がある、端末の時刻がずれている、コアが正常に動いていないといった原因でも、すべてのノードがタイムアウトすることがあります。まず通常のインターネット接続を確認し、ログのエラー内容を調べてから、ノードを1つ選んで実際のアクセスを試してください。遅延テストだけ失敗してWebページは開ける場合は、テスト先と測定方法を確認します。実際の接続も失敗する場合は、認証情報、アカウント状態、サーバーアドレスを調べましょう。DNS、TUN、ルールを一度に変更すると原因を特定しにくくなります。毎回ひとつだけ変更し、元の値を控えてください。

まず、以前のクライアントや重複したプロセスがバックグラウンドで動いていないか確認し、アプリのログ、サービスログ、システムイベントを調べてください。ポートが使用中の場合は、そのポートを使っているプロセスを特定します。重複するプロキシを終了するか、空いているポートに変更し、システムプロキシや関連アプリの設定も合わせて更新してください。設定の破損が疑われる場合は、設定フォルダーをバックアップしてから、クライアントの案内に従って新しい設定で一時的にテストします。すべてのデータをすぐに削除しないでください。ランタイムやOSとの互換性に関するエラーは、リリースノートに沿って対処します。一般的なエラー画面を共有する際は、サブスクリプションURLや認証情報を隠してください。

まずTUNを無効にして比較し、ルートの取り込みが原因かどうかを確認します。ローカルのサブネット、企業VPNのルート、仮想ネットワークアダプターのアドレスが競合していないか調べ、コアとクライアントが対応する方法でルート除外を設定してください。直接接続ルールを追加するだけでは、誤ったネットワークアダプターに通信が流れる問題を解決できない場合があります。企業ネットワークで内部DNSが必要な場合は、名前解決の経路も確認しましょう。他人のサブネット除外リストをそのままコピーしたり、複数の自動ルーティングツールを同時に有効にしたりしないでください。変更後はインターネット、LAN、企業内リソースをそれぞれ確認します。

まず、どのドメインをどのDNSリゾルバーで解決するのか、リクエストを直接接続とプロキシのどちらに通すのかを明確にします。そのうえでコアのログと検査結果を照らし合わせ、実際の経路を確認してください。検査サイトに表示されるリゾルバーの地域や名称は手掛かりにはなりますが、それだけでリークを証明することはできません。ブラウザーのセキュアDNS、OSの暗号化DNS、別のVPNがクライアントのDNS設定を迂回する場合があります。TUNでDNSを取り込んでも、暗号化されたDNS通信がすべて自動的に取り込まれるわけではありません。アプリの設定、DNSの経路、プロキシの出口を個別に確認し、変更後は接続を張り直して再テストしてください。

まずシステムプロキシにローカルのアドレスが残っていないか確認してください。プロキシのプロセスが終了していると、そのアドレスは使えない接続先になるため、残ったシステムプロキシを無効にします。次にTUNやVPNが接続中のままになっていないか、ほかのアプリに手動プロキシ設定や環境変数が残っていないかを確認します。プロセスを強制終了するのではなく、元のクライアントを再起動し、システムプロキシとTUNを無効にしてから通常の手順で終了するのが安全です。まだ問題が残る場合にルートやDNSの状態を調べてください。企業ネットワークや固定IP設定が失われるおそれがあるため、ネットワーク設定の全リセットを最初に試すのは避けましょう。