Clashのよくある質問

クライアントは設定の読み込み、システムプロキシ、画面操作を担い、コアは設定の解析、ルールの照合、接続の確立を担います。Clash MetaはオリジナルのClashから派生したプロジェクトで、mihomoも同じコアの系譜を受け継いでいます。クライアント名にClashが含まれていても、同じコアを使っているとは限りません。プロトコルに対応していない、または設定項目のエラーが出る場合は、クライアントのバージョン情報でコア名を確認し、該当バージョンの設定項目を調べてください。画面上の名称だけで互換性を判断しないようにしましょう。

クライアントはネットワークツールであり、インストーラーを入手しただけでプロキシサービスを使えるわけではありません。通常は、利用権限のあるサブスクリプションURLを読み込むか、自分で管理しているサーバー情報を入力する必要があります。まず設定画面に設定ファイルがあり、有効化されていることを確認し、次にプロキシまたはプロキシグループがポリシーグループで参照されているか確認してください。DIRECTのみの設定では直接接続の振り分けはできますが、プロキシノードは自動で追加されません。クライアントのダウンロードとサーバー接続情報の入手は別の手順です。

ルールモードではrulesを上から順に照合し、最初に一致したルールで接続先が決まります。日常的な振り分けに適しています。グローバルモードでは、コアに入った接続をグローバルポリシーで処理し、DIRECTモードでは接続先へ直接アクセスします。まずはルールモードを使い、接続ログで適用されたルールを確認しましょう。グローバルモードにしても、もともとコアに入っていないアプリが自動的にプロキシを使うわけではありません。システムプロキシやTUNによる通信の取り込み設定の代わりにもなりません。

システムプロキシとTUNは通信を取り込む方法が異なり、通常は両方を有効にする必要はありません。システムプロキシはOSのプロキシ設定に従うアプリ向けです。TUNは仮想ネットワークインターフェース経由で通信を取り込み、より多くのアプリをカバーできますが、管理者権限が必要な場合があります。初めて設定する場合は、まずシステムプロキシだけを有効にし、ノードとルールが正常に動作することを確認してから、必要に応じてTUNを使いましょう。併用する場合はクライアントの説明に従い、問題が起きたら切り分けのため片方を無効にしてください。

それぞれ役割が異なります。コアのプロジェクトはネットワーク処理コードを、クライアントのプロジェクトはGUIやOSとの連携を管理します。サブスクリプション提供元はサーバー接続情報やサービス状況を提供します。Clash設定ガイドはクライアントの入手先と設定方法を案内するサイトで、サブスクリプションの発行や期限切れアカウントの復旧は行いません。「Clash 公式サイト」や「Clash 無料ノード」を検索する際は、ページの運営元と用途を確認してください。出所の不明な変換サイトや問い合わせフォームにサブスクリプションキーを入力しないようにしましょう。

Ubuntuのデスクトップ環境では、Linux対応のGUIクライアントを使うと、サブスクリプションの読み込みやポリシーの切り替え、ログの確認が簡単です。デスクトップ環境のないサーバーでは、mihomoを直接実行し、systemdでプロセスを管理する方法が適しています。ダウンロード前にuname -mでCPUアーキテクチャを確認し、パッケージの形式も確かめてください。デスクトップクライアントと単体のコアが同じプロキシポートを使用しないようにしましょう。サービスとして運用する場合は、実行ユーザー、設定ディレクトリ、設定ファイルの読み取り権限も改めて確認してください。

まず、アカウント管理ページのURLではなく、サブスクリプションURL全体をコピーしたか確認し、前後に空白や改行が混じっていないかもチェックします。次に更新ログを確認してください。401や403ならアクセス権限、404ならURLの変更、タイムアウトなら現在のネットワークと更新時の接続経路を確認します。内容を取得できても解析エラーになる場合は、ログイン画面が返されたか、形式が対応していない可能性があります。提供元に問い合わせる際は、ステータスコードとエラーの概要だけを伝え、サブスクリプションURL全体は公開しないでください。

