Clashのよくある質問

Clashは、プロキシコアとその設定エコシステムを指す名称として広く使われています。Clash Metaは関連する派生コアで以前使われていた名称で、その後mihomoとして開発が続いています。クライアントは設定のインポート、システムプロキシ、接続状況の確認など、GUI機能を提供します。機能が使えるかどうかはアプリ名だけで判断せず、実際に搭載されているコアとそのバージョンを確認してください。古い解説にある設定項目も現在のコアのドキュメントと照らし合わせ、異なるコアの設定を混在させないようにしましょう。

クライアントは設定を読み込んでコアを起動するもので、インストールしただけで利用可能なリモートプロキシサービスが使えるようになるわけではありません。サブスクリプションには通常、プロキシ接続情報、プロキシグループ、ルールが含まれます。同じ目的は手動設定でも実現できます。まず設定の入手元が信頼できることを確認し、正常に読み込まれているか、プロキシグループに選択可能な項目があるかをチェックしてください。サブスクリプションURLには認証情報が含まれることが多いため、公開コメントやスクリーンショット、オンライン変換サイトに掲載しないでください。トラブルの相談時は、機密情報を伏せたエラーメッセージだけを共有しましょう。

ルールモードは、コアに届いた接続に対してrulesの順序に沿って経路を選ぶため、日常的な通信の振り分けに適しています。グローバルモードは、対象の接続すべてにグローバルポリシーを適用するため、特定のプロキシ経路を一時的に比較するときに便利です。ダイレクトモードでは、対象の接続が直接宛先にアクセスします。モードが決めるのは、コアが受け取った通信の処理方法であり、システムから通信を取り込む範囲を変更するものではありません。切り替えた後は新しい接続を作成して接続履歴を確認してください。ブラウザーの既存の長時間接続は、以前の経路を使い続けることがあります。

システムプロキシはOSの設定を通じて、その設定に従うアプリをローカルのプロキシポートに接続させます。TUNは仮想ネットワークインターフェースとルーティングを使って通信を取り込み、システムプロキシを参照しない一部のアプリにも対応できます。初めて設定する場合は、まずシステムプロキシで動作を確認し、必要に応じてTUNを有効にしてください。最初から両方を併用する必要はありません。TUNが通信を取り込む範囲は、ルーティング、除外設定、権限、プラットフォームによって異なります。スイッチがオンになっているだけで、すべてのアプリの通信がコアに届いているとは限りません。

設定ファイルをインポートできるからといって、すべての項目が反映されるとは限りません。モバイル版クライアントでは、サブスクリプション形式、ルールの構文、拡張項目、通信の取り込み方法への対応がデスクトップ版と異なる場合があります。クライアントを選んだら、まず対応する設定形式を確認し、インポート時のメッセージと接続履歴をチェックしてください。Clash PlusはダウンロードページのiOSカテゴリからApp Storeにアクセスできます。公式サイトはclashplus.ioです。デスクトップ版でのサービスのインストールやシステムプロキシの設定は、iOSでは利用できません。

まず、端末の時刻、現在のネットワーク、サブスクリプションのアカウント状態を確認します。次に、URLを最後まで正しくコピーできているか、余分な空白や改行がないか、アクセス用パラメーターの有効期限が切れていないかをチェックしてください。クライアントに表示されたHTTPステータスコードも記録しましょう。401や403は認証やアクセス制限、404はURLの変更が原因の可能性があります。タイムアウトする場合は、ネットワーク経路をさらに確認してください。クライアントにサブスクリプション更新用のプロキシ設定があれば、プロキシ経由と直接接続の両方を試します。まだ使える古い設定を何度も削除したり、サブスクリプションURL全体を公開したりしないでください。

まずエラーメッセージに記載された行番号と項目名を読み、その行と直前のブロックのインデント、コロン、リスト記号を確認します。YAMLのインデントには半角スペースを使ってください。全角コロンやタブ文字は解析エラーの原因になります。構文に問題がなくてもコアが読み込みを拒否する場合は、参照先のプロキシグループが存在するか、現在のコアが該当項目に対応しているかを確認します。元のファイルは残し、コピー上で最近の変更を少しずつ戻してください。サブスクリプションの認証情報やプロキシのパスワードを含むファイル全体を、公開オンラインツールに送信しないでください。