まず現在動作しているファイルをバックアップし、ログに記載された行番号の前後を確認します。エラーの位置は、直前の行のインデントや閉じていない引用符が原因の場合もあります。YAMLのインデントにはスペースを使い、Tabは使いません。リスト項目のハイフンと同じ階層の項目は位置をそろえてください。generalはガイド内で基本設定をまとめる区分名で、トップレベルのキーとして直接記述するものではありません。mixed-portなどの項目はルート階層に置きます。構文を直しても未対応のプロトコルや項目のエラーが出る場合は、インデントを何度も変えるのではなく、コアの対応状況を確認してください。

まずログを確認し、仮想ネットワークインターフェースの作成、ルートの変更、デバイスの不足など、どの段階で失敗しているかを切り分けます。Windowsではクライアントの説明に従ってサービスモードをインストールし、必要な権限を許可してください。Linuxでは/dev/net/tunが存在するか、プロセスに必要なネットワーク管理権限があるかを確認します。コンテナ環境では、ホスト側からデバイスと権限を明示的に渡す必要があります。ネットワーク権限の問題を解決するために、すべてのディレクトリの権限を緩めないでください。修正後にコアを再起動し、仮想インターフェース、ルート、DNSの設定が実際に反映されたか確認します。

リモートのサブスクリプションから生成された設定ファイルを直接編集すると、次回の更新でローカルの変更が上書きされることがあります。クライアントのオーバーライド、マージ、拡張設定機能を使い、カスタムルールをサブスクリプションと分けて保存してください。マージ後は最終的に適用された設定を確認し、ルールの順序とポリシーグループ名が正しいことを確かめます。優先して適用するルールは、通常フォールバック用のルールより前に置きます。マージの仕様はクライアントによって異なるため、移行時はオーバーライドファイルをコピーするだけでなく、適用結果も確認してください。

まず、単一のドメインを対象にするのか、ドメイン全体とそのサブドメインを対象にするのか決めます。DOMAINは完全一致、DOMAIN-SUFFIXはドメインとそのサブドメインに一致し、後者のほうが適用範囲が広くなります。ルールの接続先には、既存のプロキシ、ポリシーグループ、DIRECTなど有効なものを指定し、先に一致する可能性のある広範なルールやMATCHより前に配置してください。保存して再読み込みしたら、既存の接続を切って対象にアクセスし、接続ログで適用されたルールを確認します。すでに確立した長時間接続は、ルールを変更しても自動で新しい接続先に切り替わらないことがあります。

コマンドラインツールの中には、独自の引数やプロキシ環境変数だけを参照し、デスクトップのプロキシ設定を読み込まないものがあります。まずcurl --proxy http://127.0.0.1:7890 https://example.comを実行して単体テストを行い、ポートは実際のmixed-portに置き換えてください。テストが成功したら、ツールのドキュメントに従ってHTTP_PROXY、HTTPS_PROXY、またはALL_PROXYを設定し、NO_PROXYによって接続先が除外されていないか確認します。ターミナルの環境変数は、すでに起動しているバックグラウンドサービスには自動で引き継がれません。systemdサービスには個別に実行環境を設定してください。

まずdns.enableが有効になっていることを確認し、アプリからのリクエスト、OSのDNS、コアの上流DNSによる名前解決を分けて考えます。コアのDNSを有効にしただけで、OS上のすべてのDNS問い合わせが自動的に取り込まれるわけではありません。ブラウザー内蔵の暗号化DNSが別経路を使うこともあります。ログ、OSのリゾルバー設定、TUNのDNS取り込み設定を順に確認し、必要であればブラウザー独自のDNSを一時的に無効にして比較してください。DNSチェックページに表示されたリゾルバーの場所だけで、DNS漏れが発生したと判断することはできません。

まずクライアントでLANからのアクセスを許可し、コアの待ち受けアドレスと、ファイアウォールで使用ポートが許可されているか確認します。ほかの端末にはクライアントを実行しているPCのLAN内IPアドレスを入力してください。127.0.0.1は常に各端末自身を指します。信頼できるLAN内だけに公開し、クライアントが対応している場合はアクセス認証や接続元の制限を設定しましょう。ルーターでプロキシポートをインターネットに公開したり、共有のためにexternal-controllerの管理インターフェースを公開したりしないでください。

速度テストで確認するのは通常、指定されたURLへの1回のリクエストだけです。すべてのWebサイト、プロトコル、接続先で使えることを示すものではありません。まず対象へアクセスした際に接続ログが記録されるか確認し、実際に適用されたポリシーグループと速度テストで使ったノードが同じかを確かめます。次に、ドメインの名前解決、対象サイト、ほかのサイトをそれぞれテストし、DNS、特定サイト、ノード経路のどこに問題があるか切り分けます。遅延時間の数字だけを見てノードを次々と切り替えるのではなく、失敗時のエラーとルールの記録を残すと原因を特定しやすくなります。

まずコアが動作していること、システムプロキシのアドレスとポートがmixed-portと一致していることを確認します。そのうえで対象にアクセスし、接続ログを確認してください。ログがない場合は、アプリがシステムプロキシを無視していないか、ブラウザー拡張機能が設定を上書きしていないか、ほかのソフトが残したPACアドレスがシステムに設定されていないかを調べます。ログがありDIRECTと表示される場合は、システムプロキシを変更するのではなく、モードとルールを確認してください。システムプロキシに対応していないアプリでは、基本設定が正常に動作することを確認したうえでTUNを試せます。

まずプロキシを無効にして通常のネットワーク接続を確認し、サブスクリプションの期限が切れていないこと、ノード一覧が更新されていることを確かめます。コアを再度起動したら、システム時刻、サーバーの名前解決、ログに記録されたハンドシェイクエラーを確認してください。特定のプロトコルだけ失敗する場合は、コアの対応状況と現在のネットワークからUDPに接続できるかも調べます。すべてのノードが同時に失敗する場合は、DNS、誤った送信インターフェース、別のプロキシツールなど、共通の依存要素を優先して確認します。別のネットワークで比較するのも有効ですが、速度テストのタイムアウトだけでサーバーがすべて停止していると判断しないでください。

まず重複して起動しているクライアントを終了し、バックグラウンドで単体のコアやsystemdサービスが動いていないか確認します。Ubuntuではss -ltnpでTCPの待ち受け状態を調べ、プロセス情報と照合して使用中のプロセスを特定してください。不明なシステムプロセスをすぐに終了しないでください。両方のサービスを使い続ける必要がある場合は、mixed-portを変更し、システムプロキシ、ブラウザー設定、ターミナルの環境変数も合わせて更新します。プロキシポートとexternal-controllerの管理ポートは別です。管理ポートを変えても、プロキシの待ち受けポートの競合は解消されません。

UWPサンドボックスを使う一部のアプリにはループバック接続の制限があり、127.0.0.1上のプロキシに接続できないことがあります。ただし、ストアアプリがすべて該当するわけではありません。まずブラウザーで同じプロキシを使えることを確認し、対象アプリの接続ログが記録されるか調べてください。ループバック制限が原因と確認できた場合は、クライアント付属の例外設定ツールを使うか、管理者権限でCheckNetIsolationを実行して該当パッケージに例外を追加します。元に戻せるよう、変更した対象を記録してください。TUNの利用も検討できますが、すべてのアプリの制限を一括で解除する必要はありません。

警告をそのまま無視したり、証明書の検証を無効にして接続を復旧させたりしないでください。まずシステムの日時とタイムゾーンを確認し、警告に表示されたドメイン、証明書の発行者、有効期限が接続先サイトと一致するか調べます。次に、パケットキャプチャツールやほかのネットワークフィルターを終了し、直接接続、別のノード、別のネットワークで比較します。通常のプロキシ転送に、見知らぬルート証明書のインストールは必要ありません。特定の接続先だけで異常が起きる場合は、その経路を使ったアカウント情報や支払い情報の送信を中止し、エラー表示を保存して原因を調べてください。