mixed-portは、同じポートでHTTPプロキシとSOCKSプロキシの接続を受け付けます。7890はよく使われる設定値ですが、すべてのクライアントで必須の固定ポートではありません。変更後は設定を再読み込みし、コアが新しいポートで実際に待ち受けていることを確認してから、システムプロキシ、ブラウザー拡張機能、コマンドラインの環境変数も更新します。クライアントの上書き設定を使っている場合は、サブスクリプションに記載されたポートが上書きされていないかも確認してください。設定ファイルだけを変更してシステム側のポートを古いままにすると、クライアントは動作していてもアプリが接続できないことがあります。

まずログを確認し、権限不足、仮想インターフェースの作成失敗、ルートの設定失敗を切り分けます。Windowsでは、バックグラウンドサービスのインストールと起動、またはクライアントの説明に沿った管理者権限での実行が必要な場合があります。macOSでは、該当するネットワーク権限の許可が必要です。Linuxでは通常、TUNデバイスとネットワーク管理の権限を確認します。サービスモードはGUIクライアントの動作方式であり、汎用的なYAML項目ではありません。権限を許可するかサービスをインストールした後、コアを再起動し、仮想インターフェースとルートを確認してください。関係のないプログラムを長期間、管理者権限で実行するのは避けましょう。

サブスクリプションの更新で置き換わるキャッシュファイルに、長期的に管理するルールを直接書き込まないでください。クライアントの上書き、マージ、スクリプト機能を使い、独自のルールやDNS設定を別の場所に保存する方法をおすすめします。まずクライアントのマージ方法を確認してください。リストが置き換えられる場合も追記される場合もあり、ルールの順序が変わることもあります。更新後はエディター上のローカルファイルだけでなく、最終的に適用された設定を確認します。クライアントをアップグレードする前に上書きファイルをバックアップし、プロキシグループ名の依存関係も記録しておきましょう。

selectは出口を手動で固定する場合に適しています。url-testは指定したテスト先への測定結果に基づいてメンバーを選びます。fallbackは通常、メンバーの順序に従って利用可能な項目を選択します。自動測定の結果はテスト先と測定時点の状態を示すもので、すべてのWebサイトやプロトコルの動作を保証するものではありません。selectのメンバーに自動選択グループを含めれば、一時的に手動で切り替える選択肢も残せます。問題を調べるときは、利用できることを確認済みのメンバーに固定して新しい接続を作成してください。自動切り替えによって、1回のテストに異なる出口の結果が混ざるのを防げます。

クライアントの接続一覧を開き、対象のWebサイトにもう一度アクセスします。ドメイン名またはプロセス名で絞り込み、適用されたルール、選択されたポリシー、実際の出力経路を確認してください。ルールは通常、上から順に評価され、最初に一致したものが適用されます。そのため、追加したルールより先に広範なルールが一致する場合は、そのルールより上に配置する必要があります。ドメイン名が表示されずIPアドレスしか見えない場合は、DNSの経路とスニッフィングの条件を確認します。設定を変更した後は、そのサイトの既存の接続を閉じてから再テストしてください。ページが開くかどうかだけでは、ルールが適用されたとは判断できません。

Fake-IPを有効にすると、コアはアプリにマッピング用アドレスを返し、その対応関係からドメイン名を復元して通信を振り分けます。設定でfake-ip-range: 198.18.0.1/16を使っている場合、その範囲のアドレスが返されても、それだけで障害とは限りません。重要なのは、その後の接続がマッピングを保持しているコアに戻ることです。LAN内のデバイス検出や特定アプリとの互換性に問題がある場合は、必要なドメインに限ってfake-ip-filterを設定してください。マッピング用アドレスが表示されたからといって、DNS機能全体を無効にする必要はありません。

まず、2台の端末が相互に通信できるネットワークに接続されていることを確認し、次にallow-lan、待ち受けアドレス、ホスト側ファイアウォールをチェックします。別の端末のプロキシサーバーには、クライアントを実行している端末のLAN内IPアドレスを指定します。127.0.0.1ではありません。また、実際に待ち受けているmixed-portを指定してください。許可する範囲は信頼できるLAN内に限定し、必要に応じて認証を設定します。ルーターのポート転送でプロキシをインターネットに公開しないでください。ホストのIPアドレス変更、ゲストネットワークの分離、無線アクセスポイントの端末間通信制限も接続失敗の原因になります。

確認したい接続先を選び、まずその接続先の既存接続を閉じます。次にクライアントの接続一覧に該当するリクエストが表示されるか、プロキシの経路が想定どおりかを確認してください。ブラウザーの設定の影響を切り分ける場合は、ターミナルでcurl -I -x http://127.0.0.1:7890 https://example.comを実行し、HTTPプロキシを明示してテストできます。ポート番号は実際の値に置き換えてください。このコマンドで確認できるのは、そのリクエストのプロキシ経路だけです。システムプロキシ、UDP、すべてのアプリの通信が正常に取り込まれていることを示すものではありません。

まず、複数のメンバーと異なるネットワークで結果を比較します。特定のメンバーだけ失敗する場合は、そのメンバーの接続情報、サービスの状態、プロトコルへの対応を確認してください。すべてのメンバーが失敗する場合は、端末の時刻、ネットワーク接続、DNS、設定の読み込み状態を優先して確認します。テスト先にアクセスできるかもチェックしてください。テスト用エンドポイントの障害で、すべてがタイムアウトすることもあります。測定に成功しても実際の通信が正常とは限らず、失敗しただけでサービス停止とも断定できません。実際のリクエストと、ログに記録されたハンドシェイク、名前解決、接続のエラーを合わせて判断してください。

まず、システムプロキシの接続先アドレスとポートが、コアの待ち受け設定と一致しているか確認します。次に、ブラウザー拡張機能、プロキシの除外リスト、ほかのプロキシソフトが設定を書き換えていないかをチェックしてください。ターミナルのプログラムはOSのプロキシ設定を参照しないことがあります。HTTP_PROXYやHTTPS_PROXYを個別に設定するか、プログラムのプロキシ指定オプションが必要な場合があります。プロキシを明示したリクエストと通常のリクエストを比較し、接続履歴も確認します。明示的なプロキシ接続は成功するのに通常のリクエストがコアに届かない場合は、ノードを何度も変更するのではなく、アプリがプロキシ設定を読み込む方法を調べてください。

まず、リクエストが実際にコアへ届いていることを確認します。次にログを見て、名前解決の失敗、DNSクエリのタイムアウト、上流への接続失敗がないか調べてください。nameserverに到達できるかを確認し、暗号化DNSを使っている場合は、そのサーバーのドメイン名を解決するためのブートストラップ経路も確認します。TUNを使う場合は、dns-hijackとアプリ内蔵のセキュアDNSが想定した経路に影響していないかをチェックしてください。一度に変更するのは1項目だけにし、設定を再読み込みしてから、必要に応じてOSのDNSキャッシュを消去し、接続を作り直します。DNSの項目をすべて同時に置き換えると、原因の特定が難しくなります。

AppContainerを使う一部のアプリにはループバック通信の制限があり、通常のデスクトップアプリのようにローカルプロキシへ接続できません。まず対象のアプリが該当するかを確認し、クライアントにループバックの除外機能があれば、必要なアプリだけを許可してください。管理者権限のターミナルでCheckNetIsolation LoopbackExempt -sを実行すると、既存の除外設定を確認できます。特定のパッケージへの設定方法は、Windowsのドキュメントに従ってください。すべてのアプリを一括で許可しないでください。設定後は対象アプリを再起動し、接続一覧でリクエストの経路を確認します。

まず、システムプロキシが、すでに待ち受けを停止したローカルポートを指したままになっていないか確認します。残っている設定を解除するか、クライアントを再起動してから通常の手順で終了してください。TUNを使用している場合は、バックグラウンドサービス、仮想インターフェース、ルートが復旧しているかも確認します。複数のネットワーク関連プログラムを同時に終了すると、状態の切り分けが難しくなるため避けてください。必要に応じてOSの設定に従ってDNSを自動取得に戻し、ネットワーク接続を作り直します。正体の分からないネットワークアダプターを削除したり、すべてのルートを消去したりしないでください。変更前後の設定とログを残し、復旧後に機能を一つずつ再起動しましょう。